On Wed, 02 Nov 2005 15:14:15 EST, Steve Grubb said:
On Wednesday 02 November 2005 14:42, Valdis.Kletnieks(a)vt.edu wrote:
> Presumably, that should be failed by SELinux or something as a violation
> of the appropriate MLS constraint - a process running at some level allowed
> to run 'cat secret' shouldn't be allowed to write to an unlabeled
device.
I think you're missing a subtle point. Assume that the user has the
permissions to read secret and write to an unlabeled media. Assume they have
properly allocated the device and are ready to do something.
Given that, what is the correct action? LSPP says that its an auditable event
- it doesn't say it must be prevented. Should each program that does this be
patched or does a central mechanism in the kernel need to handle this?
The point is that we *already* have both audit and MAC (SELinux, etc) capabilities
that are in place to deal with the case where a process is *directly* trying to
export data - audit can see that, and the MAC can prohibit it if it wants to.
The additional CUPS support is because CUPS is acting as a proxy - by the time
we hit the event that LSPP requires support for, the original process may be
long gone (for instance, I may have issued the 'print' command the night before).