[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 24 Jul 2011 22:38:41 +0400
From: Vasiliy Kulikov <segoon@...nwall.com>
To: musl@...ts.openwall.com
Subject: Re: some fixes to musl
Rich,
On Sun, Jul 24, 2011 at 08:56 -0400, Rich Felker wrote:
> On Sun, Jul 24, 2011 at 01:39:11PM +0400, Vasiliy Kulikov wrote:
> > > It should be obvious that a bogus LSM will create gaping security
> > > holes if it's allowed such power.
> >
> > I don't say such handling is perfect, just want to show it can be
> > somehow justified:
> >
> > Most of LSM hooks maintain some security context associated with
> > file/task/socket/etc. Some actions may require (re)allocation of this
> > context. If the allocation fails (e.g. OOM), it's wrong to allow the
> > task to continue the work with the object, which has an outdated context
> > (not updated against some recent activity). So, unexpected ENOMEM is
> > returned.
>
> Are you saying that all operations on the associated object
> (file/task/socket/etc.) are automatically first subjected to an LSM
> hook? Or just that the LSM module author might set up a hook?
The LSM may set up a hook. The hook may deny any access to an object.
But not all hooks are registered by all LSM implementations. Some hook
implementations are simply log the event and return success
unconditionally. IIRC, only SELinux implements all hooks (among all
in-tree LSM implementations). If a hook is not registered, it is a
noop.
> In the latter case, I would say it's a bug and potential gaping
> vulnerability for a module to install a hook on any
> resource-deallocation function.
It should probably needs better review, but at first sight only
shutdown() among all deallocations may fail because of LSM. And only
SELinux implements it. I suppose hooking shutdown() makes sense as a
task may get an fd e.g. for read only access, and shutdown would break
RO restriction.
close(2) is not hooked.
> In short, I think you've raised really good points, and LSM probably
> needs an audit...
Yes, and possible breakage of implicit expectations is not the only
reason for the review :-)
Thanks,
--
Vasiliy
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
