4 ms·

I think this part of Unix is exceedingly problematic. I want to be able to run program that don't have the ability to do anything that I, personally, can do.

by amluto 1y ago

I think this part of Unix is exceedingly problematic. I want to be able to run program that don't have the ability to do anything that I, personally, can do. Ideally this would be doable without nasty kludges or root's help. Linux has some ways to accomplish this, for example: - seccomp. It can be done quite securely, but running general purpose software in seccomp is not necessarily a good way to prevent it from acting like the running user. - Namespaces. Unless user namespaces are in use, only root can set this up. With user namespaces, anyone can do it, but the attack surface against the kernel is huge, mount namespaces are somewhat porous (infamously, /proc/self/exe is a hole), and they can be a bit resource-intensive, especially if you want to use network namespaces for anything interesting. Also, user namespaces have kind of obnoxious interactions with ordinary filesystem uids (if I'm going to run some complex containerized stack with access to a specific directory within my home directory, who should own the files in there, and how do I achieve that without root's help?). And userns without subuid doesn't isolate very strongly, and subuid need's root's help. - Landlock. Kind of cool, kind of limited. - Tools like Yama. On Ubuntu, with Yama enabled (the default), programs can't generally ptrace (or read /proc/self/environ) from other programs running as the same user. In any case, once you've done something to prevent a process from accessing /proc/fd/PID for other pids belonging to the same user (e.g. pidns) and/or restricted ptrace (e.g. PR_SET_DUMPABLE), then environ gets protected.

jkrejcha 1y ago
It's not your (unprivileged user account's) place to decide the security posture of the entire system, that's why you're running into issues with root. Even Yama, an LSM, requires root (or de facto equivalent) for initial setup (as it should). Namespaces, if done incorrectly, can significantly increase the attack surface of the entire system (mount namespaces especially need to be treated with care) and same with regards to anything to do with user accounts. The real security barrier on most operating systems to date is the user account and if you want full isolation (modulo kernel bugs), run a process as a separate user if you're that concerned about leakage (or ideally, don't run it at all).
- amluto 1y ago
  > It's not your (unprivileged user account's) place to decide the security posture of the entire system, that's why you're running into issues with root. Tell that to literally any unprivileged user who would like to run any sort of software without exposing their entire account to any possible code execution bug or malicious code in the software they're running. > The real security barrier on most operating systems to date is the user account and if you want full isolation (modulo kernel bugs), run a process as a separate user if you're that concerned about leakage (or ideally, don't run it at all). That a very 1980s or maybe 1990s perspective, I think. It's 2025. I have some computers. They are mine. I trust myself to administer them and do pretty much anything to them, but I would prefer not to trust all my software. Sure, I can, very awkwardly, try to isolate things by using multiple uids, but it's extremely awkward and I see no technical reason why uids are a good solution here. And there are no shortage of technical reasons why uids are a horrible solution. I would like to run unprivileged software and delegate some degree of privilege to them -- imagine a web browser or an IDE or whatever. I, as the owner of the machine, can make a uid. But I would also like my IDE to isolate various things it runs from each other and from the IDE as a whole, and it cannot do that because it does not own the machine and should absolutely not be running as root.
  - icedchai 1y ago
    Apple's "App Sandbox" stuff helps quite a bit with this sort of thing. I realize that doesn't solve the Linux / generic Unix case. https://developer.apple.com/documentation/security/app-sandbox https://developer.apple.com/documentation/security/app-sandb...
    - amluto 1y ago
      I skimmed the docs. It appears that this is a mechanism whereby a developer can restrict what their app can do via some configuration in Xcode. This seems almost unbelievably weak — developers want more privileges for their app, not fewer (especially developers of semi-malicious tracker-style SDKs), and the app sandbox seems entirely capable of, say, allowing a document editor app to open a document in a separate sandbox.
nine_k 1y ago
Yes, if we talk about interactive use, where the user may want to run a program with isolation on a whim, and can't be bothered to prepare a separate account for it. Namespaces, to my mind, are a huge help, starting from trivial chroot and nsenter, all the way to bubblewrap [2] and containers (rootless, of course). Also, with a properly prepared disk image, and the OS state frozen when everything heavyweight has started already, you can spawn a full-blown VM in well under a second, and run a questionable binary in it. It would be fun to have "domains" within a user account, with their own views of the file system, network, process tree, etc, and an easy way to interactively run programs in different domains. Again, it's pretty doable; whoever creates an ergonomic product to do it, will win! (Well, not really, because most developers sadly run macOS, which lacks all these niceties, but has its own mechanisms, not very accessible to the user.) [1]: https://quintessence.sh/blog/bwrap-guide-linux/ https://quintessence.sh/blog/bwrap-guide-linux/
- jkrejcha 1y ago
  Part of the problem with namespaces in general comes from setuid/setgid binaries. Now, nosuid helps, but the argument goes (and this is why dropping privileges on Linux sometimes requires root) that blocking setuid can actually increase attack surface (because many programs, as part of their initialization routines setuid to a specific service user). Blocking setuid blocks this which can lead to a program unintentionally running, paradoxically, with too many privileges (or the incorrect set of ones). And in the case of allowing setuid and filesystem views, the issue here becomes that an unprivileged user could create a view of the filesystem that has an /etc/passwd and /etc/shadow file that the attacker knows in their home directory. Run some setuid program (like su or sudo) with this view and we've successfully became root, breaking out of the sandbox. And you can't whitelist /etc/passwd or whatever either. This is why allowing anyone to play with mount points is fraught with danger. Now is suid/sgid a fundamental part of a Unix-like system? No, but setuid was created in the world that was and even though these are arguably bugs, releasing a Linux kernel that creates a bunch of security holes in userspace is a very very bad breakage of userspace. --- No New Privileges does make this a bit better (as you can never gain more privileges than you already have, and this is a one-way door) and the kernel docs even say that eventually unshare or chroot may be allowed when operating under no new privileges But this is currently why you can't chroot as an unprivileged user as you can trivially blow through the security domain on most Linux distributions

by amluto 1y ago

jkrejcha 1y ago

It's not your (unprivileged user account's) place to decide the security posture of the entire system, that's why you're running into issues with root. Even Yama, an LSM, requires root (or de facto equivalent) for initial setup (as it should). Namespaces, if done incorrectly, can significantly increase the attack surface of the entire system (mount namespaces especially need to be treated with care) and same with regards to anything to do with user accounts. The real security barrier on most operating systems to date is the user account and if you want full isolation (modulo kernel bugs), run a process as a separate user if you're that concerned about leakage (or ideally, don't run it at all).

amluto 1y ago
> It's not your (unprivileged user account's) place to decide the security posture of the entire system, that's why you're running into issues with root. Tell that to literally any unprivileged user who would like to run any sort of software without exposing their entire account to any possible code execution bug or malicious code in the software they're running. > The real security barrier on most operating systems to date is the user account and if you want full isolation (modulo kernel bugs), run a process as a separate user if you're that concerned about leakage (or ideally, don't run it at all). That a very 1980s or maybe 1990s perspective, I think. It's 2025. I have some computers. They are mine. I trust myself to administer them and do pretty much anything to them, but I would prefer not to trust all my software. Sure, I can, very awkwardly, try to isolate things by using multiple uids, but it's extremely awkward and I see no technical reason why uids are a good solution here. And there are no shortage of technical reasons why uids are a horrible solution. I would like to run unprivileged software and delegate some degree of privilege to them -- imagine a web browser or an IDE or whatever. I, as the owner of the machine, can make a uid. But I would also like my IDE to isolate various things it runs from each other and from the IDE as a whole, and it cannot do that because it does not own the machine and should absolutely not be running as root.
- icedchai 1y ago
  Apple's "App Sandbox" stuff helps quite a bit with this sort of thing. I realize that doesn't solve the Linux / generic Unix case. https://developer.apple.com/documentation/security/app-sandbox https://developer.apple.com/documentation/security/app-sandb...
  - amluto 1y ago
    I skimmed the docs. It appears that this is a mechanism whereby a developer can restrict what their app can do via some configuration in Xcode. This seems almost unbelievably weak — developers want more privileges for their app, not fewer (especially developers of semi-malicious tracker-style SDKs), and the app sandbox seems entirely capable of, say, allowing a document editor app to open a document in a separate sandbox.

nine_k 1y ago

Yes, if we talk about interactive use, where the user may want to run a program with isolation on a whim, and can't be bothered to prepare a separate account for it. Namespaces, to my mind, are a huge help, starting from trivial chroot and nsenter, all the way to bubblewrap [2] and containers (rootless, of course). Also, with a properly prepared disk image, and the OS state frozen when everything heavyweight has started already, you can spawn a full-blown VM in well under a second, and run a questionable binary in it. It would be fun to have "domains" within a user account, with their own views of the file system, network, process tree, etc, and an easy way to interactively run programs in different domains. Again, it's pretty doable; whoever creates an ergonomic product to do it, will win! (Well, not really, because most developers sadly run macOS, which lacks all these niceties, but has its own mechanisms, not very accessible to the user.) [1]: https://quintessence.sh/blog/bwrap-guide-linux/ https://quintessence.sh/blog/bwrap-guide-linux/

jkrejcha 1y ago
Part of the problem with namespaces in general comes from setuid/setgid binaries. Now, nosuid helps, but the argument goes (and this is why dropping privileges on Linux sometimes requires root) that blocking setuid can actually increase attack surface (because many programs, as part of their initialization routines setuid to a specific service user). Blocking setuid blocks this which can lead to a program unintentionally running, paradoxically, with too many privileges (or the incorrect set of ones). And in the case of allowing setuid and filesystem views, the issue here becomes that an unprivileged user could create a view of the filesystem that has an /etc/passwd and /etc/shadow file that the attacker knows in their home directory. Run some setuid program (like su or sudo) with this view and we've successfully became root, breaking out of the sandbox. And you can't whitelist /etc/passwd or whatever either. This is why allowing anyone to play with mount points is fraught with danger. Now is suid/sgid a fundamental part of a Unix-like system? No, but setuid was created in the world that was and even though these are arguably bugs, releasing a Linux kernel that creates a bunch of security holes in userspace is a very very bad breakage of userspace. --- No New Privileges does make this a bit better (as you can never gain more privileges than you already have, and this is a one-way door) and the kernel docs even say that eventually unshare or chroot may be allowed when operating under no new privileges But this is currently why you can't chroot as an unprivileged user as you can trivially blow through the security domain on most Linux distributions