Long story but in redhat distro's you can ignore that.
By default he identity field in a security context is only used to map
roles, sensitivities and compartments to linux logins.
The system_u identity is used for init and its children.
Back in the old days one was required to restart processes on behalf of
the system with the run_init command (example: run_init service httpd
The run_init command would make sure that the process was started with
the right context.
Later when the unconfined domain was introduced, for some reason, this
was abandoned and instead unconfined_r:unconfined_t was allowed to role
and domain transition to system_r:initrc_t upon executing init script
executable files, among other things like role and domain transitioning
to system_r:rpm_t upon running yum or rpm executable files.
The identity field however isnt changed if you dont use run_init.
It does not matter often since by default the identity field is only
used to map roles, sensitivities and compartments to linux users.
There are almost no rules or constraints that use this field.
Unless one enabled the optional user based access control security
model. This is a security model that uses the identity field to isolate
processes with the selected identities. Isolate users.
But this ubac security model is not enabled in redhat distributions.
So the tl;dr is:
if you really want processes you run on behalf of the system to have the
system_u identity then use run_init:
run_init service bla restart
run_init yum update
This is mandatory if you tuned your targeted policy to require confined
But in a stock redhat distro where users are not targeted and are mapped
to unconfined_u by default this is not required and you can ignore the
first field in security contexts.
I hope this helps
On Wed, 2012-08-22 at 15:36 -0400, Michael Hampton wrote:
I am trying to write a SELinux policy for a daemon which will be
started from an init script on CentOS 6. I seem to be most of the way there, except when
running its init script (with "service bitcoin start"), the daemon starts and
runs as unconfined_u:
ps -eZ | grep bitcoin
unconfined_u:system_r:bitcoin_t:s0 19993 ? 00:00:00 bitcoind
I generated the policy using selinux-polgengui which was included with CentOS 6 selecting
"Standard Init Daemon".
The init script seems to be correctly labeled:
root@buildbox-el6 ~ # ls -Z /etc/rc.d/init.d/bitcoin
-rwxr-xr-x. root root system_u:object_r:bitcoin_initrc_exec_t:s0
The daemon also seems to be correctly labeled:
root@buildbox-el6 ~ # ls -Z /usr/sbin/bitcoind
-rwxr-xr-x. root root system_u:object_r:bitcoin_exec_t:s0 /usr/sbin/bitcoind
The bitcoin.if and bitcoin.te are as generated by the tool, though I can provide them if
I expected the daemon to run as system_u. When the system boots, the daemon is started as
system_u as expected, but not when I start or restart it with 'service bitcoin
restart'. What's going on here and how do I fix it?
selinux mailing list