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

[Stephen Smalley]

On Thu, 2007-01-04 at 22:01 -0600, Klaus Weidner wrote:
> 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.

Not so much resistance as uncertainty as to what form such a check would
take and how effective it would be.

> 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
-- 
Stephen Smalley
National Security Agency