Re: Fwd: [Linux Security Module Interface]

From: Sebastian Andersson <bofh@diegeekdie.com>
Subject: Re: Fwd: [Linux Security Module Interface]
Date: Wed, 11 Apr 2001 09:04:42 +0200

Next Article (by Subject): Re: Fwd: [Linux Security Module Interface] Amon Ott
Previous Article (by Subject): Fwd: [Linux Security Module Interface] Fabrice MARIE
Top of Thread: Fwd: [Linux Security Module Interface] Fabrice MARIE
Next in Thread: Re: Fwd: [Linux Security Module Interface] Amon Ott
Articles sorted by: [Date] [Author] [Subject]

On Wed, Apr 11, 2001 at 11:51:45AM +0800, Fabrice MARIE wrote:
> 
> What do you think about that ?

I don't think this is such a good idea.

I think this looks like ImmuniX can't earn money without having
to resort to proprietary software development and that is sad.
Maybe they should try to sell competence instead of units? Sell
development work to OEMs, ask companies to fund the development, etc.

I think it will be hard to provide a good API for this that both allows
most kinds of security policies (and if it doesn't, why have a common
API for it?) and at the same time provide good performance and most
importantly, not limit the performance of the common case, with the
default, POSIX security model.

The more hooks there are in the kernel for loaded modules, the more
non-free/non-open-source modules there will be. There will be even more
"linux distributions" that one can't install on more than one computer
and all the hassle of buying licenses, spending days interpretating if
one can legaly install a cold-spare machine without buying extra
licenses etc. And then we are back at "Sun UNIX", "HP UNIX",
"IBM UNIX", "SGI UNIX" or even worse.

I also don't want a lkm interface on a secure machine.

> Would it make RSBAC more widely used ?

No. What would make RSBAC more widely used is a good book about it and
a distribution with RSBAC preinstalled that is as easy to install as
Debian GNU/Linux with some already configured security policies
suiteable for different kinds of machines and organisations.
Installing RSBAC is in my opinion the easy part of using RSBAC.
Neither of those two areas are small projects though.
And of course some slashdot postings about it too... :-)

> Is it a security threat to enable this kind
> of security feature at the module level ?

No, in the sense that if someone can install any module, they are
already having full control of the machine, they can call any internal
function in the kernel today. They can even do that with just
/dev/kmem access and quite safely. Look in Phrack for a description.

Yes, in the sense that there will be non-free software without source
that provides some security feature and it will, as usual, contain
security holes, but few will audit it outside of the company and the
black hat community. A security company with a security hole looks bad
so they keep their mouth shut and releases fixes with the next version,
which people will not install because they don't have any problem with
the current version. Even if the company policy is to inform its
customer about known problems, quite a few developers will silently
fix problems they find instead of spending a lot of time filing reports
about it (if it is their own coding that was at fault). It's the human
nature; blame others, keep a low profile about your own faults...
(Me cynical?).

> What about a box without RSBAC/SElinux/StJude
> that would be rooted ... an attacker would have
> even more evil power with your kernel ?

No. If you let them load a module, they already own your machine well
enough. Check out the modern root kits, they contain modules today.
If you can't find any, take a look at LIDS (http://www.lids.org/) and
its usefulness to someone nasty.

Regards,
/Sebastian
-
To unsubscribe from the rsbac list, send a mail to
majordomo@rsbac.org with
unsubscribe rsbac
as single line in the body.

Go to Compuniverse LWGate Home Page.