On Sat, Sep 22, 2007 at 08:38:17PM +0300, Ihar Hrachyshka wrote:
quoted text
> The problem of Linux as a whole is that it tries to resolve security
> problems not by auditing code but by implementing SELinux. But what
> the problem would be if OpenBSD has "SeBSD" extension?

I think the nearest equivalent is "TrustedBSD".

The main trouble with SELinux is that it's so horrendously complex [1] and
fraught with traps for the unwary [2]. The chance that the policy you've
written is correct (i.e. without unwanted holes), unless you happen to have
a PhD in SELinux, is pretty much zero. On the other hand, the basic Unix
permissions model is so simple it's easy to audit.

The other problem with SELinux is that there seems to be some smoke and
mirrors going on.

SELinux: "We don't have a superuser account!"

Me: "So how do you configure SELinux policies?"

SELinux: "You need to have a special role, sysadm_r" [3]

Me: "So someone logged with sysadm_r can change any SELinux policy they
like? Or even disable SELinux entirely?"

SELinux: "Yes"

Me: "So how is that different from having a root account?"

SELinux: "Well, only the trusted administrator needs to have this privilege.
You don't give it to any of your service daemons, for example, and they
can't recover it"

Me: "But I don't run any of my daemons as root anyway; they all run as their
own separate unprivileged uids."

SELinux: "Hmm. Good point. But on a non-SELinux system, you could attempt to
break a setuid-root binary to get root again."

Me: "But with SELinux, don't you have rules so that privileged applications
transition the domain? So for example, when you run tcpdump, it transitions
into another domain which has privileges to capture network packets?"

SELinux: "Yes. But it's much more granular and configurable than setuid."

Me: "I think I've heard enough. Just let me audit my few setuid programs
properly, and then I won't need to learn SELinux at all, thank you."

[1] http://www.lurking-grue.org/writingselinuxpolicyHOWTO.html
[2] http://fedoraproject.org/wiki/SELinux/EnforcePolicy

[3] http://docs.fedoraproject.org/selinux-faq-fc3/index.html#id2826056
"How do I temporarily turn off enforcing mode without having to reboot?
...
You must issue the setenforce command with the sysadm_r role; to do so, use
the newrole command. Alternately, if you switch to root using su -, you gain
the sysadm_r role automatically."

[4] http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/selg-section...
"Should an attacker gain root control, they could rebuild the policy to
weaken or neutralize SELinux"