[ale] systemd

Jim Kinney jkinney at jimkinney.us
Tue Dec 8 13:12:40 EST 2015


I can't directly and fully address all of the nuances but ...
All of the inits that use a scripting language that run in a shell
require a fully working system to launch the shell. Debian and RHEL
worked around this with dash and nash, very limited shells that could
run init scripts. That was a step in the right direction. But the
desire to have as many system services running with similar strict
security controls as is found in the kernel is a reason to work for a
different way to init the system.
By using a compiled init, and specifically one that uses all the same,
and only the same libs used by the kernel build, it puts the init
startup closer (in a sense) to the kernel and the kernel level
security. For systems that need to be hardened, apparmor/selinux
security is mandatory and an init that runs almost within the security
tool start up process will have a tighter security process as nothing
will be started in the wild.
It's not a perfect system as there are ways that jailbreak kernel
security. Most involve bugs in glibc or the kernel itself. Those get
found and fixed (usually) pretty quickly. So using  systemd, and it
uses glibc (and some other libs that are "core" to modern Linux
systems), fixes to glibc fix systemd as well (I'm ignoring the built-in 
bugs that all code brings).
It's not a guarantee of better security but it's an opportunity for
such.
Can other inits do the same. Of course those that follow a similar
process will. Can a scripted init do it? Maybe if the all of the shell
parts used were under the same level of kernel security that is being
worked with using systemd. The shell can only fork a process under
special circumstances and that requires special blessings, etc...
On Tue, 2015-12-08 at 11:39 -0500, leam hall wrote:
> At this point I'm echoing what I heard. Admittedly, the source was
> reliable but also had probably just heard me complain about systemd.
> I
> don't think the context was "only systemd" can do this, but that it
> did it much better than init scripts.
> 
> Like I said, I've not proven it fully, but was interested to have
> heard at least one positive comment.
> 
> 
> On Tue, Dec 8, 2015 at 11:34 AM, James Sumners 
> om> wrote:
> > Such as? As far as I'm aware it just uses cgroups:
> > 
> > https://www.kernel.org/doc/Documentation/cgroups/
> > https://sysadmincasts.com/episodes/14-introduction-to-linux-control
> > -groups-cgroups
> > 
> > Which is completely scriptable.
> > 
> > On Tue, Dec 8, 2015 at 10:56 AM, leam hall <leamhall at gmail.com>
> > wrote:
> > > 
> > > Okay, I finally heard one positive comment on systemd. It allows
> > > some
> > > of the more granular kernel security controls that init scripts
> > > don't.
> > > Not that I'm totally happy, but this is something to go look more
> > > at.
> > > 
> > > Leam
> > > 
> > > --
> > > Mind on a Mission
> > > _______________________________________________
> > > Ale mailing list
> > > Ale at ale.org
> > > http://mail.ale.org/mailman/listinfo/ale
> > > See JOBS, ANNOUNCE and SCHOOLS lists at
> > > http://mail.ale.org/mailman/listinfo
> > 
> > 
> > 
> > 
> > --
> > James Sumners
> > http://james.sumners.info/ (technical profile)
> > http://jrfom.com/ (personal site)
> > http://haplo.bandcamp.com/ (band page)
> > 
> > _______________________________________________
> > Ale mailing list
> > Ale at ale.org
> > http://mail.ale.org/mailman/listinfo/ale
> > See JOBS, ANNOUNCE and SCHOOLS lists at
> > http://mail.ale.org/mailman/listinfo
> > 
> 
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ale.org/pipermail/ale/attachments/20151208/54703f5d/attachment.html>


More information about the Ale mailing list