|
Message-ID: <20110724183841.GD6429@albatros> 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.