On 24.09-10:25, Jason Dixon wrote: [ ... ] > > What I'm trying to say is that all the services I listed before make > > their own little SELinux layer with appropriate policy built into > > them. Better than SELinux though is that the monitor is enabled by > > default and generally can't be turned off. Even more interesting is > > that this policy enforcement is portable to other unix like operating > > systems, it's not restricted to the OpenBSD kernel. > > What makes this so effective is that it's built-in by the people > who understand it best, the developers. Not some Jr. Sysadmin tasked > with standing up a new Linux server and trying to write his own SELinux > policy from scratch.
little sad to see such slating of extended security feature sets by such a security conscious group. policy cannot be defined or implemented in the application. it must be enforced by the kernel to be meaningful. this, of course, does not preclude privilage seperation within an application but that is good application programming not secure policy. SELinux's policy features are a superset of standard Unix. I was unaware of 'systrace' in openbsd but have found these poor and cumbersome previously but will certainaly review it. i agree completely with the general tack of opinion here, there is very little that cannot be done with consious administration and intelligent use of available features. it's a little like ACLs, it's definately a security feature but getting real value add from it is rare (particularly when you take into account the overhead of these features) and whether it increases or decreses overall security is a serious question too. in many instances (on various trusted operating systems and policy systems, not just selinux) i have seen the most appalling policies simply because administrators became significantly frustrated that they simply "opened" stuff until the application worked.
