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

[Joy Latten]

On Wed, 2007-02-14 at 20:48 -0500, Joshua Brindle wrote:
> 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.
> 
I think I became confused because when I saw that getpeercon() returned
single mls level (s3) for CIPSO and a range (s3-s9) for labeled ipsec. I
knew the user:role:type would perhaps be different, but I was not
expecting the mls level too. I guess I learned something new about the
cipso implementation. :-) 

It seems everything is working ok. Klaus W. says it is ok that
ssh-mls uses a range for labeled ipsec and just the effective level for
cipso. Both protocols appear to work correctly with the xinetd/ssh-mls
implementation.

Joy