lkml.org 
[lkml]   [2006]   [Apr]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [RFC][PATCH 11/11] security: AppArmor - Export namespace semaphore
From
Date
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?

--
Stephen Smalley
National Security Agency

-
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:03    [W:0.248 / U:2.220 seconds]
©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site