Re: [RFC][PATCH 11/11] security: AppArmor - Export namespace semaphore

[Serge E. Hallyn]

Quoting Stephen Smalley (sds@xxxxxxxxxxxxx):
> On Thu, 2006-04-20 at 07:46 -0500, Serge E. Hallyn wrote:
> > Quoting Stephen Smalley (sds@xxxxxxxxxxxxx):
> > > On Wed, 2006-04-19 at 10:50 -0700, Tony Jones wrote:
> > > > This patch exports the namespace_sem semaphore.
> > > > 
> > > > The shared subtree patches which went into 2.6.15-rc1 replaced the old
> > > > namespace semaphore which used to be per namespace (and visible) with a
> > > > new single static semaphore.
> > > > 
> > > > The reason for this change is that currently visibility of vfsmount information
> > > > to the LSM hooks is fairly patchy.  Either there is no passed parameter or
> > > > it can be NULL.  For the case of the former,  several LSM hooks that we
> > > > require to mediate have no vfsmount/nameidata passed.  We previously (mis)used
> > > > the visibility of the old per namespace semaphore to walk the processes 
> > > > namespace looking for vfsmounts with a root dentry matching the dentry we were 
> > > > trying to mediate.  
> > > > 
> > > > Clearly this is not viable long term strategy and changes working towards 
> > > > passing a vfsmount to all relevant LSM hooks would seem necessary (and also 
> > > > useful for other users of LSM). Alternative suggestions and ideas are welcomed.
> > > 
> > > The alternative I would recommend is to not use LSM.  It isn't suitable
> > > for your path-based approach.  If your path-based approach is deemed
> > > legitimate, then introduce new hooks at the proper point in processing
> > > where the information you need is available.
> > 
> > Whoa, so now LSM is not for access control?
> 
> That isn't what I said, although I see that my phrasing wasn't clear.  I
> said it wasn't suitable for a path-based approach.  That is fairly clear
> from the hook placements and interfaces, and from the contortions that
> AppArmor has to go through in order to obtain the paths, and the number
> of times it ends up calling d_path on a single syscall.  Now "new hooks"

.

> _could_ be new LSM hooks, I suppose, but my point was that it is a
> mistake to try to use the existing LSM VFS hooks for this purpose - they
> are in the wrong place for it, and no amount of munging will fix that.
> Make sense?

Yup, that (.) seems a pursuasive hint.

Tony, do you have any performance measurements?  Both for unconfined and
confined apps?  Presumably unconfined processes should have 0 performance
hit, right?

-serge
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/