Subject: Re: Volunteers to test some kernel code...
To: Brett Lymn <blymn@baea.com.au>
From: Perry E. Metzger <perry@piermont.com>
List: tech-kern
Date: 06/22/1999 10:05:03
blymn@baea.com.au (Brett Lymn) writes:
> According to Perry E. Metzger:
> >
> >I've been thinking about this, and I'm far from sure this whole scheme 
> >is going to provide any real security. It may add a lot of complexity, 
> >but in the end, I'm far from sure its a win.
> 
> I have been thinking about it too in the light of the comments I have
> received.  I am not totally convinced the idea is a turkey yet but
> there are some issues which I think do have a bearing:

I'm far from convinced.

The problem of securing a machine is not generally one that can be
solved in this way. All this does is end up increasing the perception
that security is a pain in the ass and encourage administrators to run 
insecurely.

Tripwire is already more than adequate for this purpose. All you end
up doing by moving this directly into the kernel is force the attacker 
to try to attack the signature database in another manner -- it still
has to be in storage.

My main concern is the same as my concern with mechanisms like
securelevel -- they do not address the problem of privilege and
privilege abuse directly, they merely attempt to put a band-aid on the 
situation.

To truly fix the problem, we need to eliminate as much privilege from
the system, and as many opportunities for privilege violation, as
possible. I'm sort of miffed that this is being discussed on tech-kern 
rather than tech-security, because in the end, this is a security
architecture issue, and the security architecture problem is a lot
deeper than just preventing people from touching files.

BTW, running immutable is perfectly feasible -- Thor and others have
run systems at high secure level with most files immutable. I contend
that it is only a bandaid, but it is certainly doable with current
mechanisms.

What I want to see in the future is a security architecture in which
we can systematically reduce the privilege of processes, and in which
we can eliminate privilege crossings like suid entirely or at least
mostly. This will start to address the real problem.

Perry