No more selinux-policy-*-sources

Stephen J. Smoogen smooge at gmail.com
Tue Mar 14 16:26:01 UTC 2006


On 3/14/06, Dennis Jacobfeuerborn <d.jacobfeuerborn at conversis.de> wrote:
> Alan Cox wrote:
> > On Tue, Mar 14, 2006 at 03:24:45PM +0100, Dennis Jacobfeuerborn wrote:
> >> complex solutions. AppArmor looks more attractive to me because while it
> >> may not be perfect at least it's usable and easily understandable compared
> >> to selinuxes black wizardry.
> >
> > Lots of things can look pretty but it doesn't mean they actually solve the
> > fundamental problems. SELinux uses more complex ideas like roles because in
> > the 1960s people working on this stuff realised the simple model actually
> > doesn't work.
>
>
> I understand that but if this system that "solves the fundamental problems"
> is so complex that most people just turn it off then the gain in security
> you get is pretty much theoretical. Security isn't an all-or-nothing thing
> and right now there seems to be chasm between the very basic traditional
> Unix model and the very secure but extremely complex SELinux. It looks like
> AppArmor fits in quite well between these two extremes.
>

To be honest, we have found that the following people turn off SeLinux
for the following reasons:

1) They were told that xyz would be fixed by turning off SeLinux. In
most cases, they the problem with xyz was really a config issue that
they then fix by hand, but will swear that turning off selinux somehow
fixed things. It is similar to problems back in the Red Hat Linux 5.0
days where any problem with the system was fixed with a static
compiled kernel or application.

2) They have installed some super nifty kernel module (panassas) or
application that selinux (and 90% of the rest of the kernel) does not
agree with.

3) They found a legitimate problem with selinux but did not have the
tools to debug it or had the training needed to fix it.

4) They turn it off because it is outside their experience or religous
(Unix) convictions.

I think that the issue is mainly tools and time to get people up to
speed on it. The Selinux module looks to me like a Policy Virtual
Machine, and most of the policy data is assembly code. Now thats all
fun for some people, but most system administrators these days don't
do assembly code work anymore. They need levels of abstraction to help
make it something they can understand since they have not one system
to look after but 300 or more. They need a "python/perl/ruby" level
tool that does all the assembly code deep down but just has commands
like "import confidential_policy; print system_users; for $user in
peter, john, robert, thomas, paul, lindy do add_user system_users,
$user; done"


--
Stephen J Smoogen.
CSIRT/Linux System Administrator




More information about the fedora-devel-list mailing list