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

[Stephen Smalley]

On Wed, 2006-10-25 at 09:50 -0400, James Antill wrote:
> On Wed, 2006-10-25 at 08:22 -0400, Stephen Smalley wrote:
> 
> > To elaborate, as I understood it, seusers (managed via semanage login)
> > was to provide per-Linux-user authorizations for MLS/MCS ranges, while
> > multiple such Linux users might be mapped to a single SELinux user that
> > was authorized for the full system range.  The login-style programs
> > would then ensure that the range in the initial security context for the
> > Linux user's session was limited by the value defined in seusers, and
> > SELinux policy would subsequently ensure that processes in that session
> > can not escalate outside of that range via newrole -l (or other
> > mechanism).
> 
>  My understanding is that while security_check_context() allows it, the
> setexeccon() will fail. Which seemed to be good enough.

No, it won't.  Suppose that I have two Linux users A and B, with A
authorized for category c0 and B authorized for category c2 in seusers,
but both A and B are mapped to SELinux user U who is authorized for all
categories in the kernel policy.  The login-style programs are naturally
going to be authorized to transition to any of those contexts since they
have to deal with user logins at any level, so the setexeccon() will
succeed.  The SELinux security context will have U as the user identity,
so it will always be valid.  You need an explicit check.

> 
> > It isn't sufficient to check the validity of the context with the
> > user-supplied level, because from the kernel's POV, any level might be
> > authorized for the underlying SELinux user identity, whereas seusers
> > might have defined a more restricted range for the Linux user identity.
> > You need a check between the user-supplied level and the seusers-defined
> > value (more generally, this could be an avc_has_perm or
> > security_compute_av check between contexts containing those levels, and
> > the underlying policy could define a mlsconstrain on the corresponding
> > permission). 
> 
-- 
Stephen Smalley
National Security Agency