No more selinux-policy-*-sources

[Stephen Smalley]

On Tue, 2006-03-14 at 21:35 +0100, Enrico Scholz wrote:
> SELinux is unsuitable for certain tasks (e.g. chroot operations) due to its
> broken/non existent kernel API (requiring two filesystems and operating
> with pathnames is not very efficient, difficultly/insecure and does not
> work in chroots). SELinux seems to have a big performance impact too (I
> remember numbers of 5-7% but did not measured them myself).

To clarify:
- The use of /proc for process security attributes and selinuxfs for
SELinux-specific interfaces was mandated by the kernel developers, who
frown on the introduction of new system calls (which was the original
approach taken when SELinux was a kernel patch).  It does have certain
drawbacks, but also certain advantages, and these APIs are only required
for security-aware applications.
- The SELinux kernel access control mechanism is not path-based; only
the initial assignment of security contexts to files by userspace
components is path-based (using file_contexts); for the runtime security
checks, SELinux uses the inode attributes.  Parallel:  For Linux DAC,
you assign modes and ownerships via utilities like chown/chmod by
specifying the path, and the kernel then applies runtime checks based on
the attributes of the inode.  setfiles even has an option for alternate
roots for that very purpose, to deal with applying file_contexts to a
chroot'd environment.
- I think your actual complaint has more to do with rpm SELinux
integration, which does need improvement.  But that isn't fundamental to
the underlying SELinux mechanism.
- SELinux does have a performance impact, but be careful about mixing
apples and oranges - the numbers I've seen repeatedly cited for AppArmor
appeared to be a comparison of their WebStone results against our dbench
results, and against results published a couple years ago.  Note that
unlike AppArmor, which is doing pathname generation in kernel and regex
matching in kernel, SELinux is just grabbing an incore inode security
value and doing a hash lookup, and our problems in the past with
scalability have been addressed by the conversion of the SELinux AVC to
using RCU by NEC. 

> 'cfengine' provides the largest attack vectors in my systems and I do
> not see how SELinux can help to protect this program.

Perhaps you could clarify why you think that SELinux cannot help with
it?  I haven't looked at cfengine closely myself, so I'm not sure about
its architecture.

-- 
Stephen Smalley
National Security Agency