[redhat-lspp] Re: [PATCH 2/3] Re: MLS enforcing PTYs, sshd, and newrole

James Antill jantill at redhat.com
Tue Oct 31 16:04:12 UTC 2006


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?

> 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)

-- 
James Antill <jantill at redhat.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/redhat-lspp/attachments/20061031/47cf697b/attachment.sig>


More information about the redhat-lspp mailing list