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

On Wed, 2006-10-25 at 15:15 -0400, James Antill wrote:
> On Wed, 2006-10-25 at 09:59 -0400, Stephen Smalley wrote:
> > On Wed, 2006-10-25 at 09:50 -0400, James Antill wrote:
> > > 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.
>
> Ok, I had assumed that "U" would always be different in this case. I
> think this update to the patch solves the problem ... it gets the list
> of valid roles/levels from get_ordered_context_list() (which I think is
> complete, but I'm not 100%) and compares what is entered against that.
> I'm not 100% sure this is right (it means there would be huge lists
> returned for MCS, no?), but I don't see what else I can call that would
> validate the role/level-range for a specific login.

Sorry, no (at least based on that description - didn't receive the patch itself). get_ordered_context_list() et al are still interfaces based on SELinux user identity. What you need to do is to validate the user-supplied level against the range returned by getseuserbyname(), and the particular check needs to see whether the level is within the user's authorized range. Which gets into policy specifics, which is why I suggested using a permission check via avc_has_perm or security_compute_av, and letting policy define a mlsconstrain on it.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.