On Sat, Sep 22, 2007 at 07:45:57PM +0300, Ihar Hrachyshka wrote:
> 2007/9/22, Joachim Schipper <[EMAIL PROTECTED]>:
> > The OpenBSD developers are trying to make the most secure UNIX system
> > they can; SELinux might or might not be secure, but it's not UNIX.
> What part of SELinux is NOT Unix? Remember that all traditional Unix
> rwx permissions are still there.
Insofar as that ls -la shows them, yes. In the sense that files actually
work that way, `usually'.
> > Additionally, it's not entirely clear whether it actually helps;
>
> For example for blocking some critical operations for ALL users, even
> root. Of course, that's the case when strict traditional
> Unix-awareness is not so critical as the security of the system by
> itself.
Root almost always can gain complete control over the system anyway, so
that's not a big issue.
Also see my comments below.
Still, yes, SELinux can be - rarely - used to solve problems for which
no clean UNIX-ish solution exists. Far too often, though, it's thought
of a as a magic bullet, which it certainly is not.
> > SELinux configuration is, even at its best, a lot more complex than the
> > equivalent UNIX-ish configuration. Thus, it becomes more likely that
> > there will be either configuration or coding errors.
>
> Every security feature, every OS improvement IS an additional code.
> That's the problem of proper kernel and security policies audit, not
> SELinux as an idea.
Yes, but not all code is created equal. Layering a second permission
layer into the system integrates closely with all other security
mechanisms, which is more dangerous than yet another driver.
Additionally, it's completely the wrong way to go about securing a
system. The best way not to have any vulnerabilities is not to have any
vulnerabilities; stuff like SELinux, Pax, or W^X is cool, but not a
substitute for good programming. An OpenBSD system running properly
chosen and secured programs without W^X is almost as secure as one with
it. I'd argue the same goes a Linux system running a haphazard
collection of badly-out-of-date, unpatched monstrosities with or without
SELinux.
Finally, SELinux is almost never necessary. (But it *is* - rarely -
useful.) And takes a lot of time, which is usually better spent doing
something actually useful - like log monitoring.
Joachim
--
TFMotD: packages-specs (7) - binary package names specifications
