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 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
