lkml.org 
[lkml]   [2006]   [Apr]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC][PATCH 11/11] security: AppArmor - Export namespace semaphore
Quoting Stephen Smalley (sds@tycho.nsa.gov):
> On Thu, 2006-04-20 at 07:46 -0500, Serge E. Hallyn wrote:
> > Quoting Stephen Smalley (sds@tycho.nsa.gov):
> > > 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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-04-20 15:23    [W:0.230 / U:0.280 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site