--- LC Bruzenak <[EMAIL PROTECTED]> wrote:
> Add it in post-evaluation and the accreditors balk. As, of course, they ought. > > I claim that you can't do it and maintain > > the integrity of your MLS. > > Casey, can you elaborate a bit on this assertion? > I agree it is not without risk but feel it may be > acceptable given that > the trusted program should be well-behaved. Or does > it open an exploit > potential? Let's follow the flow of events. Barney logs onto the system over a labeled network connection. Some mechanism is used to determine what MLS label the session should have: CIPSO, IPSEC, Barney's clearance, and the address of remote host are all mechanisms that can work. Barney's shell will get the label chosen and all resources dedicated to the session, such as a pty, will get that label. Barney, being an unprivileged, untrusted, "normal" user then performs some arbitrary actions that may include accessing and/or opening objects at his label. Further, the system will communicate with the remote host, providing information that the other end of the connection is know allowed to see because of the integrity of the aforementioned label establishment mechanism. Let us assume that a mechanism exists for Barney to change the MLS label of his session, and for convinience let's call it newrole. Barney uses newrole to change his MLS label to one that is dominated by, but not equal to, the label with which he logged into the system. Policy has been violated, since he could now create a file and fill it with higher labeled information gathered prior to the newrole invocation. Next, Barney uses newrole to change his MLS label to one that dominates, but is not equal to, the label with which he logged into the system. For grins, let's say that his shell has reopened stderr to a file for logging purposes. The newrole utility passes open file descriptors along, so now Barney can read higher labeled objects and pass the information downward by writing it to stderr. The labeled network mechanism won't allow the relabeled process to communicate over the labeled socket in any case because doing so would violate the MLS enforcement on the socket. Even if newrole does provide either of these strictly illegal facilities you still have the problem of communicating with the remote host. An implementation must not allow a process to inaccurately associate the MLS label of the data transmitted over a socket. The newrole program can behave safely, or it can provide convinience, but it can not do both. Changing a session MLS label in an environment that preserves existing state is not going to work because of the existing state. A newrole program that destroys the old session and creates a new, clean session with the new MLS label is a better choice, although you still have the problems associated with communicating with the remote host. Casey Schaufler [EMAIL PROTECTED] -- redhat-lspp mailing list [email protected] https://www.redhat.com/mailman/listinfo/redhat-lspp
