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

[Stephen Smalley <sds@tycho.nsa.gov>]

On Thu, 2006-04-20 at 14:50 -0700, Linda Walsh wrote:
> 
> 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?

The first question is whether a path-based mechanism is suitable for the
kernel at all.  Not my call to make, but seems to run counter to the
Unix and more so the Linux model, and to past discussions on
linux-fsdevel and linux-kernel.

If a path-based mechanism is suitable, then the next question is whether
LSM is suitable as a means of implementing such a mechanism.  At
present, I would argue that it is not - the hook placement and
interfaces are not well suited to it (despite being originally proposed
by the WireX folks who worked on SubDomain/AppArmor), and the current
AppArmor implementation requires significant contortions to work around
the interface mismatch.  Which would suggest that they need to propose
changes to LSM (e.g. new hooks at more suitable locations) first.

>   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 don't recall that one; submitting new hook proposals is ok as long as
there is a user that will also be submitted.  SELinux itself has needed
to extend the LSM interface over time.

>   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. 

SELinux was and remains the primary user, so that obviously has
influence, but as I've noted before, the original VFS hooks were first
proposed by the WireX folks, and they were active participants during
LSM development.

>  If it was, then why not remove all non-SELinux
> hooks?

That is actually a good idea.  They can always be added back if a
genuine user comes along.  SELinux also has some stubs that should be
dropped at the same time.

>   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.

I think you haven't looked at the native Linux 2.6 audit implementation
very closely.  LSM wasn't suitable for audit.  The namei code and other
parts of the kernel have been hooked to call into the audit system to
collect information as needed.

>     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.

Do you know how they implement it?  The question is not whether
path-based configuration in userspace is ok; it is whether the kernel
mechanism should be relying on pathnames.  There are also much saner
implementation approaches for name-based schemes than calling d_path to
generate the full path and checking that against a profile on each open;
DTE was one example.

>     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.

SELinux can express such restrictions via its TE configuration already.
Or you can implement this kind of mechanism in other ways, but it
doesn't require the kernel to be generating and checking pathnames.

>     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.

Which is fine for userspace tools, but doesn't justify it as the kernel
mechanism.

-- 
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/