Messages in this thread | | | Date | Thu, 27 Apr 2006 15:38:24 -0700 | From | Chris Wright <> | Subject | Re: 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/
| |