On Mon, Jul 18, 2011 at 3:13 PM, Russell Coker <russ...@coker.com.au> wrote: > On Mon, 18 Jul 2011, Bastien ROUCARIES <roucaries.bast...@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/ > -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cae2spaargyz6c_xdnk_vpj_wuhbmtuoogxzv_d1nw12qs0y...@mail.gmail.com
