5 ms·

What advantages do file system namespaces have over separating by directories and users?

by nix0n 10y ago

acdha 10y ago
A big one is managing software which you didn't write: if you have two things which expect to be able to write to /etc/mydaemon.conf etc. you either need to burn a VM for each one, fork the startup scripts or take the Debian-style approach of maintaining patches which make everything configurable, or manage something like maintaining chroots directory hierarchies. (repeat for network namespacing: it's really nice not to need to play games to have your CI server start 3 running jobs which all think they're listening on port 80) None of that is impossible – in the case of chroot there's many years of precedent - but if you do it regularly, there's a strong appeal to automating a common pattern. This is especially true when your goal is supporting development teams: with something like Docker, normal users don't need root just to start a daemon on a privileged port or write to a couple of files. If you work in a large or security-conscious environment, that's a fairly big draw. (Not saying that Docker is perfect or necessarily the long-term winner in this space, only that there's a usability gap which a lot of people fall into).
- mmarx 10y ago
  > This is especially true when your goal is supporting development teams: with something like Docker, normal users don't need root just to start a daemon on a privileged port or write to a couple of files. If you work in a large or security-conscious environment, that's a fairly big draw. On the contrary, any user that can run arbitrary containers (such as rootplease[0], for example) has root-level privileges on the host system. [0] https://hub.docker.com/r/chrisfosterelli/rootplease/ https://hub.docker.com/r/chrisfosterelli/rootplease/
  - acdha 10y ago
    What I was thinking about wasn't protecting against outright malice but rather mistakes and errors: If you give developers sudo access and you don't have an extremely diligent team with strong system administration experience, you're going to run into problems where people made incompletely documented changes or cause problems while working which aren't caught early enough – ever see someone break out sudo or chmod 777 as their first debugging step or even write that into the install process because it was too much work to do it right? Docker is an enormous win here both because it sharply reduces the number of times someone needs privilege escalation and because it ensures that the end result of their work can be reliably audited and repeatedly deployed. It's true that Docker doesn't protect against compromised or malicious users with privileged access. That's a very hard problem in general which can only partially be addressed at this level — especially since many of the most damaging attacks don't need it (“The bad news: they exfiltrated our customer database. Good news: they didn't get root on the EC2 instance”). I think most of the answers for this problem are going to continue to rely on existing practices like code review, auditing, getting finely-grained SELinux / seccomp rules into the development mainstream, etc.
    - xorcist 10y ago
      > If you give developers sudo access Why would you, though? A developer would at the very most require the application's privileges, not the super user's. And that's only really necessary when doing live troubleshooting.
      - acdha 10y ago
        You have to if your developers are installing packages, working on deployment, running anything which runs on a privileged port, use tools like systemtap, etc. In some cases that can be avoided with configuration but then you're asking for bugs due to discrepancies between the environments. You can reduce the number of things which hit that friction in a number of ways: having easily repeatable builds so a developer can test on their own VM; using a cloud service so test VMs are disposable and never shared; setting up a platform / microservices approach so a wider range of things either don't need to be touched or can be deployed without privileged or direct access, etc. Containers (really namespaces) one way to hit that last goal: as a classic example, if you have a web app running on port 80 everyone who deploys will need to periodically restart Apache/nginx/Varnish/etc. and that may include elevated access to debug processes running as a different user. This is by far the simplest problem in this class and there are various ways (proxies, site users, firewall NAT rules, moving config into .htacccess or its equivalent, etc.) to reduce the number of times you have to care about it but but it still requires work to maintain and adapt code (especially with third-party apps). Some people quite reasonably prefer to solve this entire class of problems by tossing everything into a container so it can run as if it's the only thing on the box.
ChoHag 10y ago
Basically if you're a shit sysadmin, you don't have to bother learning anything or working hard. This is absolutely fine if you intend to remain a shit sysadmin. Go nuts with Docker. The 21st century will be waiting for you when you're done. So will 19 fucking 60 because nothing's fucking changed.

What advantages do file system namespaces have over separating by directories and users?

by nix0n 10y ago

What advantages do file system namespaces have over separating by directories and users?

acdha 10y ago

A big one is managing software which you didn't write: if you have two things which expect to be able to write to /etc/mydaemon.conf etc. you either need to burn a VM for each one, fork the startup scripts or take the Debian-style approach of maintaining patches which make everything configurable, or manage something like maintaining chroots directory hierarchies. (repeat for network namespacing: it's really nice not to need to play games to have your CI server start 3 running jobs which all think they're listening on port 80) None of that is impossible – in the case of chroot there's many years of precedent - but if you do it regularly, there's a strong appeal to automating a common pattern. This is especially true when your goal is supporting development teams: with something like Docker, normal users don't need root just to start a daemon on a privileged port or write to a couple of files. If you work in a large or security-conscious environment, that's a fairly big draw. (Not saying that Docker is perfect or necessarily the long-term winner in this space, only that there's a usability gap which a lot of people fall into).

mmarx 10y ago
> This is especially true when your goal is supporting development teams: with something like Docker, normal users don't need root just to start a daemon on a privileged port or write to a couple of files. If you work in a large or security-conscious environment, that's a fairly big draw. On the contrary, any user that can run arbitrary containers (such as rootplease[0], for example) has root-level privileges on the host system. [0] https://hub.docker.com/r/chrisfosterelli/rootplease/ https://hub.docker.com/r/chrisfosterelli/rootplease/
- acdha 10y ago
  What I was thinking about wasn't protecting against outright malice but rather mistakes and errors: If you give developers sudo access and you don't have an extremely diligent team with strong system administration experience, you're going to run into problems where people made incompletely documented changes or cause problems while working which aren't caught early enough – ever see someone break out sudo or chmod 777 as their first debugging step or even write that into the install process because it was too much work to do it right? Docker is an enormous win here both because it sharply reduces the number of times someone needs privilege escalation and because it ensures that the end result of their work can be reliably audited and repeatedly deployed. It's true that Docker doesn't protect against compromised or malicious users with privileged access. That's a very hard problem in general which can only partially be addressed at this level — especially since many of the most damaging attacks don't need it (“The bad news: they exfiltrated our customer database. Good news: they didn't get root on the EC2 instance”). I think most of the answers for this problem are going to continue to rely on existing practices like code review, auditing, getting finely-grained SELinux / seccomp rules into the development mainstream, etc.
  - xorcist 10y ago
    > If you give developers sudo access Why would you, though? A developer would at the very most require the application's privileges, not the super user's. And that's only really necessary when doing live troubleshooting.
    - acdha 10y ago
      You have to if your developers are installing packages, working on deployment, running anything which runs on a privileged port, use tools like systemtap, etc. In some cases that can be avoided with configuration but then you're asking for bugs due to discrepancies between the environments. You can reduce the number of things which hit that friction in a number of ways: having easily repeatable builds so a developer can test on their own VM; using a cloud service so test VMs are disposable and never shared; setting up a platform / microservices approach so a wider range of things either don't need to be touched or can be deployed without privileged or direct access, etc. Containers (really namespaces) one way to hit that last goal: as a classic example, if you have a web app running on port 80 everyone who deploys will need to periodically restart Apache/nginx/Varnish/etc. and that may include elevated access to debug processes running as a different user. This is by far the simplest problem in this class and there are various ways (proxies, site users, firewall NAT rules, moving config into .htacccess or its equivalent, etc.) to reduce the number of times you have to care about it but but it still requires work to maintain and adapt code (especially with third-party apps). Some people quite reasonably prefer to solve this entire class of problems by tossing everything into a container so it can run as if it's the only thing on the box.

ChoHag 10y ago

Basically if you're a shit sysadmin, you don't have to bother learning anything or working hard. This is absolutely fine if you intend to remain a shit sysadmin. Go nuts with Docker. The 21st century will be waiting for you when you're done. So will 19 fucking 60 because nothing's fucking changed.