On Thu, Oct 12, 2006 at 08:25:12PM +1000, Russell Coker wrote: > On Thursday 12 October 2006 17:33, Klaus Weidner <[EMAIL PROTECTED]> 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 -- redhat-lspp mailing list [email protected] https://www.redhat.com/mailman/listinfo/redhat-lspp
