Messages in this thread | | | Date | Thu, 20 Apr 2006 14:50:32 -0700 | From | Linda Walsh <> | Subject | Re: [RFC][PATCH 11/11] security: AppArmor - Export namespace semaphore |
| |
Stephen Smalley wrote: > 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. > --- I thought LSM was supposed to provide the hooks to allow virtually any access control scheme to be implemented? I've seen complaints before on either here or the LSM list that one of the hurdles for "legitimacy" was whether or not it fit on top of the current set of LSM hooks. I also saw it asked whether or not LSM had been designed around, primarily, the needs of SELinux and if it was going to remain so. If it was, then why not remove all non-SELinux hooks? If LSM is to support alternate security methods, it is logical to believe that LSM was not implemented with calls to support every desired security model people might want. There are known, insecure, race conditions in linux auditing, for example, due to lack of LSM hooks. This was a conscious design decision made by the LSM majority over objections of people who wanted greater flexibility to support security mechanisms not supportable with the current set of hooks.
In regards to "legitimacy", while I share the reservations of many people in using a path based approach to security, I might point out that this model is a basic one integrated into Windows NT (XP & later, 2k?). That doesn't mean it is "good", but it certainly should add some weight to the claim of "legitimacy". I.e. - it provides a "comfortable", known security mechanism for people switching to Linux servers from from "Windows Server 2003".
In the Windows approach, you can specify allowed and disallowed paths by unique name and using wildcards. This allowed/disallowed hash is checked before every program execution.
If you start with a large, multi-user system, and allow no user-level mounts (they just sign in and can pick from a limited menu of choices, the pathname approach can have some merit. For example, one might have a security policy only allowing execution of binaries in "/usr/bin". The employer puts all of his "reservation-system" or "database-access" routines in "/usr/bin" (or adds the app path(s) to the allowed hash). The end users run the allowed binaries and that's it.
I'm not saying it's an approach I would find useful to control security on my systems, but I can see a potential usefulness for it, in that it is relatively easy for people to understand, setup and use.
Linda W
- 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/
| |