Re: A few observations about systemd
On Mon, Jul 18, 2011 at 3:13 PM, Russell Coker <russell@coker.com.au> wrote:
> 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.
I have some avr32 card with 32Mb that are valuable and do measurement
over network with blas/lapack. 1Mb is a lot of double. Phone is not
the only market.
>
>> 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.
pid == 1 is immortal. I should not get unrecoverable signal like
sigsegv. I could restart other daemon if needed.
> 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.
It is more profound. Pid == 1 could not be killed is it does bad work.
I will prefer a simple init daemon that could spawn a rescue shell if
needed over a ttyS or netconsole. If systemd is stuck I have better
chance to log onto my system. It will save development time.
> 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.
I use to recompile my own kernel. The problem is not init is root and
trusted code, but more init is unkillable.
>
> 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: