ssh/xinetd/getpeercon???

ssh/xinetd/getpeercon???

[Joy Latten]

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? 

Regards,
Joy

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

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.



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

Re: ssh/xinetd/getpeercon???

[Stephen Smalley]

On Wed, 2007-02-14 at 17:26 -0600, 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? 

The labeled networking mechanism should convey the full context when
possible (naturally, with a legacy mechanism like CIPSO, we may not have
that option except by using something like James Morris' Selopt
approach, which naturally won't be compatible with legacy trusted OSes).
  
-- 
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.

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

[Paul Moore]

On Wednesday, February 14 2007 8:48:32 pm Joshua Brindle wrote:
> Joy Latten wrote:
> > 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.

The CIPSO protocol does not have any concept of a MLS "range", it only allows 
for packets to be labeled with a single sensitivity level and category set.

Currently the NetLabel code only supports a single MLS level.  There are two 
reasons for this:

1. I tend to think packets are objects and as we have seen through numerous 
discussions, "ranged" objects don't make much sense.
2. NetLabel doesn't currently support any protocols which provide a "ranged" 
packet label.

The decision to use the lower/effective/zero-element-in-the-range-array when 
setting the security attributes of a socket using NetLabel is done in the 
SELinux code, not the general NetLabel code and not userspace.

-- 
paul moore
linux security @ hp

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

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


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