[redhat-lspp] Re: ssh/xinetd/getpeercon???

[Joshua Brindle]

Joy Latten wrote:
> I have been playing with the ssh-mls which gets called through xinetd
> when labeled networking is in use and am confused about what I am
> seeing. :-)
>
> My assumption is that when using this feature, the resulting ssh
> connection will have single mls level, which is the effective level of
> the issuer. 
>
> For example, if I am
> uid=500(ealuser) gid=500(ealuser) groups=10(wheel),500(ealuser)
> context=staff_u:staff_r:staff_t:s3-s9
>
> When I issue ssh -p 222 -l <user> <host>, I expect to see "s3" as my new
> mls level in the new ssh connection when I do an "id".
>
> With CIPSO, this happens.
> With labeled ipsec, I get "s3-s9".
>
> Debugging xinetd, I noticed that when using CIPSO, getpeercon() returns 
> "system_u:object_r:unlabeled_t:s3".
>
> When using labeled ipsec, getpeercon() returns
> "root:sysadm_r:sysadm_ssh_t:s3-s9".
>
> I always wondered if getpeercon() would someday lift its head and bite,
> I just wish it had not been on Valentine's Day. :-)
> I am concerned about the mls label being returned.
>
> So, my question is, how is this suppose to work?
> Does CIPSO, when given an mls range, like s3-s9, only pass
> the effective level through in ip options? If so, is this 
> what labeled ipsec should be doing? Should we be setting only the 
> effective level in the SA? If so, that could potentially create 
> even more SAs. Or should xinetd, when given a range, should only
> set the effective level for the new process? I kinda like this 
> solution best, that is, xinetd setting single effective level. But
> I don't know if that is correct resolution? 
>
>   
IMO the entire context should be passed, in CIPSO's case that should be 
the range, if your clearance is s9 on one machine why wouldn't it be on 
another that uses the same levels? I'd hate to see userland interpreting 
ranges like this, it will cause assumptions about the mls policy to be 
made in userspace. While CIPSO is done entirely in the kernel (i think?) 
the decision should still not be made outside the security server which 
is the only part of the system that understands what s2-s9 even means 
(consider a modified mls policy where the second part of the range is 
something other than clearance.

It is (again, IMO) entirely inappropriate for racoon or xinetd or the 
CIPSO code to interpret contexts, this issue keeps coming up and the 
answer should always be that the context is interpreted by the security 
server exclusively.