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@xxxxxxxxxxxxxx> National Security Agency
