[redhat-lspp] Re: [PATCH 2/3] Re: MLS enforcing PTYs, sshd, and newrole
Stephen Smalley
sds at tycho.nsa.gov
Tue Oct 31 16:21:15 UTC 2006
On Tue, 2006-10-31 at 11:04 -0500, James Antill wrote:
> On Tue, 2006-10-31 at 10:11 -0500, Stephen Smalley wrote:
>
> > As I understood it (and the code in pam seems to match this), you were
> > going to generate two security contexts for the user session, one based
> > on seusers and one based on the provided range, otherwise identical in
> > all respects, and apply a permission check between those two contexts.
> > So for example, if my seusers-defined default context would be
> > staff_u:staff_r:staff_t:s0-s0:c0.c255 and I entered a level of s0:c3 as
> > input, there would be a permission check made by pam_selinux between
> > staff_u:staff_r:staff_t:s0-s0:c0.c255 and staff_u:staff_r:staff_t:s0:c3.
>
> This should all be true.
>
> > Thus, the TE rule would have to be between staff_t and itself (i.e. the
> > user domains), not between local_login_t and anything.
>
> Right. Does the mlsconstrain line not do that?
The mlsconstrain line wasn't my concern - it was the TE rule.
> > We aren't checking whether login can do anything (or using its context
> > anywhere); we are checking whether the seusers-defined default context
> > for the user contains the user-supplied context.
>
> Right my understanding was that the policy line:
>
> allow $1 domain:context transition
>
> ...meant that the login program could make security call:
>
> security_compute_av(src, dst, SECCLASS_CONTEXT, CONTEXT__TRANSITION, &avd)
No. The ability to make the security call is controlled by the
compute_av permission on the security class, and isn't based on the
individual contexts passed as arguments. That would be:
allow $1 security_t:security compute_av;
which has an interface:
selinux_compute_access_vector($1)
which is already in authlogin.if. No change required for allowing the
call to happen.
What you are instead trying to do is to define the _result_ of that
compute_av call based on its arguments, not whether it can be made by
login. So the TE rule would go into userdomain.if and be of the form:
allow $1 self:context <permissionname>;
The mlsconstrain statement is ok, as long as it is sufficient to check
the high levels and not impose any constraint on the low levels.
--
Stephen Smalley
National Security Agency
More information about the redhat-lspp
mailing list