/selinux/null being labeled as root_t?

[Stephen Smalley]

On Fri, 2005-01-14 at 11:47, Colin Walters wrote:
> Hi,
> 
> I'm seeing an odd denial on my FC2 server after the latest kernel
> updates.
> 
> Jan 14 11:38:15 monk kernel: audit(1105720695.913:0): avc:  denied  { getattr } for  pid=6661 exe=/usr/sbin/sendmail.postfix path=/null dev=selinuxfs ino=189 scontext=zosima:staff_r:staff_mail_t tcontext=system_u:object_r:root_t tclass=chr_file
> 
> So this is the /selinux/null file, which should be labeled with
> security_t, correct?  My genfscon file just has:
> 
> # selinuxfs
> genfscon selinuxfs /                    system_u:object_r:security_t
> 
> I'm pretty sure this is a kernel problem since I haven't changed my
> policy in some time.
> 
> (Yes, I plan to upgrade to FC3 soon :))

This is one of the problems that surfaced a long time ago in FC2 because
of a lack of any coordinated policy update for the kernel updates.  When
we introduced the code to re-open descriptors to the null device when
SELinux closes them upon a context-changing execve, we defined and used
an initial SID to label the null device node, as it is setup before
initial policy load and is assigned directly by the kernel.  That
required a coordinated policy change to define the initial SID and
assign it a security context.  In the absence of such a policy
definition, the initial SID value being used by the kernel is just
getting re-used for some dynamically allocated SID, in this case, the
SID of the first inode brought incore.  So you need to update your
policy to include the definition in initial_sids and
initial_sid_contexts, and reboot (as initial SID changes can only take
affect during initialization, not upon a policy reload).

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