3 ms·

And Centos. $ cat /etc/redhat-release CentOS Linux release 7.2.1511 (Core) $ grep CONFIG_USER_NS /boot/config-3.10.0-327.22.2.el7.x86_64 CONFIG_USER_N

by dsp1234 10y ago

And Centos. $ cat /etc/redhat-release CentOS Linux release 7.2.1511 (Core) $ grep CONFIG_USER_NS /boot/config-3.10.0-327.22.2.el7.x86_64 CONFIG_USER_NS=y

LukeShu 10y ago
Ok, so more distros patch it to be a run-time sysctl flag than I thought. That doesn't change the fact that turning it on (and expecting to not introduce significant vulnerabilities by doing so) is saying "I'm running a significantly different userland than the standard one."
- kentonv 10y ago
  Ehh... I wouldn't recommend enabling it on a server that gives out shell accounts to multiple mutually non-trusting users... ... but I also wouldn't recommend operating such a server, period. Linux has too many vulnerabilities on a regular basis for it to be practical -- yes, many are userns-related, but many aren't. On a single-user desktop, enabling user namespaces is irrelevant. (User-root separation does not matter on a single-user desktop. All your sensitive data is in your home directory.) On a server machine that runs one service, again, enabling user namespaces has no significant security impact. If you are running multiple services on one machine and relying on UID separation (with no other sandboxing) for defense-in-depth, then, sure, enabling userns adds risk -- but again, disabling userns does not completely eliminate the risk.
  - deleted 10y ago
    [deleted]
  - catern 10y ago
    If we can't even trust UID separation to work, then the project of secure computing is hopeless. We've been working on UID separation for decades. If we can't get it right after all this time, what hope can Sandstorm possibly have of getting a new system right? Furthermore, abandoning the Unix permissions model requires us to rewrite the world. (a rewrite that, admittedly, Sandstorm has already made some great progress on) But, I think it is reasonable to trust UID separation and the Unix permissions model. Linux is not that vulnerable. With some diligence, a server can securely provide access to computational resources to multiple mutually non-trusting users, through the mechanism of Unix permissions. And it's really the only hope we have.
    - kentonv 10y ago
      > If we can't even trust UID separation to work, then the project of secure computing is hopeless. Not at all. We have better sandboxing mechanisms now. > If we can't get it right after all this time, what hope can Sandstorm possibly have of getting a new system right? UID separation has broken down because the attack surface has grown too large, encompassing: * The entire ever-growing system call list. * The huge /proc and /sys filesystems, which let you muck with all kinds of process and system state. * Devices in /dev, many connected to low-quality device driver code. * Every setuid-root binary installed on the system. When the API gets that huge, avoiding bugs across the whole thing gets impossible. Modern sandboxes work by massively reducing this surface. Sandstorm apps are restricted to a core set of common system calls, do not get /proc or /sys, only get a couple devices in /dev, and cannot use setuid-root binaries. In this situation, security is much easier. Moreover, we use a capability-based security model to permit apps to talk to each other and the world, rather than an ACL-based one. This model makes it much easier to start from zero and grow, rather than starting from everything being accessible and then shrink. > And it's really the only hope we have. Luckily, it is not.

by dsp1234 10y ago

And Centos. $ cat /etc/redhat-release CentOS Linux release 7.2.1511 (Core) $ grep CONFIG_USER_NS /boot/config-3.10.0-327.22.2.el7.x86_64 CONFIG_USER_NS=y

LukeShu 10y ago

Ok, so more distros patch it to be a run-time sysctl flag than I thought. That doesn't change the fact that turning it on (and expecting to not introduce significant vulnerabilities by doing so) is saying "I'm running a significantly different userland than the standard one."

kentonv 10y ago
Ehh... I wouldn't recommend enabling it on a server that gives out shell accounts to multiple mutually non-trusting users... ... but I also wouldn't recommend operating such a server, period. Linux has too many vulnerabilities on a regular basis for it to be practical -- yes, many are userns-related, but many aren't. On a single-user desktop, enabling user namespaces is irrelevant. (User-root separation does not matter on a single-user desktop. All your sensitive data is in your home directory.) On a server machine that runs one service, again, enabling user namespaces has no significant security impact. If you are running multiple services on one machine and relying on UID separation (with no other sandboxing) for defense-in-depth, then, sure, enabling userns adds risk -- but again, disabling userns does not completely eliminate the risk.
- deleted 10y ago
  [deleted]
- catern 10y ago
  If we can't even trust UID separation to work, then the project of secure computing is hopeless. We've been working on UID separation for decades. If we can't get it right after all this time, what hope can Sandstorm possibly have of getting a new system right? Furthermore, abandoning the Unix permissions model requires us to rewrite the world. (a rewrite that, admittedly, Sandstorm has already made some great progress on) But, I think it is reasonable to trust UID separation and the Unix permissions model. Linux is not that vulnerable. With some diligence, a server can securely provide access to computational resources to multiple mutually non-trusting users, through the mechanism of Unix permissions. And it's really the only hope we have.
  - kentonv 10y ago
    > If we can't even trust UID separation to work, then the project of secure computing is hopeless. Not at all. We have better sandboxing mechanisms now. > If we can't get it right after all this time, what hope can Sandstorm possibly have of getting a new system right? UID separation has broken down because the attack surface has grown too large, encompassing: * The entire ever-growing system call list. * The huge /proc and /sys filesystems, which let you muck with all kinds of process and system state. * Devices in /dev, many connected to low-quality device driver code. * Every setuid-root binary installed on the system. When the API gets that huge, avoiding bugs across the whole thing gets impossible. Modern sandboxes work by massively reducing this surface. Sandstorm apps are restricted to a core set of common system calls, do not get /proc or /sys, only get a couple devices in /dev, and cannot use setuid-root binaries. In this situation, security is much easier. Moreover, we use a capability-based security model to permit apps to talk to each other and the world, rather than an ACL-based one. This model makes it much easier to start from zero and grow, rather than starting from everything being accessible and then shrink. > And it's really the only hope we have. Luckily, it is not.