Forward looking to FC2 final and SELinux

[Stephen Smalley]

On Thu, 2004-04-08 at 07:35, Stephen Smalley wrote:
> Are you referring to userland SELinux processing?  I think that the
> userland patches are checking /selinux/enforce (via security_getenforce)
> and acting accordingly, so that they also act "permissively" when the
> kernel is in permissive mode.  Or are you referring to some aspect of
> the kernel SELinux processing that is not governed by permissive mode?
> 
> If you are encountering denials in permissive mode, then I'd view that
> as a bug; please report it.

The cases where I know a denial can still occur in permissive mode are:

1) Certains forms of access to /proc/pid/attr nodes are always
prohibited by SELinux (writing to another process' attributes or writing
to one's own current attribute).  But since only SELinux-aware
applications should be writing to /proc/pid/attr nodes (and using the
libselinux functions which only provide legitimate forms of access), and
since these specific forms of access are always prohibited by SELinux,
any such attempt is a bug in the application code.  Hence, I don't see
much point in making this subject to permissive mode.

2) Removing a SELinux xattr from a file is always prohibited by SELinux;
once you've labeled a file, you can relabel it subject to policy (or
without restriction if permissive), but not completely "unlabel" it.  As
there was no equivalent to removexattr in the old SELinux, there was no
permission defined to control such unlabeling, so we simply prohibited
it when we migrated to using xattr.  We could make this restriction
subject to permissive mode, or even introduce a new permission check to
control it so that it can be allowed for trusted processes even in
enforcing mode if necessary.

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