Linked by Thom Holwerda on Wed 26th Sep 2007 19:23 UTC
KernelTrap offers a summary of a lengthy debate on OpenBSD's -misc mailing list comparing the security features built into OpenBSD versus the security offered by the Linux kernel's SELinux feature. The main arguments presented against SELinux centered around its complexity and the difficulty of defining a secure policy. "The first thing people usually do with SELinux is turn it off", suggests the article, noting that the ease with which it can be turned off is another security shortcoming. By contrast, OpenBSD offers numerous security features that are always enabled with minimal overhead, including propolice stack protection, random library mappings, proactive privilege separation, W^X, and systrace.
Thread beginning with comment 274653
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
Member since:2006-02-12
Member since:2006-08-18
Fedora is not an enterprise distribution ...
Fedora is a stable test bed for an enterprise distribution.
Therefore, except for a long product life cycle and a commercial support infrastructure, Fedora contains most of the properties (features) of the enterprise version.
Member since:2006-08-01
Member since:2006-02-09
The word "enterprise" has lost all meaning to me... Using rpmfind.net to get stuff? Yikes. Just because it meets a goverment certification doesn't make it good (possibly the opposite). I would take Debian Stable over RHEL/Fedora any day if nothing else due to the ease of installing updates.
Recent Original Stories
Recent Comments
Headlines
Random Comments
Random Stories
Random OS Link
Member since:
2006-08-18
SELinux happens to be only one element of security: Mandatory Access Control. Enterprise OSes like RHEL and Fedora offer a whole array of security innovations on top of SELinux.
SELinux is troublesome because of it's inability to dynamically train/optimize itself for the changing requirements of users--or at least in a seamless and discreet manner. If a program violates a policy rule, the program just wont launch and the user will have no clue why until he happens to discover audit.log and can read verbose data or if they happen to have the "settroubleshoot" daemon and notify utility installed.
Making SELinux more flexible requires manual training. This involves creating policy modules based on security denial error logs and bypassing protection for certain "safe" applications and libraries, by using tools like audit2allow, chcon, restorecon.
The above is an unideal solution because its time consuming and unintuitive to the user. The ideal solution would be for SELinux to evolve into a more automated and dynamic MAC system that can learn and optimize security policies based on computer usage patterns and scenarios.
Edited 2007-09-26 20:59