[redhat-lspp] Re: [PATCH 2/3] Re: MLS enforcing PTYs, sshd, and newrole

[Klaus Weidner]

On Thu, Jan 04, 2007 at 10:35:45PM -0500, Joshua Brindle wrote:
> > From: Klaus Weidner [mailto:klaus at atsec.com] 
> > 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