Red Hat Bugzilla – Bug 147454
Deamons run in different security contexts
Last modified: 2007-11-30 17:10:59 EST
When a daemon (for instance httpd) is started at boot time, it inherits some of the security context from the init process. For instance, httpd shows: user_u:system_r:httpd_t 7089 ? Ss 0:00 /usr/sbin/httpd The init process itself looks like this: user_u:system_r:unconfined_t 1 ? S 0:01 init [3] However, if the daemon is restarted by running "service httpd restart", it looks like this: root:system_r:httpd_t 8052 ? Ss 0:00 /usr/sbin/httpd The implications of this are related to creation of files performed by Apache daemon. In the first instance, the files will be created like this (again, an example): -rw------- apache apache user_u:object_r:httpd_cache_t __app.dir In the second instance (after the daemon restart), the files will have a different security context: -rw------- apache apache root:object_r:httpd_cache_t __app.dir I guess there should be only one security context for any given daemon.
In the original upstream SELinux, we required users to use the run_init program to run init scripts so that they would transition to the right user identity and role and restarted daemons would inherit them. This was viewed as a useability problem for Fedora, so automatic transitions were introduced for the roles and domains upon running init scripts and daemons, but SELinux does not presently support automatic transitions for user identity; we had always expected user identity transitions to be explicitly performed by authentication programs. In the targeted policy, there is effectively only one user identity and one role anyway; the others are just for compatibility with the strict policy. Only case where this matters is if apache was going to be allowed to relabel its own files (not likely), in which case it might run afoul of the constraint on relabeling files with a different user identity.