[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: How best (BUT WHY) get rid of SELinux?



Jonathan Underwood wrote:

On 25/09/2007, Les Mikesell <lesmikesell 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 gmail com


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]