Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I’ve since moved away from systemd for all my Linux boxes, work and home.

We still cannot block systemd from making a network socket connection so security model is shot right there by the virtue of systemd running as a root process.

In the old days of systemd, no network sockets were made.

Systemd has become a veritable octopus.

Now, I use openrc and am evaluating S6.



Selinux can block systemd from making network sockets.

What do you mean by "security model" in this case? What model is that?


By "cannot block systemd from making a network socket connection", I think GP meant that your system will break if you block systemd from making network socket connections, not that it's physically impossible to do so.


Yes. If you borked your systemd config file, system-wide failure. Non-bootable, non-useable.

Also if intransigent network connection occurs (fuZzing or not), untested errors occur … notably in PID 1 which isn’t easy to debug.


But the solution is for it to not try make the socket rather than needing another system to correct bad behaviour of the first system?


There ye go. Make system process small as efficient, not to mention easily auditable.


Systemd is already in root mode. Just need to do malicious buffer overruns … somewhere, somehow … at root level … someday.

And it’s codebase is too ginormously huge.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: