5 ms·

Systemd makes it easy to add additional limitations to every service you're running. More easily restrict all your services (NTP client, DNS caching server, etc

by bkor 10y ago

Systemd makes it easy to add additional limitations to every service you're running. More easily restrict all your services (NTP client, DNS caching server, etc). It adds an easy to use method to restrict all of the daemons and services that someone might be running. Further, because the unit files are often shipped with the daemon/service, it'll do this by default on every install. Not just to the ones which have been looked at by a sysadmin. So a standard RHEL server by default has more restrictions than before. The examples are pretty unconvincing IMO. The article talks about an email server. Systemd will provide an easy method to not have one service read the other one. In the examples it talks about email server and a web server. But completely ignores that someone will not just target that specific service, you could just as well compromise the NTP client and then move from there to another service. Obviously systemd is just one small layer and security is not a yes/no thing. But why then talk specifically about systemd? The article seems to suggest that it's better to not use these abilities. This goes against the usual defence in depth security IMO.

qwertyuiop924 10y ago
>Systemd makes it easy to add additional limitations to every service you're running So does chroot. And so does jails. And posix capabilities. And cgroups...
- darfs 10y ago
  I think he is being downvoted because he is factual wrong. Could someone please elaborate with details?
  - DyslexicAtheist 10y ago
    one of the arguments against systemd is that it consolidates several scriptable and bug-prone isolated scripts into a binary. This is introducing it's own risks that require upstream interaction to fix a small issue normally a sysadmin without knowledge of C can hot-fix locally. Considering the non existence of a systemd developer community, it's pretty risky. There are similar arguments (pro/against) docker where 2 camps, one saying it's poison & bloat the other the best thing since tabbed browsing. People get so riled up because they're unwilling to acknowledge that they're just tools that make lot sense for solving specific issues. Everyone keeps looking for silver bullets. Problems start when one camp tries to become the de-facto standard (not just the tool but also the processes that come with it). Also people are way to scared of code-forks IMHO. The "fail quick, fail fast" mentality should apply here too. Some healthy competition and a willingness to let certain projects just wither and die should be a good thing ...
    - deleted 10y ago
      [deleted]
    - wtbob 10y ago
      > Considering the non existence of a systemd developer community, it's pretty risky. There's also the fact that it's written in C. Writing security-sensitive software in C in 2016 is, in general, a grievous mistake. No, other languages are not perfect; yes, other languages have their own issues; regardless, C is worse than most. Buffer overflows, memory management, lack of type safety — Just Say No™.
      - qwertyuiop924 10y ago
        It's an acceptable language for writing the piece of software that init is supposed to be. However, systemd is for more complicated and integrated and unsafe than that piece of software.
        zeveb 10y ago
        > It's an acceptable language for writing the piece of software that init is supposed to be. Is it though? Although I can't think of a lot of vulnerabilities to be concerned of in PID 1, I can think of a few (perhaps something to do with reaping zombies?). Why even allow for that possibility? I see no reason why init(1) couldn't be written in Lisp, or Python (although the speed might not be great), or Go, or Rust, or Haskell, or ML.
        bandrami 10y ago
        PID 1 shouldn't have anything complicated about it. A comp sci student should be able to write it in 10 minutes. This is a solved problem[1]. A run control system, which should be a completely separate project, could easily be written in a higher-level language than C. For instance, the traditional Linux RC system is written in sh, and the official GNU RC system[2] is written in scheme. Daemon run control isn't a domain where performance is crucial; transparency is much more important there, so the argument for using a higher level language to control daemons is pretty strong. [1] http://git.suckless.org/sinit/ http://git.suckless.org/sinit/ [2] https://www.gnu.org/software/shepherd/ https://www.gnu.org/software/shepherd/
- bkor 10y ago
  It seems you skipped the bit where I said that those restrictions are often shipped by upstream and as such applied to everyone by default? It's one thing to lock down your machine(s), systemd allows to lock down loads of services for everyone. It's not perfect, it doesn't do everything. But is your suggestion really not to make use of systemd abilities because maybe something else could be used? How does this not go against the defence in depth theory? Try and use (filesystem) capabilities. Now apply that security fix: capability is gone. Further, that was just a change made to your machine(s). It seems much easier to improve the security on all fronts instead of going for some idealistic super safe solution that either takes ages or doesn't happen. Example: pretty nice to restrict that Jabber daemon written in Java from accessing too much of the filesystem.
  - qwertyuiop924 10y ago
    Well, posix capabilities can be packaged upstream do that. So can Capsicum, for that matter. And so can chroot...
    - bandrami 10y ago
      If only there were a free POSIX-ish OS that did privilege separation and chroot for daemons by default. Perhaps some enterprising Canadian developer could base it on the BSD kernel.
      - qwertyuiop924 10y ago
        Well then, there's your proof.
lmm 10y ago
> Obviously systemd is just one small layer and security is not a yes/no thing. But why then talk specifically about systemd? The article seems to suggest that it's better to not use these abilities. The claim is not that it's better not to use these capabilities (which in any case do not require systemd; there are any number of ways to achieve the same thing). The claim is simply that systemd does not offer a substantial enhancement to system security, and that perhaps the increased attack surface offered by systemd itself outweighs any security benefit it provides to the services running under it.
- bkor 10y ago
  Stating that his claim is something else doesn't make it true. If you read the article he's saying things such as: 1. Things should be written in different (safer) languages. 2. That a compromise in a mail server is already bad so having systemd protect the mail server according to him does NOT help At least 50% is spend on those bits. Those are poor arguments to make. Systemd adds additional capabilities to make the overall system safer. You can do both. He stated nothing about an increased attack surface.
  - lmm 10y ago
    Of course I read the article. Maybe you didn't? > 2. That a compromise in a mail server is already bad so having systemd protect the mail server according to him does NOT help Right, the point of which is, as I said: systemd does not offer a substantial enhancement to system security > He stated nothing about an increased attack surface. He made reference to "baggage" which could mean many things. But either way the argument runs the same: systemd may offer some enhancement to security, but not a substantial one, not one that can only be achieved by using systemd, and not one that's worth the cost of using systemd.
    - agwa 10y ago
      This is exactly my argument! Thank you.

by bkor 10y ago

qwertyuiop924 10y ago

>Systemd makes it easy to add additional limitations to every service you're running So does chroot. And so does jails. And posix capabilities. And cgroups...

darfs 10y ago
I think he is being downvoted because he is factual wrong. Could someone please elaborate with details?
- DyslexicAtheist 10y ago
  one of the arguments against systemd is that it consolidates several scriptable and bug-prone isolated scripts into a binary. This is introducing it's own risks that require upstream interaction to fix a small issue normally a sysadmin without knowledge of C can hot-fix locally. Considering the non existence of a systemd developer community, it's pretty risky. There are similar arguments (pro/against) docker where 2 camps, one saying it's poison & bloat the other the best thing since tabbed browsing. People get so riled up because they're unwilling to acknowledge that they're just tools that make lot sense for solving specific issues. Everyone keeps looking for silver bullets. Problems start when one camp tries to become the de-facto standard (not just the tool but also the processes that come with it). Also people are way to scared of code-forks IMHO. The "fail quick, fail fast" mentality should apply here too. Some healthy competition and a willingness to let certain projects just wither and die should be a good thing ...
  - deleted 10y ago
    [deleted]
  - wtbob 10y ago
    > Considering the non existence of a systemd developer community, it's pretty risky. There's also the fact that it's written in C. Writing security-sensitive software in C in 2016 is, in general, a grievous mistake. No, other languages are not perfect; yes, other languages have their own issues; regardless, C is worse than most. Buffer overflows, memory management, lack of type safety — Just Say No™.
    - qwertyuiop924 10y ago
      It's an acceptable language for writing the piece of software that init is supposed to be. However, systemd is for more complicated and integrated and unsafe than that piece of software.
      - zeveb 10y ago
        > It's an acceptable language for writing the piece of software that init is supposed to be. Is it though? Although I can't think of a lot of vulnerabilities to be concerned of in PID 1, I can think of a few (perhaps something to do with reaping zombies?). Why even allow for that possibility? I see no reason why init(1) couldn't be written in Lisp, or Python (although the speed might not be great), or Go, or Rust, or Haskell, or ML.
        bandrami 10y ago
        PID 1 shouldn't have anything complicated about it. A comp sci student should be able to write it in 10 minutes. This is a solved problem[1]. A run control system, which should be a completely separate project, could easily be written in a higher-level language than C. For instance, the traditional Linux RC system is written in sh, and the official GNU RC system[2] is written in scheme. Daemon run control isn't a domain where performance is crucial; transparency is much more important there, so the argument for using a higher level language to control daemons is pretty strong. [1] http://git.suckless.org/sinit/ http://git.suckless.org/sinit/ [2] https://www.gnu.org/software/shepherd/ https://www.gnu.org/software/shepherd/
bkor 10y ago
It seems you skipped the bit where I said that those restrictions are often shipped by upstream and as such applied to everyone by default? It's one thing to lock down your machine(s), systemd allows to lock down loads of services for everyone. It's not perfect, it doesn't do everything. But is your suggestion really not to make use of systemd abilities because maybe something else could be used? How does this not go against the defence in depth theory? Try and use (filesystem) capabilities. Now apply that security fix: capability is gone. Further, that was just a change made to your machine(s). It seems much easier to improve the security on all fronts instead of going for some idealistic super safe solution that either takes ages or doesn't happen. Example: pretty nice to restrict that Jabber daemon written in Java from accessing too much of the filesystem.
- qwertyuiop924 10y ago
  Well, posix capabilities can be packaged upstream do that. So can Capsicum, for that matter. And so can chroot...
  - bandrami 10y ago
    If only there were a free POSIX-ish OS that did privilege separation and chroot for daemons by default. Perhaps some enterprising Canadian developer could base it on the BSD kernel.
    - qwertyuiop924 10y ago
      Well then, there's your proof.

lmm 10y ago

> Obviously systemd is just one small layer and security is not a yes/no thing. But why then talk specifically about systemd? The article seems to suggest that it's better to not use these abilities. The claim is not that it's better not to use these capabilities (which in any case do not require systemd; there are any number of ways to achieve the same thing). The claim is simply that systemd does not offer a substantial enhancement to system security, and that perhaps the increased attack surface offered by systemd itself outweighs any security benefit it provides to the services running under it.

bkor 10y ago
Stating that his claim is something else doesn't make it true. If you read the article he's saying things such as: 1. Things should be written in different (safer) languages. 2. That a compromise in a mail server is already bad so having systemd protect the mail server according to him does NOT help At least 50% is spend on those bits. Those are poor arguments to make. Systemd adds additional capabilities to make the overall system safer. You can do both. He stated nothing about an increased attack surface.
- lmm 10y ago
  Of course I read the article. Maybe you didn't? > 2. That a compromise in a mail server is already bad so having systemd protect the mail server according to him does NOT help Right, the point of which is, as I said: systemd does not offer a substantial enhancement to system security > He stated nothing about an increased attack surface. He made reference to "baggage" which could mean many things. But either way the argument runs the same: systemd may offer some enhancement to security, but not a substantial one, not one that can only be achieved by using systemd, and not one that's worth the cost of using systemd.
  - agwa 10y ago
    This is exactly my argument! Thank you.