Re: Some Concrete AppArmor Questions - was Re: [RFC][PATCH 0/11] security: AppArmor - Overview

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

On Thu, 2006-04-27 at 15:38 -0700, Chris Wright wrote:
> * Stephen Smalley (sds@tycho.nsa.gov) wrote:
> > Not sure about the example here, as the type in that case would actually
> > be lost upon the cp by the unconfined process to the /tmp location, in
> > which case you have an issue for both AA and SELinux - the data has
> > become accessible under a different name and label which may now be
> > accessible beyond the original intent.
> 
> Point is, names matter as much as inodes do.  And it's possible to
> get improperly labelled data in canonical location for object (i.e.
> /etc/shadow).  Certainly requires unconfined help, but real people do
> things like that w/out fully understanding the impact.  You can fix the
> normal tools, but not all one-off admin tools.

The names don't matter as much as the real security properties of the
data, but I do agree that mislabeling of data is an issue, particularly
for a gradual rollout of MAC where we have to deal with the fact that
not everything will be confined and not all of userspace will be
properly instrumented.  However, I'd argue that this can be addressed,
in the short term through userspace tools like restorecond that leverage
inotify and in the long term through ever expanding application of MAC
to the system (as that becomes more feasible via the introduction of
appropriate tools and infrastructure to make management feasible, which
is already in progress).  Addressing it by introducing a flawed
mechanism into the kernel seems like a bad idea to me.

> > Of course, the real problem here
> > is that you have an unconfined process copying the data at all, at which
> > point you have no real guarantees about it, and the loss in label is the
> > least of your worries.
> 
> That's my point.  You can't meaningfully reason about the security of
> the system with unconfined processes.

Precisely.  And this is something that we recognize and are working
toward eliminating - the targeted policy is just a way of transitioning
MAC into Linux gradually until we have the necessary infrastructure and
tools to make it truly manageable.  Whereas other approaches seem to
presume that unconfined processes will always be present, and in fact,
will be the majority of the system.

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