On Wed, 2005-02-02 at 08:37 -0500, Stephen Smalley wrote:
> On Tue, 2005-02-01 at 09:33, Stephen Smalley wrote:
> > The structure allocated upon the alloc_security could be just a trivial
> > container structure with a pointer to the real structure to be filled in
> > later upon the exec, so that you don't have to manipulate the chain of
> > security objects at that time. Module removal has plenty of other
> > safety issues already, doesn't it?
>
> Of course, the container structure would also need to have some kind of
> synchronization primitive, e.g. a semaphore, that can be initialized
> upon alloc_security and used by later hooks, so that you can then
> synchronize attempts to allocate the real structure and set the pointer
> to it upon other hooks like inode_permission. Somewhat similar to what
> SELinux already does when setting up the content of the already
> allocated inode security structure from d_instantiate.
But just to be clear, you're talking about something a module like
bsdjail and seclvl would need to do, right? This doesn't go into the
stacking infrastructure?
In the case of seclvl, digsig, and bsdjail, I wonder whether having to
do these blanket allocations will cause a greater performance impact
than the rwlock in security_{set,get,del}_value. Maybe a performance
comparison of just selinux+capabilities with and without the rwlock will
be a good data point here.
-serge
--
Serge Hallyn <serue@private>
This archive was generated by hypermail 2.1.3 : Wed Feb 02 2005 - 08:00:28 PST