On Wed, Oct 22, 2014 at 2:30 PM, <Valdis.Kletnieks@vt.edu> wrote:
On Wed, 22 Oct 2014 13:13:29 -0600, John Schiel said:
i was beginning to wonder how secure systemd is also.
One of the 3 CIA pillars of security is "availability". And if it's oh-dark-30, figuring out what symlink is supposed to be where for a given failed systemd unit can be a tad challenging. At least under sysvinit, either /etc/rc5.d/S50foobar is there or it isn't(*).
How long has it been since you've looked at/used systemd? Manual management of symlinks to control what services are started at boot time are a thing of the past. "systemctl enable|disable|status <service>" will handle all of that for you. I agree, managing symlinks was annoying in the early systemd days, but I haven't messed with those symlinks manually in a long time, except to remove orphan symlinks caused by services that weren't removed cleanly from the system. I think your fear comes more from a lack of familiarity with systemd, rather than a true technical deficit. Personally I find systemd services much easier to debug, especially since stderr and stdout from all services is captured, rather than being lost to /dev/null. I find it VERY annoying that many init.d scripts eventually boil down to "/usr/sbin/program --someflags 2>&1 > /dev/null &".
And if they carry through on their systemd-console threat, that could get even worse - that introduces a whole new pile of risks for being unable to diagnose early boot bugs
I haven't seen much about systemd-console, but I thought that this reddit thread was interesting. http://www.reddit.com/r/linux/comments/1rmj9e/systemd_is_about_to_gain_a_sys... It seems to me that moving VTs out of the kernel and into a userspace process would be a good thing. I guess one could argue about whether systemd is the right place for it, but as you can see from that reddit thread there have been a number of other projects that have attempted to do that but have failed to gain traction for one reason or another. One thing that the systemd developers are undeniably good at is getting their work adopted by the distributions.
So yeah, there's security issues other than "can it be hacked because it's got a huge surface area".
Nothing new here. And before you get started, Bash and OpenSSL prove that old code isn't necessarily secure code. -- Jeff Ollie