Quoting Stephen Smalley ([email protected]):
> On Thu, 2006-04-20 at 07:46 -0500, Serge E. Hallyn wrote:
> > Quoting Stephen Smalley ([email protected]):
> > > 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
