[redhat-lspp] Re: MLS enforcing PTYs, sshd, and newrole

[Stephen Smalley]

On Thu, 2006-10-19 at 10:06 -0400, Daniel J Walsh wrote:
> Stephen Smalley wrote:
> > pam_selinux used to have support to let the user pick from the list of
> > reachable contexts for the user.  So you could just restore that
> > support.
> >   
> I don't think so.  This allowed you to select your TE role, not your 
> Sensitivity.  The problem is selecting your sensivity.  Since there is 
> an large number of sensitivities a user can log in as he will need to 
> key it in.

Ah, I was thinking of the old MLS implementation, pre-TCS.  Fair point.

> > That doesn't address sshd though.  Or gdm.  sshd shouldn't be too
> > difficult.  There were some externally developed gdm patches for selinux
> > that enabled context selection long ago, but nothing recent
> > (pre-Fedora).
> >   
> I though the sshd would happen automatically when you login via a secure 
> channel.  IE If I connect at TopSecret, I get TopSecret.

Only if running it via the modified xinetd and only if using labeled
networking.  Otherwise, you still need a way for users to select a level
for their session.

> I think gdm will require other features such that I launch terminals at 
> different sensitivity levels???

Well, doing that right requires security enhanced X, a modified window
manager, and a trusted path, so that won't be happening today.

> I think we should separate the TE Context selection from the Sensitivity 
> Selection, in order to satisfy the MLS problems.

Ok.

> > You don't need to remove -l from newrole; you can just constrain its use
> > via DAC and via SELinux policy, as Klaus has previously suggested.
> >
> >   
> So it will not work on ptys?  Or are you thinking a boolean? I think it 
> will be strange for a user to have the app work differently depending on 
> how they logged in, but I guess this is another short coming of MLS.

It would be restricted via DAC mode and possibly a boolean in policy,
such that an admin could allow use of it if desired.  Only the LSPP
config would need to lock it down.

-- 
Stephen Smalley
National Security Agency