Messages in this thread | | | Date | Thu, 20 Apr 2006 08:21:28 -0500 | From | "Serge E. Hallyn" <> | Subject | Re: [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/
| |