[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: