Re: Fwd: [Linux Security Module Interface]

From: Fabrice MARIE <fabrice@celestix.com>
Subject: Re: Fwd: [Linux Security Module Interface]
Date: Wed, 11 Apr 2001 16:16:52 +0800
Next Article (by Subject): Gaah. forgot a question. Jörgen Sigvardsson
Previous Article (by Subject): Re: Fwd: [Linux Security Module Interface] Amon Ott
Top of Thread: Fwd: [Linux Security Module Interface] Fabrice MARIE
Articles sorted by: [Date] [Author] [Subject]
Hello Sebastian & Amon, (& the rest :)

My questions were generally targeted to raise a
discussion about that API...

On Wednesday 11 April 2001 15:04, you wrote:
> 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 definitely agree with you. I hate the idea of proprietary modules
to the kernels. Especially when the module you use need to be recompiled
for the new kernel ... argg.

> 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... :-)

Installing is definitely piece of cake, and could (should!) be already
inside a normal distro. If they are scared by its power, they could
make a 3 differents kernels : 1 rsbac enabled, 1 rsbac maintenance
and one withtout rsbac as a default. Then the user can choose !

> > 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.

I've read the article already that explained how to load
modules in a kernel that doesn't contain module loading,
using /dev/kmem ! :) One has to agree that it's not a piece
of cake !! But anyway, I agree with you.

> 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.

Anyway additional policies can be added using REG, so I see no
point to add any other API. What do you think ?

As I said, the target of my questions was to raise different
points of view. I think like you Sebastien & Amon, but I'm still
very interested in a good defense from the other side, if any.
If any of you don't agree, please speak up.

Thanks,
Fabrice.
-- 
Fabrice MARIE
R&D Engineer
Celestix Networks
http://www.celestix.com/

"Silly hacker, root is for administrators" 
       -Unknown
-
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.