On Thu, Jan 04, 2007 at 10:35:45PM -0500, Joshua Brindle wrote: > > From: Klaus Weidner [mailto:[EMAIL PROTECTED] > > Instead of hardcoded types, how about a configurable type or > > a /etc/securettytypes file that contains the types instead of > > tty names? > > Sure, the securettycontexts might be the way to go. I'm dubious about > just making this happen for level changes though, you shouldn't be able > to bypass any part of the security policy using newrole.
The problem isn't actually in newrole, so this is a workaround to close an information leak in MLS environments without causing problems for everyone else who wouldn't care about this leak. Newrole has special privileges (specifically the "mlsprocsetsl" attribute) which make it a trusted program, and I think it's reasonable to have a trusted program enforce part of the security policy. >From what I recall from the previous discussions, there is a lot of resistance to implementing SELinux hooks in the PTY layer which would be needed to enforce the restriction at the kernel level. A permission check at the PTY level would most likely require a fair amount of policy to avoid TE denials, and even getting just the MLS constraints to work would be tricky. For example, which of the processes involved at the ends of the PTY should gain MLS override privileges due to its type attributes if any? -Klaus -- redhat-lspp mailing list [email protected] https://www.redhat.com/mailman/listinfo/redhat-lspp
