danwalsh

Ok, this is not really a new feature in Fedora 17.  

systemd has been starting some daemons in Fedora 16, but more and more daemons and privileged processes are being started by systemd in 17.

Why is this a security feature?

Symbols: @ means Execute, -> indicates transition, === indicates a client/server communication

In the past daemons would be started in two ways.  At boot init (sysV) launches an initrc script and then this script would launch the daemon, or an admin could log in and launch the init script by hand causing the daemon to run.

 From an SELinux point of view this looked like:

init_t @ initrc_exec_t -> initrc_t @ httpd_exec_t -> httpd_t: 
This  apache processes would end up running with the full label of:
system_u:system_r:httpd_t:s0
If apache created content it would be labeled
system_u:object_r:httpd_sys_content_rw_t:s0

When an administrator started restarted the process say through service httpd restart
unconfined_t @initrc_exec_t -> initrc_t @httpd_exec_t -> httpd_t
The process would adopt the user portion of the SELinux label that started it
unconfined_u:system_r:httpd_t:s0
Content would be created by this apache would be:
unconfined_u:object_r:httpd_sys_content_rw_t:s0
SELinux ends up confusing the user since we have to ignore the user componant of the SELinux label. If you wanted to write policy to confine based on user type, you can't.

With systemd this improves greatly.

The transitions is very different.
init_t @ httpd_exec_t -> httpd_t
system_u:system_r:httpd_t:s0

But if you want to restart the Apache daemon as admin you now do.
unconfined_t === init_t @ httpd_exec_t -> httpd_t
system_u:system_r:httpd_t:s0

With systemd we don't have the labeling problem and we can tighten up the SELinux policy. 

Systemd starting daemons affects more than just SELinux. 

Over the years lots of vulnerabilities and administration failures had to be worked around because of admins restarting daemons.  Daemons need to be coded to cleanup any leaked information from the admin process influencing the way the Daemon ran.

•     Need to clean $ENV
•     Need to change working directory

        cd / in order to make sure they don't blow up because they lack access to the current working directory (service script does for them).

•     Need do something with the terminal, close stdin, stdout, stderr after they start.

         In SELinux we are always in a quandary about this, since if we allow the daemon access to the terminal, a hacked daemon could present the admin with passwd:  and trick him into revealing the admin password.)

•     Changing the controlling terminal
•     Change the handling of signals
•      ... 

If a daemon writer screws up on one of these he could make the system vulnerable or end up with unexpected bugs. 

Using systemd to start daemons, guarantees the daemon always gets started with  the same environment whether they are started at boot or restarted by an administrator.