5 ms·

> PID 1 brings down the whole system when it crashes. This matters because systemd is complex. The Linux kernel is much more complex and also brings down the w

by oofabz 13y ago

> PID 1 brings down the whole system when it crashes. This matters because systemd is complex. The Linux kernel is much more complex and also brings down the whole system when it crashes. > Attack Surface Sysvinit runs shell scripts and has known race conditions. A system like that is not secure by design. It is as secure as it is because exploits were fixed one by one over the years. > Reboot to Upgrade You must also reboot to upgrade sysvinit.

InclinedPlane 13y ago
See what happens when you kill PID 1 on a system using sysvinit.
- munchhausen 13y ago
  On Linux, nothing: The only signals that can be sent to process ID 1, the init process, are those for which init has explicitly installed signal handlers. This is done to assure the system is not brought down accidentally. (From kill(2)) In practice, you will find that: kill(1, SIGKILL) = 0 results in exactly...no effect.
  - nailer 13y ago
    It's also because Unix doesn't generally believe in being forgiving (or, UX in general): someapp & [job 1 backgrounded] kill %1 (job 1 is killed - yep, you can use kill for jobs) Miss a percent there? You've just sent a TERM to init.
    - srd 13y ago
      Which won't matter if you're a normal user. If you're root - why are you using the job system to kill your jobs?
      - nailer 13y ago
        > If you're root - why are you using the job system to kill your jobs? Probably because you know the features of your shell and enjoy productivity.
      - yk 13y ago
        Because thats a job for kill.
  - belorn 13y ago
    I wonder what would happen if you used OOM_Killer on process ID 1.
    - makomk 13y ago
      PID 1 is meant to be immune to the OOM killer. Last time I did development work in that area, it was also impossible to attach a debugger to PID 1 without patching the kernel, and although it worked I'm not sure how safe it was to do so.
      - zx2c4 13y ago
        zx2c4@thinkpad ~ $ sudo strace -p 1 Process 1 attached select(11, [10], NULL, NULL, {1, 122329}) = 0 (Timeout) stat("/dev/initctl", {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0 fstat(10, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0 stat("/dev/initctl", {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0 select(11, [10], NULL, NULL, {5, 0}) = 0 (Timeout) stat("/dev/initctl", {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0 fstat(10, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0 stat("/dev/initctl", {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0 select(11, [10], NULL, NULL, {5, 0}^CProcess 1 detached <detached ...> Ptracing seems to work for me.
uggedal 13y ago
> You must also reboot to upgrade sysvinit. The whole point of the article is that you don't need to upgrade sysvinit or another minimal /sbin/init like those found in the BSDs.
- adobriyan 13y ago
  The argument is kinda weak given how many kernel updates are there and how often they come (and kernel upgrade _requires_ reboot regardless of PID 1).
  - michaelmior 13y ago
    Not necessarily. Ksplice[1] for example allows the kernel to be upgraded without rebooting. [1] https://www.ksplice.com/ https://www.ksplice.com/
dredmorbius 13y ago
It is as secure as it is because exploits were fixed one by one over the years. That's largely how things get secure. Though pre-emptive security through code audits and library rewriting (the OpenBSD approach) also helps. Init scripts have had those years. Systemd has not.
- akerl_ 13y ago
  Yes, but we didn't decide to not use sysvinit on those grounds. It's quite a nifty case to make, that we can't use a new init system because we haven't used the new init system for a long time already to find the bugs.
  - ZeroGravitas 13y ago
    That actually strikes me as a more reasonable objection than many I've heard. On the other hand, systemd is actually in use in various places, so bugs are being looked for and found, so this process doesn't begin with Debian's adoption and you're back to balancing probababilities the same as you would with any change.
    - belorn 13y ago
      > Debian's adoption In this case, adoption means moving systemd from being optional to default. Debian has had systemd in use for quite a while now with current statistics at 7.5% of all installation (accordingly to popcon http://qa.debian.org/popcon.php?package=systemd http://qa.debian.org/popcon.php?package=systemd).
      - bbanyc 13y ago
        Package names are a bit confusing here. The systemd package includes all the binaries - one of which, logind, is required by GNOME - but doesn't install systemd as /sbin/init and doesn't boot with it by default. The package to do that is called systemd-sysv, for reasons having to do with the special treatment of sysvinit as a "required" package in dpkg. So 7.5% of Debian systems have it installed, but only about 0.3% (plus however many of that 7.5% that are setting init=systemd in GRUB) are using it.
lelf 13y ago
> The Linux kernel is much more complex and also brings down the whole system when it crashes Yeah. And there is nothing good about it. > Sysvinit runs shell scripts and has known race conditions Bugs can be everywhere. But the smaller the paramount part the better. > You must also reboot to upgrade sysvinit You don't
- sspiff 13y ago
  >> The Linux kernel is much more complex and also brings down the whole system when it crashes > Yeah. And there is nothing good about it. I beg to differ, and I think a lot of people will disagree with you. Regardless, your snarky remark fails to state any problems with the Linux kernel, or identify what you consider a "good" kernel.
  - ptr 13y ago
    He's probably thinking about some kind of micro kernel (which are pretty cool), or redundant CPUs (which probably wouldn't help much)?
  - _quasimodo 13y ago
    I think he meant there is nothing good about complexity and bringing down the whole system on a crash. For the Linux kernel this is probably an unfortunate necessity, for an init system it is not.
tonyskn 13y ago
> Reboot to Upgrade This is not needed anymore. Check systemd's manual for 'systemd daemon-reexec'
- pmr_ 13y ago
  The article specifically addresses this feature, but I'm not knowledgeable enough about the topic to judge the quality of the argument.
  - makomk 13y ago
    So, I used to vaguely help develop another proposed init replacement a few years ago, and it's entirely correct. The only way to upgrade init is to have it dump state and re-exec() itself, and there are theoretical failure modes that will cause init to crash before it's even possible to set up a crash handler to catch the problem, causing a kernel panic. What's more, supporting upgrades this way means you need to support every previous state file format, and the more state and features there are the harder this is to do. (Seriously, it was a pain in the butt to keep track of.) systemd is developed primarily by and for Red Hat who avoid this problem by not supporting upgrades to a new distro release from within the running system - but most other major distros do and will likely be bitten hard by the issue. Without support for this you can't even reboot cleanly after upgrading init or any of the libraries it uses, because init will keep old deleted executable open and make it impossible to remount root as read-only (an obscure quirk of Unix filesystems that basically only init developers need to know). You don't just need to reboot to upgrade init, you need to boot into a special upgrade environment that doesn't use the system's init, and Fedora does. That's why Fedora needs daemon-reexec - otherwise they wouldn't even be able to apply security updates to glibc without rebooting first. Compare this with kernel upgrades, which can be installed immediately and simply don't take effect until the next reboot.
    - andor 13y ago
      Without support for this you can't even reboot cleanly after upgrading init or any of the libraries it uses, because init will keep old deleted executable open and make it impossible to remount root as read-only Lennart Poettering on how this is done in systemd: https://plus.google.com/+LennartPoetteringTheOneAndOnly/posts/LjkLwkeDiLc https://plus.google.com/+LennartPoetteringTheOneAndOnly/post...
epsylon 13y ago
You have completely missed the point of the article. So if not systemd, what? Debian's discussion of whether to adopt systemd or not basically devolved into a false dichotomy between systemd and upstart. And except among grumpy old luddites, keeping legacy sysvinit is not an attractive option. So despite all its flaws, is systemd still the best option? No. After which he proceeds to explain how to solve points 1, 2, and 3 by moving most tasks out of PID 1.
Elhana 13y ago
Linux kernel is maintained by sane people, unlike systemd/udev: http://article.gmane.org/gmane.linux.kernel/1369384 http://article.gmane.org/gmane.linux.kernel/1369384

by oofabz 13y ago

InclinedPlane 13y ago

See what happens when you kill PID 1 on a system using sysvinit.

munchhausen 13y ago
On Linux, nothing: The only signals that can be sent to process ID 1, the init process, are those for which init has explicitly installed signal handlers. This is done to assure the system is not brought down accidentally. (From kill(2)) In practice, you will find that: kill(1, SIGKILL) = 0 results in exactly...no effect.
- nailer 13y ago
  It's also because Unix doesn't generally believe in being forgiving (or, UX in general): someapp & [job 1 backgrounded] kill %1 (job 1 is killed - yep, you can use kill for jobs) Miss a percent there? You've just sent a TERM to init.
  - srd 13y ago
    Which won't matter if you're a normal user. If you're root - why are you using the job system to kill your jobs?
    - nailer 13y ago
      > If you're root - why are you using the job system to kill your jobs? Probably because you know the features of your shell and enjoy productivity.
    - yk 13y ago
      Because thats a job for kill.
- belorn 13y ago
  I wonder what would happen if you used OOM_Killer on process ID 1.
  - makomk 13y ago
    PID 1 is meant to be immune to the OOM killer. Last time I did development work in that area, it was also impossible to attach a debugger to PID 1 without patching the kernel, and although it worked I'm not sure how safe it was to do so.
    - zx2c4 13y ago
      zx2c4@thinkpad ~ $ sudo strace -p 1 Process 1 attached select(11, [10], NULL, NULL, {1, 122329}) = 0 (Timeout) stat("/dev/initctl", {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0 fstat(10, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0 stat("/dev/initctl", {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0 select(11, [10], NULL, NULL, {5, 0}) = 0 (Timeout) stat("/dev/initctl", {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0 fstat(10, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0 stat("/dev/initctl", {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0 select(11, [10], NULL, NULL, {5, 0}^CProcess 1 detached <detached ...> Ptracing seems to work for me.

uggedal 13y ago

> You must also reboot to upgrade sysvinit. The whole point of the article is that you don't need to upgrade sysvinit or another minimal /sbin/init like those found in the BSDs.

adobriyan 13y ago
The argument is kinda weak given how many kernel updates are there and how often they come (and kernel upgrade _requires_ reboot regardless of PID 1).
- michaelmior 13y ago
  Not necessarily. Ksplice[1] for example allows the kernel to be upgraded without rebooting. [1] https://www.ksplice.com/ https://www.ksplice.com/

dredmorbius 13y ago

It is as secure as it is because exploits were fixed one by one over the years. That's largely how things get secure. Though pre-emptive security through code audits and library rewriting (the OpenBSD approach) also helps. Init scripts have had those years. Systemd has not.

akerl_ 13y ago
Yes, but we didn't decide to not use sysvinit on those grounds. It's quite a nifty case to make, that we can't use a new init system because we haven't used the new init system for a long time already to find the bugs.
- ZeroGravitas 13y ago
  That actually strikes me as a more reasonable objection than many I've heard. On the other hand, systemd is actually in use in various places, so bugs are being looked for and found, so this process doesn't begin with Debian's adoption and you're back to balancing probababilities the same as you would with any change.
  - belorn 13y ago
    > Debian's adoption In this case, adoption means moving systemd from being optional to default. Debian has had systemd in use for quite a while now with current statistics at 7.5% of all installation (accordingly to popcon http://qa.debian.org/popcon.php?package=systemd http://qa.debian.org/popcon.php?package=systemd).
    - bbanyc 13y ago
      Package names are a bit confusing here. The systemd package includes all the binaries - one of which, logind, is required by GNOME - but doesn't install systemd as /sbin/init and doesn't boot with it by default. The package to do that is called systemd-sysv, for reasons having to do with the special treatment of sysvinit as a "required" package in dpkg. So 7.5% of Debian systems have it installed, but only about 0.3% (plus however many of that 7.5% that are setting init=systemd in GRUB) are using it.

lelf 13y ago

> The Linux kernel is much more complex and also brings down the whole system when it crashes Yeah. And there is nothing good about it. > Sysvinit runs shell scripts and has known race conditions Bugs can be everywhere. But the smaller the paramount part the better. > You must also reboot to upgrade sysvinit You don't

sspiff 13y ago
>> The Linux kernel is much more complex and also brings down the whole system when it crashes > Yeah. And there is nothing good about it. I beg to differ, and I think a lot of people will disagree with you. Regardless, your snarky remark fails to state any problems with the Linux kernel, or identify what you consider a "good" kernel.
- ptr 13y ago
  He's probably thinking about some kind of micro kernel (which are pretty cool), or redundant CPUs (which probably wouldn't help much)?
- _quasimodo 13y ago
  I think he meant there is nothing good about complexity and bringing down the whole system on a crash. For the Linux kernel this is probably an unfortunate necessity, for an init system it is not.

tonyskn 13y ago

> Reboot to Upgrade This is not needed anymore. Check systemd's manual for 'systemd daemon-reexec'

pmr_ 13y ago
The article specifically addresses this feature, but I'm not knowledgeable enough about the topic to judge the quality of the argument.
- makomk 13y ago
  So, I used to vaguely help develop another proposed init replacement a few years ago, and it's entirely correct. The only way to upgrade init is to have it dump state and re-exec() itself, and there are theoretical failure modes that will cause init to crash before it's even possible to set up a crash handler to catch the problem, causing a kernel panic. What's more, supporting upgrades this way means you need to support every previous state file format, and the more state and features there are the harder this is to do. (Seriously, it was a pain in the butt to keep track of.) systemd is developed primarily by and for Red Hat who avoid this problem by not supporting upgrades to a new distro release from within the running system - but most other major distros do and will likely be bitten hard by the issue. Without support for this you can't even reboot cleanly after upgrading init or any of the libraries it uses, because init will keep old deleted executable open and make it impossible to remount root as read-only (an obscure quirk of Unix filesystems that basically only init developers need to know). You don't just need to reboot to upgrade init, you need to boot into a special upgrade environment that doesn't use the system's init, and Fedora does. That's why Fedora needs daemon-reexec - otherwise they wouldn't even be able to apply security updates to glibc without rebooting first. Compare this with kernel upgrades, which can be installed immediately and simply don't take effect until the next reboot.
  - andor 13y ago
    Without support for this you can't even reboot cleanly after upgrading init or any of the libraries it uses, because init will keep old deleted executable open and make it impossible to remount root as read-only Lennart Poettering on how this is done in systemd: https://plus.google.com/+LennartPoetteringTheOneAndOnly/posts/LjkLwkeDiLc https://plus.google.com/+LennartPoetteringTheOneAndOnly/post...

epsylon 13y ago

You have completely missed the point of the article. So if not systemd, what? Debian's discussion of whether to adopt systemd or not basically devolved into a false dichotomy between systemd and upstart. And except among grumpy old luddites, keeping legacy sysvinit is not an attractive option. So despite all its flaws, is systemd still the best option? No. After which he proceeds to explain how to solve points 1, 2, and 3 by moving most tasks out of PID 1.

Elhana 13y ago

Linux kernel is maintained by sane people, unlike systemd/udev: http://article.gmane.org/gmane.linux.kernel/1369384 http://article.gmane.org/gmane.linux.kernel/1369384