How best (BUT WHY) get rid of SELinux?

[Les Mikesell]

Jonathan Underwood wrote:

>>> On 25/09/2007, Les Mikesell <lesmikesell at gmail.com> wrote:
>>>>   2) How many more years and millions will it take to adapt the
>>>> decades-worth of tradtional unix tools and applications that Linux users
>>>> take for granted to a wildly different security model?
>>>>
>>> This work has been done. What Unix tools are you using which aren't
>>> working with SElinux?
>> I have an assortment of suid perl scripts that run under apache's cgi
>> interface.  I didn't expect them to work.  Will they?
> 
> No disrespect, but your personal perl scripts don't really count as
> "traditional unix tools". Write a policy for them, and all will be
> fine.

Saying that everything done individually has to be re-done is a long way 
from your statement that the work was already done...

>> What about
>> MimeDefang, running as a sendmail milter and connecting via local
>> sockets to an assortment of mail scanning processes that may each be
>> running under their own uid.  I've seen issues posted about the sockets
>> amd SELinux.  Have they been solved?
>>
> 
> I believe so. Again tho, things will work with correctly written policy modules.
> Basically your complaint seems to be that you don't want to learn to
> use the tools to write the policy modules you need.

My complaint is that unix already had a security model, one whose 
simplicity was a great improvement over the prior much more complex 
systems such as multics and reversing that simplicity is heading the 
wrong direction.

> Everything has a
> cost, and a benefit... it's a personal decision as to which outweighs
> the other.

SELinux gives an extra layer of security, but only comes into play when 
you've already screwed up the simple system, admittedly made easier by 
languages that encourage buffer overflows, executable stacks, and 
predictable stack frames.  I'd just rather see the effort going toward 
fixing the simple problems instead of ignoring them and hoping, for no 
particular reason, to get the more complex scheme right.

-- 
    Les Mikesell
     lesmikesell at gmail.com