On 24.09-10:25, Jason Dixon wrote:

[ ... ]

quoted text
> > 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.