Re: Hook function suggestion

aoat_private

On Don, 19 Apr 2001 buddy wrote:
> Now, the only thing I'm trying to say here, is that nobody seems to care about the
> reason *why* you would want to hook into, say, sys_fork(). There has been no
> discussion about the actual threats and insecurities that we want to cover.

On GACI list, I already posted the a list of RSBAC hooks with some reasons and
call chains. I attached a slightly reworked version.

After your rant about people just telling what they did: We all made our own
reflections about security impacts of certain functions. This is why the hooks
are there. So what is needed is:
- justification
- discussion
- importance rating, e.g. with levels
- compilation of useful hooks
- decision which ones to take for the final solution
- decision about config switches to select subsets

> As an example, needing root privileges in order to (un)load modules doesn't make
> me feel any safer, but apparently I'm more paranoid than you are. ;-) I'm worried
> about all those people relying on their LKM notifying them of a root compromise,
> and being owned all the same.

One of my main reasons for saying 'Modules are not secure enough'. However, if
all we have (or can get) is a modules interface, let's make the best out of it.

> I'm not saying that LSM will add insecurity to the kernel. What I'm addressing is
> the problem that the police face: if you want to carry a gun to protect people,
> you'd better protect the gun too. Besides, the police's primary task is not to
> carry
> a gun, but to protect people.

Fully agreed.

> > P.S.  My thanks to Huagang for actually providing the spec of desired
hooks for > > LIDS.  That's what we really need to be discussing here.
> 
> I'm certainly not trying to start a broad, general discussion about computer
> security.
> I can't wait either to get something done. But not just anything.
> So, while I appreciate Huagang's effort and input, I thought I'd take the
> opportunity to discuss the *really* difficult stuff related to security, and how
> that is connected to LSM.

Just added my own list, as it is certainly the most important one... ;)

Amon.