lkml.org 
[lkml]   [2006]   [Apr]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Some Concrete AppArmor Questions - was Re: [RFC][PATCH 0/11] security: AppArmor - Overview
* Stephen Smalley (sds@tycho.nsa.gov) wrote:
> Even in the absence of any "unconfined" processes, the potential for
> collusion among multiple "confined" processes (via coordinated attack)
> shouldn't be overlooked. Thus, the base mechanism needs to be resilient
> in the face of such collusion.

Yes, good point.

> > I guess it's worth noting the AA atack is stopped by SELinux, while the
> > opposite is also true. A 'cp /etc/shadow /tmp; mv /tmp/shadow /etc' done
> > by an unconfined process doesn't effect AA, while it kills the type
> > label on /etc/shadow and could be an effective policy breach. In each
> > case somewhat subtle (i.e. not explicit relabel or policy change) can
> > have holes.
>
> 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.

> If you had used appropriate
> options to cp to preserve the attribute, then it would have preserved
> the type throughout the transaction.

Hehe, why would I do that if I'm trying to get unconfined process to
break the label? ;-)

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

\
 
 \ /
  Last update: 2006-04-28 00:41    [W:0.120 / U:0.020 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site