On Thu, 2005-06-23 at 11:58 -0700, stewartetcie@xxxxxxxxxx wrote: > Beware of forks masquerading as subsystems. The offer > of mandatory access control is seductive, but the > SELinux implementation is flawed if it amounts to a > fork in the Linux code base. It doesn't. SELinux is upstream, in the mainline kernel. No forking here. > If that were the only problem, it would be enough to > preclude the inclusion of SELinux from a general > purpose Linux distribution until such time as good > management tools are available. Chicken and the egg problem. People aren't motivated to create good management tools until they see that the system is mainstream. What management tools exist for POSIX ACLs on Linux? Yet the kernel mechanism is included, which allows people who want to do so to leverage them. In much the same way, including SELinux with a relatively simple policy (targeted) is a natural first step. And there are certainly other kernel features that have followed the same path. > One candidate is Linux (a. k. a. non-SELinux). If I > have to roll my own distro from Fedora in order to > optimize performance by removing unnecessary > subsystems, such as mandatory access control on an > isolated system, then Fedora is no longer a general > purpose system and it is no longer Linux, now it is > SELinux. Um, no. First, you can completely disable SELinux, at which point it is no longer registered with the kernel's security framework and imposes no performance overhead. That actually goes well beyond what many kernel features offer, most of which are going to be enabled in a stock Fedora kernel simply because it is intended for general use. Second, you always have the freedom to rebuild the Fedora kernel SRPM or an upstream kernel with SELinux completely omitted. You are applying an unfair criteria to SELinux that doesn't exist for any other kernel feature. > These comments are offered in the spirit of > constructive criticism. I'm grateful you declared your > bias, for your spirited defence of your product and > very grateful SELinux was contributed to the open > source community, warts and all. However, SELinux isn't > the only possible implementation of mandatory access > control for Linux (cf. sHype). If my criticicms are > valid, SELinux must either be improved, or it'll be > replaced by a better implementation. Perhaps I'm wrong. > Time will tell. Meanwhile, thanks for listening. It is certainly true that SELinux is not the only possible implementation of MAC for Linux, although I think you are misunderstanding the sHype report itself (don't confuse their explanation of how virtualization offers stronger isolation with fewer shared resources vs. finer-grained controlled sharing available via OS-level controls as a criticism of OS-level MAC - they are just explaining the differing roles played by virtualization vs. OS-level controls). And you are certainly free to use any such alternative MAC implementation you wish; just disable SELinux (via selinux=0 in your grub.conf or via /etc/selinux/config SELINUIX=disabled) and load your favorite loadable module (of course, if your alternative MAC implementation requires a kernel patch, then you'd need to rebuild your kernel with that patch, but that is not affected by SELinux in any way). So your freedom is not limited in any manner by SELinux being included in Fedora. But remember that SELinux is: - upstream (in the mainline Linux 2.6 kernel), - open source (kernel code and userland and policy), - a truly community-based project (with significant contributions by external developers and users) ever since its initial release by the NSA in 2000, - a generalized access control architecture and model suitable for a general purpose operating system, - extensible to support application security needs. So don't dismiss it too quickly. Thanks ;) -- Stephen Smalley National Security Agency -- fedora-selinux-list mailing list fedora-selinux-list@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-selinux-list
