Re: A few observations about systemd
On Mon, 18 Jul 2011, Bastien ROUCARIES <roucaries.bastien@gmail.com> wrote:
> Yes but 793691kb of unkillable even by -9 signal is not really nice.
root 1 0.0 1.0 4348 2844 ? Ss May26 0:56 /bin/systemd
--log-level info --log-target syslog-or-kmsg --system --dump-core --show-
status=1 --sysv-console=1 --deserialize 19
Unless systemd locks it's memory (and /proc/1/maps suggests not) then that
will all be demand-paged and probably not much will be used on most systems.
The above is from the ps output from one of my test i386 systems.
root 1 0.0 0.0 2024 132 ? Ss Jan28 5:16 init [2]
The above is from the ps output of one of my i386 servers running Squeeze. It
appears that systemd has allocated an extra 2324K of RAM and has an extra
2712K resident. Given that it's difficult to buy a phone with less than 256M
of RAM nowadays that doesn't seem to be a big problem, and systemd can save
memory by removing the need to run other daemons.
> Better security will need to keep pid==1 to some really simple stuff,
> and delegate funky stuff to another daemon. pid == 1 should be keep
> only to reap zombie process no more.
I think you mean to say that there is a theoretical benefit for reliability
there. As all the things that systemd does will be performed by different
root owned processes in a typical Linux system there won't be much potential
for security benefits in using separate processes. Even with the most strict
configuration of SE Linux the ability to constrain things such as autofs which
can be included in systemd isn't a huge benefit as it's extremely difficult to
constrain them to prevent attack. If your autofs decides to mount an
untrusted device (be it removable media or network) and allow device nodes
and/or SUID binaries then you're going to lose.
Finally vmlinuz is 2.3M compressed on Squeeze and it has a huge amount of code
used for modules. If a serious bug is found in any of that code then nothing
will save you. I don't think that systemd is the security issue.
You could have a HURD system running SE Linux to constrain it's device drivers
which is similar to some research projects that preceded SE Linux and is quite
possible to implement if someone has enough coding time. On such a system
systemd might comprise a significant portion of the code that is highly
trusted. So I would be a lot more inclined to accept an argument for sysvinit
over systemd if it was based on a SE-HURD platform. But SE-HURD doesn't exist
at this time and seems unlikely to exist in the next few years.
--
My Main Blog http://etbe.coker.com.au/
My Documents Blog http://doc.coker.com.au/
Reply to: