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

[Stephen Smalley]

On Thu, 2007-01-04 at 22:35 -0500, Joshua Brindle wrote:
> > From: Klaus Weidner [mailto:klaus at atsec.com] 
> > 
> > On Thu, Jan 04, 2007 at 10:05:57PM -0500, Joshua Brindle wrote:
> > > Hardcoding types into code makes it inflexible to policy 
> > changes, this 
> > > is a bad idea IMO, the tty whitelist, however, is probably 
> > the way to 
> > > go. I don't know if we should use the existing 
> > /etc/securetty or  add 
> > > our own file though.
> > 
> > I'm not sure if the existing /etc/securetty is the right one, 
> > since people may make serial terminals available to users but 
> > would not want direct root login on those. Well, maybe not 
> > terribly likely these days.
> > 
> > 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.

We don't want to break newrole -r on a pty.  

(issue is that there are two ends for a pty, master and slave, and only
the slave end is relabeled by newrole.  master end is always /dev/ptmx
wrt the inode, only the open file is per instance IIUC).

-- 
Stephen Smalley
National Security Agency