--- Klaus Weidner <[EMAIL PROTECTED]> wrote:
> > The problem here is not with the pty, rather with > newrole, which > > oughtn't keep descriptors open if it is changing > MLS label. > > In this case, the descriptor is the standard input > and output stream that > newrole uses for interaction, including reading its > password, and closing > that will make it stop working That is correct. In the context of MLS the newrole command is flawwed in that it provides a mechanism that allows the downward flow of information. > since the system > doesn't have a trusted > input/output path (which is a separate problem). > newrole can't tell the > difference between a legitimate pty use from ssh or > in an xterm versus > the unauthorized use, and it would be a very > significant restriction to > permit only console access for newrole use. You're right. The MLS requirements make this hard. You cannot change the MLS label of a user session while leaving any of the old accesses available. In the Unix world this was addressed in a number of ways: - MLS X11 servers - Commands (e.g. newlabel or "su -M") that run a requested command at a higher MLS label but that close all open descriptors and reopen them on /dev/null. - Required logout/login to change MLS label. > Would it work to have newrole relabel the pty (maybe > in a PAM session > module?), so that the controlling low process won't > be able to read from it? Hee Hee. This only works if you do the MLS check on every fd operation. UNICOS/MLS did this. You can do it in the pty driver, too, if you only care about ptys. You could do it in the driver for /dev/tty if you're ambitious. Of course, that puts you into a situation that's indistinguishable from having closed the descriptors. Casey Schaufler [EMAIL PROTECTED] -- redhat-lspp mailing list [email protected] https://www.redhat.com/mailman/listinfo/redhat-lspp
