cron/init leaking file descriptor?

[Stephen Smalley]

On Tue, 2005-01-04 at 11:30, Tom London wrote:
> Running strict/enforcing, latest Rawhide.
> 
> Started getting these avcs today.
> Jan  4 08:21:28 fedora kernel: audit(1104855688.541:0): avc:  denied 
> { use } for  pid=5131 exe=/usr/sbin/sendmail.sendmail path=/null
> dev=selinuxfs ino=254 scontext=system_u:system_r:system_mail_t
> tcontext=system_u:system_r:init_t tclass=fd
> Jan  4 08:22:21 fedora kernel: audit(1104855741.192:0): avc:  denied 
> { use } for  pid=5286 exe=/usr/sbin/logrotate path=/null dev=selinuxfs
> ino=254 scontext=system_u:system_r:logrotate_t
> tcontext=system_u:system_r:init_t tclass=fd
> 
> My naive reading of this indicates that someone is
> leaving a open file descriptor (to /selinux/null ?)

SELinux re-opens descriptors to /selinux/null if it closes them due to a
lack of sufficient permissions by the new context upon a
context-changing execve.  Getting a denial to a /selinux/null descriptor
itself suggests that there was an earlier denial to a real file (e.g.
the console) that caused the descriptor to be re-opened to /selinux/null
first, and that is now being checked on subsequent execs.  From the
audit message, the descriptor was created in init_t, so it was likely
created when /sbin/init re-exec'd itself into init_t after loading
policy.  Possibly kernel leaking a descriptor again, e.g. to the initial
console or to some file in the initramfs.

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