This is a tangent, but I think this is a significant security risk for desktop Linux users that only remains unexploited because of the small install base.
A compromised site or browser could easily show the user steps to install malware and with only a minimal amount of obfuscation they would be indistinguishable from legit instructions to a user who doesn't understand what the commands are supposed to do.
For secure computing you really need a UI which makes it obvious to the user when they are doing something potentially dangerous and when every command is a string of arcane characters, mostly requiring root access, this is impossible.
It's amazing that despite Linux having a dozen different sandboxing mechanisms, performing most tasks requires switching to a mode that would allow any program to do absolutely anything to the computer.
The "root user" concept is so bad for security, and the first thing a new user learns is "if something doesn't work, try it with sudo". You figure that out before you even know what sudo does.
Its a terrible model. honestly, the existing Unix/ring(n) model and the windows user model don't work for modern, single-user devices.but do much hardware and software architecture is built around it that it's hard to switch at this point
I feel like Microsoft is also just incredibly lazy. I think they could come up with a way to do sandboxing in at least a migratable way (so still-maintained applications can opt-into it) like they sorta tried with UWP, but there's just no money in it. Plus they do security consulting stuff so it's not like vulnerable software hurts their profits much.
I mean this is also how it works in Windows with Admin mode, but I think I've had to use sudo to do many more things than I had to use admin in windows.
Yeah, Windows uses the same flawed permissions model but in Unix so many tasks require root access. It reminds me of Vista's UAC implementation where it prompted for admin access so often a lot of people just turned it off.
If you download a mobile app, you get asked all kinds of things, like whether you want to allow location, access to the local network, file access, etc. (what things should the program be able to do and know). Desktop and server operating systems mostly don't have these because they were developed so long ago (and Micro$oft is lazy and incompetent).
There's higher resolution privilege approaches that aren't on/off but you'll typically see those in the form of manually configured user profiles and stuff. things the average desktop user just doesn't care for.
The best solution that's been proposed IMO is something called capability based security, which allows a hierarchy of trusted brokers to delegate very specific permissions for specific resources (files, hardware access, system calls) to applications. Rather than having the applications run as a "user" and inherit all the users permissions, the application is passed cryptographically secure "keys" representing a temporary permission to perform specific actions on a resource.
That's a big change to existing models though, a less dramatic solution would be applications running under an unprivileged user context then specifically requesting access to various features and files, like the Access Control List system Android layers on top of Linux ("do you want to allow this application to make phone calls etc.") or having multiple user accounts with varying privileges and applications requesting temporary permissions to run under the required user rather than having one big root account that does everything and everything needs access to.
The big problem with the root user is that for every privilege you choose to restrict to the root (or administrator), as soon as an application needs to perform one of those actions it must also get access to every single other interface protected by the root user account. Configuring network interfaces requires root access, but anything allowed to configure a network interface automatically is also allowed to read and write every single file on the system, including drivers, the kernel code and the boot structures.
Linux suffers from having a dozen poorly-documented/accessible ways to do sandboxing instead of one way that can be explained to newcomers and works for almost everything
A compromised site or browser could easily show the user steps to install malware and with only a minimal amount of obfuscation they would be indistinguishable from legit instructions to a user who doesn’t understand what the commands are supposed to do.
You don't even need that, I've seen a lot of projects tell you to curl a literal .sh you run in sudo.
I only do this if it's a really well known project and just kinda hope they weren't hacked on the exact day I'm installing it. You're right that it is a pretty big security issue, it's only a matter of time before somebody does that on a production machine somewhere, maybe it even happened who knows.
curl | sudo sh has got to be the funniest construct I've ever seen. who needs remote code execution when people will just download a script and inject it directly into their veins?
fwiw, I appreciate that nixos forces me to write a package for the stuff I want to use and doesn't already have one, and that I can't write a package that downloads a script and runs it because 99% of the, script will try to break out of the sandbox.
This is a tangent, but I think this is a significant security risk for desktop Linux users that only remains unexploited because of the small install base.
A compromised site or browser could easily show the user steps to install malware and with only a minimal amount of obfuscation they would be indistinguishable from legit instructions to a user who doesn't understand what the commands are supposed to do.
For secure computing you really need a UI which makes it obvious to the user when they are doing something potentially dangerous and when every command is a string of arcane characters, mostly requiring root access, this is impossible.
It's amazing that despite Linux having a dozen different sandboxing mechanisms, performing most tasks requires switching to a mode that would allow any program to do absolutely anything to the computer.
The "root user" concept is so bad for security, and the first thing a new user learns is "if something doesn't work, try it with sudo". You figure that out before you even know what sudo does.
Its a terrible model. honestly, the existing Unix/ring(n) model and the windows user model don't work for modern, single-user devices.but do much hardware and software architecture is built around it that it's hard to switch at this point
I feel like Microsoft is also just incredibly lazy. I think they could come up with a way to do sandboxing in at least a migratable way (so still-maintained applications can opt-into it) like they sorta tried with UWP, but there's just no money in it. Plus they do security consulting stuff so it's not like vulnerable software hurts their profits much.
I mean this is also how it works in Windows with Admin mode, but I think I've had to use sudo to do many more things than I had to use admin in windows.
Yeah, Windows uses the same flawed permissions model but in Unix so many tasks require root access. It reminds me of Vista's UAC implementation where it prompted for admin access so often a lot of people just turned it off.
it's because most distributions don't build and install packages with user permissions. check out home-manager for a fix to this.
Thanks for the recommendation, I might give this a go.
Based on the description on their github page, this isn't really mature enough to help the non-technical user who's copy pasting sudo commands though.
yeah, it's just a new model we could use and I'd like to see something similar get adopted by most distros.
deleted by creator
"this doesn't work, try it with sudo" is a recipe for bricking your machine.
How do you avoid the "root user" concept tho? What's the alternative?
If you download a mobile app, you get asked all kinds of things, like whether you want to allow location, access to the local network, file access, etc. (what things should the program be able to do and know). Desktop and server operating systems mostly don't have these because they were developed so long ago (and Micro$oft is lazy and incompetent).
There's higher resolution privilege approaches that aren't on/off but you'll typically see those in the form of manually configured user profiles and stuff. things the average desktop user just doesn't care for.
The best solution that's been proposed IMO is something called capability based security, which allows a hierarchy of trusted brokers to delegate very specific permissions for specific resources (files, hardware access, system calls) to applications. Rather than having the applications run as a "user" and inherit all the users permissions, the application is passed cryptographically secure "keys" representing a temporary permission to perform specific actions on a resource.
That's a big change to existing models though, a less dramatic solution would be applications running under an unprivileged user context then specifically requesting access to various features and files, like the Access Control List system Android layers on top of Linux ("do you want to allow this application to make phone calls etc.") or having multiple user accounts with varying privileges and applications requesting temporary permissions to run under the required user rather than having one big root account that does everything and everything needs access to.
The big problem with the root user is that for every privilege you choose to restrict to the root (or administrator), as soon as an application needs to perform one of those actions it must also get access to every single other interface protected by the root user account. Configuring network interfaces requires root access, but anything allowed to configure a network interface automatically is also allowed to read and write every single file on the system, including drivers, the kernel code and the boot structures.
Linux suffers from having a dozen poorly-documented/accessible ways to do sandboxing instead of one way that can be explained to newcomers and works for almost everything
You don't even need that, I've seen a lot of projects tell you to curl a literal .sh you run in sudo.
I only do this if it's a really well known project and just kinda hope they weren't hacked on the exact day I'm installing it. You're right that it is a pretty big security issue, it's only a matter of time before somebody does that on a production machine somewhere, maybe it even happened who knows.
curl | sudo shhas got to be the funniest construct I've ever seen. who needs remote code execution when people will just download a script and inject it directly into their veins?fwiw, I appreciate that nixos forces me to write a package for the stuff I want to use and doesn't already have one, and that I can't write a package that downloads a script and runs it because 99% of the, script will try to break out of the sandbox.