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

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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages