Help with domain transitions

[Stephen Smalley]

On Wed, 2005-01-26 at 21:25, David Hampton wrote:
> I'm having trouble getting exim to consistently transition domains so I
> can work on a new policy.  I'm probably overlooking something simple
> here, but I can't figure out what.
> 
> I started with the targeted policy on an up to date FC3 system.  In my
> new exim.te file, I have a daemon_domain(exim, ...) declaration, which
> yields (among other things) the following in the policy.conf file when I
> run make:
> 
> type exim_exec_t, file_type, sysadmfile, exec_type;
> allow initrc_t exim_exec_t:file { { read getattr lock execute ioctl }
> execute_no_trans };
> allow sysadm_t exim_exec_t:file { { read getattr lock execute ioctl }
> execute_no_trans };
> allow initrc_t exim_exec_t:file { read { getattr execute } };
> allow exim_t exim_exec_t:file { read getattr lock execute ioctl };
> allow exim_t exim_exec_t:file entrypoint;
> type_transition initrc_t exim_exec_t:process exim_t;
> 
> The executable is correctly labeled:
> 
> -rwsr-xr-x root root system_u:object_r:exim_exec_t /usr/sbin/exim
> 
> I have run 'make reload', and /var/log/messages shows that the new
> policy file was loaded.  However, when I run exim it still always ends
> up in the unconfined_t domain.  It doesn't matter if I use 'service exim
> restart', 'run_init service exim restart', or start exim by hand.
> 
> If I do a 'make fixfiles' then everything starts working as expected,
> and all three ways of starting exim cause the transition to occur into
> the exim_t domain.
> 
> Perhaps this is because I forcefully (rpm -U --force) reinstalled the
> selinux-policy-targeted RPM the other night after I finished testing
> things?  Something's definitely fubar on my system.

If there isn't a type_transition from unconfined_t (or one of its
aliases, like sysadm_t), then a direct execution of exim won't cause a
transition - you would have to use the init scripts (whether directly or
via /sbin/service or via run_init).  Note that is a deviation from the
default in strict policy, where direct_sysadm_daemon is enabled by
default and direct transitions from sysadm_t are defined.  IIUC, Gentoo
has modified their policy to force people to only run daemons via the
init scripts to ensure that they don't accidentally run them in the
wrong domain.

But the behavior you describe is very odd and might indicate a different
problem that we have seen at times, where the kernel's incore notion of
the inode's security label diverges from the on-disk extended attribute
and doesn't get back into sync unless you manually relabel it.  This
happens when the type on the inode isn't defined in the policy when it
is first brought incore, causing the kernel to label the incore inode
with the unlabeled SID, but ls -Z will show you the on-disk extended
attribute.  Policy reload doesn't automatically walk the list of all
inodes to recheck them, so this won't be correct until you either
manually relabel the file or the incore inode is flushed and
subsequently re-acquired after the type has been defined.  fixfiles
relabel might have yielded the latter result; it wouldn't have actually
relabeled the inode if the on-disk extended attribute was already set
correctly.

-- 
Stephen Smalley <sds at epoch.ncsc.mil>
National Security Agency