Re: [RFC][PATCH 11/11] security: AppArmor - Export namespace semaphore

[Linda Walsh <lkml@tlinx.org>]

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