* Stephen Smalley ([email protected]) 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
