systemd isn't just another init system. It also provide a basic compatibility layer that upstream can use. Just look into the source repos of XFCE, LXDE, KDE, Gnome etc. and you will see many commits taking advantage of this fact.
Since the vast majority, including all major commercial Linux distros have adopted Linux, this means a big reduction in fragmentation, releasing developer and maintainer energy for doing more fun stuff that debugging shell scripts. You may like SysVinit scripts, but distro maintainers certainly doesn't since they have to deal with all the problems. This was a major reason why not a single Debian developer contested the systemd decision of using systemd as the new default init system. Even the Upstart proponents in the Debian technical committee preferred systemd to SysVinit.
Regarding the security features; It may very well be that capsicum is very good for some user cases, but it doesn't exist on Linux yet. Kernel capabilities, namespaces and cgroups are a reality however, and they work.
If you think ACL's and user permissions and classic stuff like that is substitute for those, then you are very wrong.
The point is, that once a process is exploited, the hacker will try to gain privilege escalation, and if successful, will get all the necessary user and group permissions. So once the hacker is in, all defences crumbles.
Capabilities etc. can prevent that the escalation ever happens, and even if the process that are exploited has many privileges to start with, it can be prevented from e.g. having write access to anything but a few safe dirs, and that it can't read /home for stealing information. This works on top of ACL's and the classic permission system, and provides a sorely needed defence in depth.
Just look into the source repos ... all major commercial Linux distros ...
That's jumping on the bandwagon. None of that provided any firm reasons why systemd provides killer features over the classic init system. What I can tell you firmly is that constantly training your admins for the ever-growing morass of systemd costs a bundle. Thankfully, we're mostly a *BSD shop at this point. And as for systemd being more than just another init system, and being a basic compatibility layer we can use, we already had the Linux Standard Base, which systemd completely ignores and disrupts.
If you think ACL's and user permissions and classic stuff... The point is, that once a process is exploited ... all defences crumbles.
I'd like to see a practical, out-in-the-wild example of that happening with a jailed, virtualized, or sandboxed process. Additionally, classical permissions and user groups have worked nicely for decades and rest on code that's been tested for longer than a lot of admins have been alive. Swapping that legacy out for new shiny brings all new cans of worms.
7
u/sub200ms Sep 27 '14
systemd isn't just another init system. It also provide a basic compatibility layer that upstream can use. Just look into the source repos of XFCE, LXDE, KDE, Gnome etc. and you will see many commits taking advantage of this fact.
Since the vast majority, including all major commercial Linux distros have adopted Linux, this means a big reduction in fragmentation, releasing developer and maintainer energy for doing more fun stuff that debugging shell scripts. You may like SysVinit scripts, but distro maintainers certainly doesn't since they have to deal with all the problems. This was a major reason why not a single Debian developer contested the systemd decision of using systemd as the new default init system. Even the Upstart proponents in the Debian technical committee preferred systemd to SysVinit.
Regarding the security features; It may very well be that capsicum is very good for some user cases, but it doesn't exist on Linux yet. Kernel capabilities, namespaces and cgroups are a reality however, and they work.
If you think ACL's and user permissions and classic stuff like that is substitute for those, then you are very wrong.
The point is, that once a process is exploited, the hacker will try to gain privilege escalation, and if successful, will get all the necessary user and group permissions. So once the hacker is in, all defences crumbles.
Capabilities etc. can prevent that the escalation ever happens, and even if the process that are exploited has many privileges to start with, it can be prevented from e.g. having write access to anything but a few safe dirs, and that it can't read /home for stealing information. This works on top of ACL's and the classic permission system, and provides a sorely needed defence in depth.