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

[Klaus Weidner]

On Thu, Oct 12, 2006 at 08:25:12PM +1000, Russell Coker wrote:
> On Thursday 12 October 2006 17:33, Klaus Weidner <klaus at atsec.com> wrote:
> > If you need local console (or serial) login at different MLS levels for
> > the same user, you can create multiple Linux users for each human user
> > that share the same uid and home directory, and use "semanage login" to
> > map them to appropriate levels. So you'd have smith_secret_cat1,
> > smith_unclassified and so on.
> 
> That doesn't work well with password expiry policies.  Having 
> smith_secret_cat1 password expire at different times to smith_unclassified 
> would be a pain for users and sys-admins.
> 
> Then if you want to use RSA SecurID or similar tokens you have an extra level 
> of pain in mapping them to the right Unix account names.
> 
> I think that the right solution is to re-enable the code for selecting the 
> role etc at login time and adding some code for selecting the level.  It 
> should not be difficult to do this if there are no plans to ever support it 
> for ssh or X logins.

Good point, and I agree that the right long-term solution would be to
do context selection (via a PAM module?) at login time. 

I don't think that it's a significant issue though for current LSPP
configurations - any people who plan to use this please speak up if you
disagree.  The current LSPP configurations are for server systems, and
require that local consoles (including serial consoles listed in
/etc/securetty) are physically restricted to be accessible by admins
only, and admins can still use newrole. This leaves only non-admin serial
terminals, and I don't think those are that common these days.

Of course, people deploying a system that's based on the LSPP
configuration can choose to deviate from the evaluated configuration
based on their own risk assessment. This could include restoring general
access to "newrole" if they don't consider the PTY exploit to be a
concern.

-Klaus