On 11/02/14 02:05, Yasha Karant wrote:
> On 02/10/2014 02:52 PM, David Sommerseth wrote:
>> On 10/02/14 23:02, Tom H wrote:
>>> To see a "complex" systemd service file, take a look at a Fedora 20
>>> nfs-utils; nfsd is started by three lines:
>>>
>>> ExecStartPre=/usr/lib/nfs-utils/scripts/nfs-server.preconfig
>>> ExecStartPre=/usr/sbin/exportfs -r
>>> ExecStart=/usr/sbin/rpc.nfsd $RPCNFSDARGS $RPCNFSDCOUNT
>>>
>>> I would've used just one ExecStart calling
>>> "/usr/lib/nfs-utils/scripts/nfs-server.script" but the maintainer
>>> clearly disagrees. :)
>> Yeah, and I can actually understand a little bit why.  Because systemd
>> can track the services it has started quite carefully, even after they
>> have been started.  And can take actions if they die.  By starting those
>> three from a single script, it would only be able to track that script
>> and not all those "features" the script starts.
>>
>> Another thing is that logging can be somewhat simpler too, and you are
>> always guaranteed that logging goes via systemd, even things which goes
>> to stdout (and stderr? I don't recall now).  A script can easily do odd
>> tweaks there too.
>>
>> So by doing as much as possible in the systemd unit file, it gets less
>> convoluted and a bit easier to follow what should happen if you need to
>> debug.
>
> Does this not make systemd a prime target for attack and compromise? 
> How hardened is systemd?

Not sure if I fully understand your question.  How is this different
from sys-v init?

systemd just have the infrastructure to pay more closely attention to
the processes it has started, and logs better what those processes do
(by proxy the log data to the journal and syslog).  To me it's kind of
touching the areas of DJB's daemontools.

Other than that, systemd uses SELinux to ensure automatic starting of
services (via dbus) happens by users/processes allowed to do so.  So
f.ex. httpd won't be able to trigger systemd to start sshd (or even
worse, telnetd or some other unknown service) ... This is probably the
area which sys-v init couldn't really handle well at all.

Normal users wouldn't be able to add/modify services either, without
root permission (unless the permissions on the systemd config files is
wrong, just as the case with sys-v init)


--
kind regards,

David Sommerseth