All of lore.kernel.org
 help / color / mirror / Atom feed
* ipsec and getpeercon()
@ 2006-08-29 18:08 Joshua Brindle
  2006-08-29 18:20 ` Joshua Brindle
                   ` (2 more replies)
  0 siblings, 3 replies; 59+ messages in thread
From: Joshua Brindle @ 2006-08-29 18:08 UTC (permalink / raw)
  To: selinux; +Cc: paul.moore

I'm trying to use getpeercon() with a tcp stream socket over an ipsec
host2host connection and it isn't working, it always returns the context
of the local domain/socket:


[root@rawhide-clone ~]# runcon -t passwd_t ./server
server: got connection from 10.1.13.104, root:system_r:passwd_t:s0-s0:c0.c255

[root@rawhide-clone ~]# runcon -t initrc_t ./server
server: got connection from 10.1.13.104, root:system_r:initrc_t:s0-s0:c0.c255

the process connecting is unconfined_t

Am I doing something wrong or is something broken?

if ((new_fd = accept(sockfd, (struct sockaddr *)&their_addr,
                            &sin_size)) == -1) {
    perror("accept");
    continue;
}
if (getpeercon(new_fd, con))
         perror("getpeercon");
}
    printf("server: got connection from %s, %s\n",
                 inet_ntoa(their_addr.sin_addr), con);


I also tried getsockopt(new_fd, SOL_SOCKET, SO_PEERSEC, con, &len)


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

^ permalink raw reply	[flat|nested] 59+ messages in thread
* RE: ipsec and getpeercon()
@ 2006-08-30 16:43 Venkat Yekkirala
  2006-09-01 12:15 ` Joshua Brindle
  0 siblings, 1 reply; 59+ messages in thread
From: Venkat Yekkirala @ 2006-08-30 16:43 UTC (permalink / raw)
  To: Stephen Smalley, Joshua Brindle; +Cc: Joy Latten, selinux, paul.moore

> BTW, Joy & Venkat - it would be nice if the usage/configuration of the
> ipsec labeling was documented somewhere.  I've seen emails in the past
> with sample usage, but has it been captured anywhere we can 
> refer people
> to, like in the Fedora SELinux wiki?

If I remember right, Joy was either working on or had a comprehensive doc
from the original work on labeled ipsec that was going to be modified for
the recent changes and posted to selinux/redhat-lspp. My emails with sample
usage were more a stop gap as well as to aid in the modifications to the
original doc.

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

^ permalink raw reply	[flat|nested] 59+ messages in thread
* RE: ipsec and getpeercon()
@ 2006-09-01 13:16 Venkat Yekkirala
  2006-09-01 13:41 ` Stephen Smalley
  0 siblings, 1 reply; 59+ messages in thread
From: Venkat Yekkirala @ 2006-09-01 13:16 UTC (permalink / raw)
  To: Joshua Brindle; +Cc: Stephen Smalley, Joy Latten, selinux, paul.moore

> Ok, aside from the bug I'm apparently experiencing (Joy is 
> looking in to
> it) I think I have misunderstood what getpeercon() is suppose 
> to do over
> ipsec. I was under the impression it would act like getpeercon() over
> unix stream sockets and get the context of the application on 
> the other
> side of the socket but that is apparently not what getpeercon() for
> ipsec does.

It should indeed return the peer's context when using ipsec as well.
I would consider the current behaviour as a bug. Joy is looking but
I will try to take a look as well.

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

^ permalink raw reply	[flat|nested] 59+ messages in thread
* RE: ipsec and getpeercon()
@ 2006-09-01 14:35 Venkat Yekkirala
  2006-09-01 15:25 ` Joshua Brindle
  0 siblings, 1 reply; 59+ messages in thread
From: Venkat Yekkirala @ 2006-09-01 14:35 UTC (permalink / raw)
  To: Stephen Smalley; +Cc: Joshua Brindle, Joy Latten, selinux, paul.moore

> I'd tentatively guess that the lack of any definition or rules
> authorizing polmatch is causing the SAs to be left unlabeled.

It should have then returned the unlabeled context (if it were
working correctly).

> 
> But Joshua's point about needing to manually define spd entries per
> context (at least per TE domain/type, even if using a MLS 
> range), would
> still hold, right?

In the most practical/intuitive sense, yes, you would want to define
a unique spd entry for each domain you want to communicate. As for
"expectation of what domain is on the otherside" like Joshua was
wondering about, this could either be implicit (by using static SA's;
spi 0x01 could refer to a_t on one machine and b_t on the other machine)
or explicit (when using racoon to negotiate). In the latter case, a_t and
b_t must exist on both machines or the negotiation will fail.

Also in theory, multiple domains can share a single spd domain (by
polmatch'ing
to the spd domain), with the secmark rules doing finer differentiation in
conjunction with appropriate transition sid rules :).

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

^ permalink raw reply	[flat|nested] 59+ messages in thread
* RE: ipsec and getpeercon()
@ 2006-09-01 15:49 Venkat Yekkirala
  2006-09-01 16:52 ` Stephen Smalley
  2006-09-01 17:48 ` Joshua Brindle
  0 siblings, 2 replies; 59+ messages in thread
From: Venkat Yekkirala @ 2006-09-01 15:49 UTC (permalink / raw)
  To: Joshua Brindle; +Cc: Stephen Smalley, Joy Latten, selinux, paul.moore

> 
> Hrm, am I right in understanding that the selinux context from one
> machine is never sent over ipsec to the destination? 

Not verbatim, but only in the form of the spi (such as 0x001)
along with the encrypted packets.

The security context string is used in the IKE negotiations
though (resulting in the spi(s)).

> 
> What you talk about above (using static SA's which refer to different
> contexts on each side) is doable but seems inconvenient and fragile
> (multiple client domains talking to the same destination daemon using
> lots of SA's that have to be managed).
> 
> One option (maybe) is to get racoon to send the context of the
> connecting domain as part of the negotiation, this still requires lots
> of SA's.

I am thinking about this as well. Rather than use the Type specified in
the SPD rule, we could use the one from the connecting domain. Should
only be a minor change code-wise.

This way you could have just a set of domains that "polmatch"
to a specific policy domain/Type, but they could all be using
unique SAs based on the context of the connecting domain.

> 
> Another way is if I could have a local proxy that has a 
> single SA to the
> destination machine and can send an appropriate context in 
> the AH or ESP
> header (in the authentication data field? I don't now the 
> ipsec spec at
> all so I'm not sure if any of this is possible, please let me know if
> not so I can start looking elsewhere).

Not feasible AFAIK. The spi is the only identifier that can
reasonably be leveraged like we do currently.

> 
> Note that we may be sending contexts that aren't even valid 
> on the local
> machine, but would be valid on the destination machine. 

Could you please elaborate on this (a practical scenario).

> 
> is any of this possible?
> 

Sounds like we are making some progress here. Thanks for the discussion.

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

^ permalink raw reply	[flat|nested] 59+ messages in thread
* RE: ipsec and getpeercon()
@ 2006-09-01 18:17 Joy Latten
  0 siblings, 0 replies; 59+ messages in thread
From: Joy Latten @ 2006-09-01 18:17 UTC (permalink / raw)
  To: vyekkirala; +Cc: jbrindle, paul.moore, sds, selinux

>> Ok, aside from the bug I'm apparently experiencing (Joy is 
>> looking in to
>> it) I think I have misunderstood what getpeercon() is suppose 
>> to do over
>> ipsec. I was under the impression it would act like getpeercon() over
>> unix stream sockets and get the context of the application on 
>> the other
>> side of the socket but that is apparently not what getpeercon() for
>> ipsec does.
>
>It should indeed return the peer's context when using ipsec as well.
>I would consider the current behaviour as a bug. Joy is looking but
>I will try to take a look as well.

Ok, I looked at the code, and yes, if the socket class is 
tcp_socket, the dst for the socket is examined for a 
xfrm (in other words, an SA). If there is a xfrm, the context 
in the xfrm is used. Otherwise, we return -ENOPROTOOPT.

So yes, it is assumed that the context in the SA associated with the 
destination is the peer's context. I have always viewed labeled SAs 
as meaning, I want to restrict access to this socket/traffic stream 
to this context.  

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.

^ permalink raw reply	[flat|nested] 59+ messages in thread
* RE: ipsec and getpeercon()
@ 2006-09-01 19:34 Venkat Yekkirala
  0 siblings, 0 replies; 59+ messages in thread
From: Venkat Yekkirala @ 2006-09-01 19:34 UTC (permalink / raw)
  To: Joy Latten; +Cc: Joshua Brindle, paul.moore, Stephen Smalley, selinux

[-- Attachment #1: Type: text/plain, Size: 1981 bytes --]

Actually this must be coming out of netlabel. In selinux_netlbl_sock_graft()
I see
 
        sksec->nlbl_state = NLBL_REQUIRE;
        sksec->peer_sid = sksec->sid;
        sksec->sclass = isec->sclass;
 
        /* Try to set the NetLabel on the socket to save time later, if we
fail
         * here we will pick up the pieces in later calls to
         * selinux_netlbl_inode_permission(). */
        selinux_netlbl_socket_setsid(sock, sksec->sid);

and selinux_netlbl_socket_getpeersec_stream returns peer_sid set above and
the xfrm version of getpeersec never gets invoked.

-----Original Message-----
From: Joy Latten [mailto:latten@us.ibm.com]
Sent: Friday, September 01, 2006 11:05 AM
To: Venkat Yekkirala
Cc: Joshua Brindle; paul.moore@hp.com; Stephen Smalley;
selinux@tycho.nsa.gov
Subject: RE: ipsec and getpeercon()



Venkat Yekkirala <vyekkirala@TrustedCS.com> wrote on 09/01/2006 08:16:32 AM:

> > Ok, aside from the bug I'm apparently experiencing (Joy is 
> > looking in to
> > it) I think I have misunderstood what getpeercon() is suppose 
> > to do over
> > ipsec. I was under the impression it would act like getpeercon() over
> > unix stream sockets and get the context of the application on 
> > the other
> > side of the socket but that is apparently not what getpeercon() for
> > ipsec does.
> 
> It should indeed return the peer's context when using ipsec as well.
> I would consider the current behaviour as a bug. Joy is looking but
> I will try to take a look as well.

Ok, I looked at the code, and yes, in the hook, if the socket class is
tcp_socket, 
the dst for the socket is examined for a xfrm (in other words, an SA). If
there is a 
xfrm, the context in the xfrm is used. Otherwise, we return -ENOPROTOOPT. 

So yes, it is assumed that the context in the SA associated with the
destination 
is the peer's context. I have always viewed labeled SAs as meaning, I want
to restrict 
access to this socket/traffic stream to this context. 
  
Joy 
  



[-- Attachment #2: Type: text/html, Size: 3937 bytes --]

^ permalink raw reply	[flat|nested] 59+ messages in thread
* RE: ipsec and getpeercon()
@ 2006-09-01 19:41 Venkat Yekkirala
  0 siblings, 0 replies; 59+ messages in thread
From: Venkat Yekkirala @ 2006-09-01 19:41 UTC (permalink / raw)
  To: Stephen Smalley; +Cc: Joshua Brindle, Joy Latten, selinux, paul.moore

> > I am thinking about this as well. Rather than use the Type 
> specified in
> > the SPD rule, we could use the one from the connecting 
> domain. Should
> > only be a minor change code-wise.
> 
> In that case, can we just use the sender's context as a whole for the
> SA, and not derive a context from some combination of the 
> sender and the
> policy context?  Then we could even drop in a single spd entry that
> matches all contexts and still get per-context SAs.

Offhand I don't see why not. I will try this and post a patch next week.

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

^ permalink raw reply	[flat|nested] 59+ messages in thread
* RE: ipsec and getpeercon()
@ 2006-09-01 19:47 Joy Latten
  2006-09-01 20:19 ` Paul Moore
  0 siblings, 1 reply; 59+ messages in thread
From: Joy Latten @ 2006-09-01 19:47 UTC (permalink / raw)
  To: latten, vyekkirala; +Cc: jbrindle, paul.moore, sds, selinux

Yes, that is coming from netlabel. In selinux_socket_getpeersec_stream()
if the socket is tcp_socket class, we call the cipso routine
first, selinux_netlbl_socket_getpeersec_stream(). I have not
thoroughly examined the cipso code, but at a glance I assumed
if cipso is enabled and its maps set up, this will come back with
something. If it doesn't come back with anything, I assumed
that meant cipso is either disabled or its maps not set up. 
According to code, if nothing comes back from cipso, then 
selinux_socket_getpeer_stream() is called which will look 
for a xfrm on the dst. And if there is one, then use the security
context from the xfrm. Otherwise, return error.


hmmm... this makes me wonder if Joshua had cipso enabled and that is why
it looks like getpeercon was not honoring the ipsec labels... 

Joy

>Actually this must be coming out of netlabel. In selinux_netlbl_sock_graft()
>I see
> 
>        sksec->nlbl_state = NLBL_REQUIRE;
>        sksec->peer_sid = sksec->sid;
>        sksec->sclass = isec->sclass;
> 
>        /* Try to set the NetLabel on the socket to save time later, if we
>fail
>         * here we will pick up the pieces in later calls to
>         * selinux_netlbl_inode_permission(). */
>        selinux_netlbl_socket_setsid(sock, sksec->sid);
>
>and selinux_netlbl_socket_getpeersec_stream returns peer_sid set above and
>the xfrm version of getpeersec never gets invoked.
>
>-----Original Message-----
>From: Joy Latten [mailto:latten@us.ibm.com]
>Sent: Friday, September 01, 2006 11:05 AM
>To: Venkat Yekkirala
>Cc: Joshua Brindle; paul.moore@hp.com; Stephen Smalley;
>selinux@tycho.nsa.gov
>Subject: RE: ipsec and getpeercon()
>
>
>
>Venkat Yekkirala <vyekkirala@TrustedCS.com> wrote on 09/01/2006 08:16:32 AM:
>
>> > Ok, aside from the bug I'm apparently experiencing (Joy is 
>> > looking in to
>> > it) I think I have misunderstood what getpeercon() is suppose 
>> > to do over
>> > ipsec. I was under the impression it would act like getpeercon() over
>> > unix stream sockets and get the context of the application on 
>> > the other
>> > side of the socket but that is apparently not what getpeercon() for
>> > ipsec does.
>> 
>> It should indeed return the peer's context when using ipsec as well.
>> I would consider the current behaviour as a bug. Joy is looking but
>> I will try to take a look as well.
>
>Ok, I looked at the code, and yes, in the hook, if the socket class is
>tcp_socket, 
>the dst for the socket is examined for a xfrm (in other words, an SA). If
>there is a 
>xfrm, the context in the xfrm is used. Otherwise, we return -ENOPROTOOPT. 
>
>So yes, it is assumed that the context in the SA associated with the
>destination 
>is the peer's context. I have always viewed labeled SAs as meaning, I want
>to restrict 
>access to this socket/traffic stream to this context. 
>  
>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.

^ permalink raw reply	[flat|nested] 59+ messages in thread
* RE: ipsec and getpeercon()
@ 2006-09-01 19:52 Joy Latten
  0 siblings, 0 replies; 59+ messages in thread
From: Joy Latten @ 2006-09-01 19:52 UTC (permalink / raw)
  To: jbrindle, vyekkirala; +Cc: latten, paul.moore, sds, selinux


> I am thinking about this as well. Rather than use the Type specified in
> the SPD rule, we could use the one from the connecting domain. Should
> only be a minor change code-wise.
> 
> This way you could have just a set of domains that "polmatch"
> to a specific policy domain/Type, but they could all be using
> unique SAs based on the context of the connecting domain.
> 

I am not sure I understand. So for a particular traffic stream, the
Type(in regards to the security context) in the policy on the 
initiator is different than the Type in the policy on the receiver? 
And that both the initiator and receiver should send over their 
contexts and negotiate on which one to use?

Other than the policy, where would the receiving machine 
get its Type/domain from to send over for negotiating?  

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.

^ permalink raw reply	[flat|nested] 59+ messages in thread
* RE: ipsec and getpeercon()
@ 2006-09-01 20:35 Venkat Yekkirala
  2006-09-04 12:38 ` Joshua Brindle
  0 siblings, 1 reply; 59+ messages in thread
From: Venkat Yekkirala @ 2006-09-01 20:35 UTC (permalink / raw)
  To: Joshua Brindle; +Cc: Stephen Smalley, Joy Latten, selinux, paul.moore

<snip>
> so you want to implicitly label the SA's?

No, these will be explicit/unique SAs negotiated by IKE. We would
use the initiator's context in the negotiation (Joy, take note),
as opposed to using, as we currently do, the spd context (with the
mls portion taken from the initiator).

> I'm doubtful that this will
> help, unless applications are going to take on the burden of 
> setting up
> their own SA's, I'm not sure that will ever happen.

The above would be transparent to the apps (except that there's
a general issue, unrelated to our changes, with connection requests
failing the first time round while the negotiation is going on).

> 
> > This way you could have just a set of domains that "polmatch"
> > to a specific policy domain/Type, but they could all be using
> > unique SAs based on the context of the connecting domain.
> > 
> 
> Is there much overhead in having lots of SA's between 2 hosts?

I haven't had a chance to do any sort of performance analyses. But I would
guess that the impact from the label portion would be pretty small as
compared
to the base ipsec obverhead (and there probably are figures available out
there
on this). I don't know if Trent, Joy et al performed any analyses
in this regard for the original work.

> How can
> you do things like RPC where the port will be dynamic with 
> multiple SA's
> in use?

The standard ipsec policy for rpc services should already be
taking the dynamicity of port into account. The only difference
will be that there will be a different SA for each connection
when negotiated by IKE. Or did I miss something here?

IKE negotiation happens transparent to the apps (with the exception noted
above).

<snip>
> > > 
> > > Note that we may be sending contexts that aren't even valid 
> > > on the local
> > > machine, but would be valid on the destination machine. 
> > 
> > Could you please elaborate on this (a practical scenario).
> > 
> 
> The most obvious scenario I have is 2 SELinux machines, one using MLS
> and one not. The context on the client side 
> (root:sysadm_r:admin_tool_t)
> would be invalid on the destination.
> 
> We are also looking at how SELinux machines that are in different
> administrative realms can interact, particularly when the policies are
> disparate and they have no shared namespace and the context structure
> may or may not be the same (as above).
> 
> We basically need to be able to send an opaque context to the
> destination that is not verified locally (via a trusted proxy) 

Currently, there's an expectation of at least the IPSec portions of the
policy namespace being shared between the machines (and also either all mls
or no-mls), for racoon negotiation to work. An alternative might be using
statically defined SAs where spi 0x001 would mean a_t on machine A and b_t
on machine B.

Long term, we may want to build handling of IPSec DOIs into racoon/IKE.

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

^ permalink raw reply	[flat|nested] 59+ messages in thread
* RE: ipsec and getpeercon()
@ 2006-09-01 20:49 Venkat Yekkirala
  2006-09-01 20:58 ` Paul Moore
  0 siblings, 1 reply; 59+ messages in thread
From: Venkat Yekkirala @ 2006-09-01 20:49 UTC (permalink / raw)
  To: Paul Moore, Joy Latten; +Cc: latten, Venkat Yekkirala, jbrindle, sds, selinux

> Unfortunately, the fix
> is not immediately obvious.

You would use the xfrm_sid and in it's absence the node
sid as the base sid.

If using secmark, it will get copied into peer_sid.

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

^ permalink raw reply	[flat|nested] 59+ messages in thread
* RE: ipsec and getpeercon()
@ 2006-09-01 22:42 Joy Latten
  0 siblings, 0 replies; 59+ messages in thread
From: Joy Latten @ 2006-09-01 22:42 UTC (permalink / raw)
  To: jbrindle, vyekkirala; +Cc: latten, paul.moore, sds, selinux

>> so you want to implicitly label the SA's?
>
>No, these will be explicit/unique SAs negotiated by IKE. We would
>use the initiator's context in the negotiation (Joy, take note),
>as opposed to using, as we currently do, the spd context (with the
>mls portion taken from the initiator).
>
Ok, I actually kinda like this idea if I am understanding it
correctly. :-) So, the context we place in the policy would really
be associated with what the local machine will accept?

So for example, the initiator's context which is gotten from 
the kernel along with the ACQUIRE message would be sent over.
Where would this context come from? Would it be the context
of the process or socket that wanted to send the packet?
Would we still need to do some of the checks we currently do? 
For example, do we have association:sendto and 
association:polmatch permissions?  

The initiator's context is sent over in IKE's negotiation.
Does the remote guy determine if he will accept
this security context based on the security context within the
policy he has for this particular traffic stream? If it is outside
the scope of his policy's security context he rejects it and if it 
is within, he accepts it and the two create a pair of SAs for
this traffic stream with this particular context?

My only concern for now is that the initiator may be able to send
over anything he wants, if I am understanding correctly.
What about all the different types that could be sent
over? Do we want to control what initiator can send? Or that 
is not important, as long as we control what is accepted? 
I am not sure though how several types would map to just one type
in a policy? Or am I misunderstanding and the type
sent in security context must be same as type in remote's policy,
but the remote's policy will have an mls range that allows
many SAs to be mapped to one policy?

Ok, that's all for today. :-)

Regards,
Joy

>>> I'm doubtful that this will
>>> help, unless applications are going to take on the burden of 
>>> setting up
>>> their own SA's, I'm not sure that will ever happen.
>>
>>The above would be transparent to the apps (except that there's
>>a general issue, unrelated to our changes, with connection requests
>>failing the first time round while the negotiation is going on).
>
>> 
>> > This way you could have just a set of domains that "polmatch"
>> > to a specific policy domain/Type, but they could all be using
>> > unique SAs based on the context of the connecting domain.
>> > 
>> 
>> Is there much overhead in having lots of SA's between 2 hosts?
>
>I haven't had a chance to do any sort of performance analyses. But I would
>guess that the impact from the label portion would be pretty small as
>compared
>to the base ipsec obverhead (and there probably are figures available out
>there
>on this). I don't know if Trent, Joy et al performed any analyses
>in this regard for the original work.
>

Actually, there have been many recent changes made to xfrm code
in the kernel to significantly improve xfrm insertion and I think
lookups too.


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.

^ permalink raw reply	[flat|nested] 59+ messages in thread
* Re: ipsec and getpeercon()
@ 2006-09-05 14:36 Joy Latten
  0 siblings, 0 replies; 59+ messages in thread
From: Joy Latten @ 2006-09-05 14:36 UTC (permalink / raw)
  To: jbrindle, paul.moore; +Cc: latten, latten, sds, selinux, vyekkirala

>Or it could just be that I'm retarded and booted up on the wrong kernel
>after cloning the VM. The new results (with no SAD or SPD entries) is a
>nice "Protocol not available" on both sides. With the entries I now get 
>
>server: got connection from 10.1.13.104, system_u:object_r:unlabeled_t
>
>which is the correct label of the local ipsec socket (changed it to make
>sure it was getting the local context) which still isn't what I'd expect
>getpeercon() to tell me.
>

Actually, this sounds correct. If neither Cipso nor IPSec or configured,
then code should return -ENOPROTOPT. Thus the "Protocol not available".

When using basic IPSec, two SAs, an In & Out SA must exist for each 
traffic stream you wish to protect and on both the local and remote machines. 
When using labeled SAs, we have extended this such that whatever you have
as the label in the SA, is what that socket is restricted to send or receive on 
both the local and remote machines. Thus you can conclude, that the 
label getpeercon() gets back from labeled SA is the label of the remote socket.

Yes, this can result in lots of SAs, but that is something we did consider.
Some work has been done recently by the networking maintainer to improve
performance inserting and I think searching the policy and SA databases.

I have started working on the documentation on how to use the labeled
SA feature.

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.

^ permalink raw reply	[flat|nested] 59+ messages in thread
* RE: ipsec and getpeercon()
@ 2006-09-05 15:43 Venkat Yekkirala
  2006-09-05 16:01 ` Paul Moore
  0 siblings, 1 reply; 59+ messages in thread
From: Venkat Yekkirala @ 2006-09-05 15:43 UTC (permalink / raw)
  To: Paul Moore, Stephen Smalley
  Cc: Joshua Brindle, Joy Latten, latten, Venkat Yekkirala, selinux

> When NetLabel accepts an incoming connection it sets the 
> context of the
> local socket to equal the context of the connection.  Since NetLabel
> currently only supports sending the MLS label this context is 
> created by
> taking the non-MLS portion of the context (user:role:type) from the
> parent socket and the MLS label from the connection.  This is how the
> child socket is labeled

Thus far it's fine, but netlabel sets the peer_sid also to this context
which
would be incorrect. The TE portion of the "peer context" should ideally
be obtained from either the xfrm sid if present or in its absence the node
sid
(in the compat case).

In the secmark world, we will be setting peer_sid to the final secmark
of the packet (post reconciliation). So, I am not as much worried about
the above netlabel behavior (unless someone is intent on using the compat
case in conjunction with cipso with any seriousness).

> and this is the context reported to userspace
> when a getpeercon() call is made when NetLabel is in use.
> 
> Once NetLabel supports full contexts there will not be any need to use
> the parent socket's context.
> 
> -- 
> 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.

^ permalink raw reply	[flat|nested] 59+ messages in thread
* RE: ipsec and getpeercon()
@ 2006-09-05 16:14 Venkat Yekkirala
  2006-09-05 16:27 ` Paul Moore
  0 siblings, 1 reply; 59+ messages in thread
From: Venkat Yekkirala @ 2006-09-05 16:14 UTC (permalink / raw)
  To: Paul Moore; +Cc: Stephen Smalley, Joshua Brindle, Joy Latten, latten, selinux

> What would you propose the proper behavior for when there is 
> no xfrm or
> node sid?

The netif sid and in it's absense, the unlabeled init sid.

>  It seems to be much more consistent (and desirable) to pull
> the TE bits from a single source.

If the single source were the correct source, then yes. :)

>  Also, from a practical 
> point of view
> I suspect it to be very unlikely that anyone would be using more than
> one form of network labeling for a connection.  Meaning that I would
> expect the common case for NetLabel to be no xfrm or node sid.

Well, a node/netif could be used to constrain the range of cipso labels
that can come/leave thru to the node/interface. Example: Secret on one
netif, TS on another.

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

^ permalink raw reply	[flat|nested] 59+ messages in thread
* RE: ipsec and getpeercon()
@ 2006-09-05 16:27 Venkat Yekkirala
  0 siblings, 0 replies; 59+ messages in thread
From: Venkat Yekkirala @ 2006-09-05 16:27 UTC (permalink / raw)
  To: Paul Moore; +Cc: Stephen Smalley, Joshua Brindle, Joy Latten, latten, selinux

> > In the secmark world, we will be setting peer_sid to the 
> final secmark
> > of the packet (post reconciliation). So, I am not as much 
> worried about
> > the above netlabel behavior (unless someone is intent on 
> using the compat
> > case in conjunction with cipso with any seriousness).
> 
> This is an important discussion but I think it's probably 
> best until you
> post the entire secid reconciliation patch so we are all on 
> the same page.

Well, there are always people out there that appreciate getting a feel
for what's coming up, but I understand your anxiousness. :)

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

^ permalink raw reply	[flat|nested] 59+ messages in thread
* RE: ipsec and getpeercon()
@ 2006-09-05 16:42 Venkat Yekkirala
  2006-09-05 17:10 ` Paul Moore
  0 siblings, 1 reply; 59+ messages in thread
From: Venkat Yekkirala @ 2006-09-05 16:42 UTC (permalink / raw)
  To: Paul Moore; +Cc: Stephen Smalley, Joshua Brindle, Joy Latten, latten, selinux

> >>What would you propose the proper behavior for when there is 
> >>no xfrm or
> >>node sid?
> > 
> > The netif sid and in it's absense, the unlabeled init sid.
> 
> I don't like using the default unlabeled sid, it implies that 
> the packet
> is not labeled when it is - just not with any TE information.

That's right. You would convey this by using the unlabeled init sid
as the base sid, and replacing the mls portion with the cipso label.

> 
> I think that when you get down to it, in the absence of a xfrm or node
> sid any TE value in the case of getpeercon() is going to be equally
> "right" or "wrong" as they are all generated values in 
> absence

TE is not really absent here. It's just not explicit in some cases, meaning
it has the "unlabeled" label.

> of the TE
> bits.  Using the socket's sid as a TE base makes the most 
> sense to me as
> that is what is used to make access decisions on accepting the packet
> into the socket's receive buffer.

It's definitely used as the subject sid, but for the object sid, you would
ideally want to do what I mentioned earlier.

> 
> >> Also, from a practical 
> >>point of view
> >>I suspect it to be very unlikely that anyone would be using 
> more than
> >>one form of network labeling for a connection.  Meaning that I would
> >>expect the common case for NetLabel to be no xfrm or node sid.
> > 
> > Well, a node/netif could be used to constrain the range of 
> cipso labels
> > that can come/leave thru to the node/interface. Example: 
> Secret on one
> > netif, TS on another.
> 
> Yep, that's possibile, but not required.  I suspect we can play
> everybody's favorite game of "Guess What the User's Thinking!" all day
> long if we like ;)

I can only share what I have noticed over the last 8 years.

All in all, I don't want to continue to beat a soon-to-be-dead horse any
more :)

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

^ permalink raw reply	[flat|nested] 59+ messages in thread
* RE: ipsec and getpeercon()
@ 2006-09-05 20:01 Venkat Yekkirala
  2006-09-06 15:55 ` Joshua Brindle
  0 siblings, 1 reply; 59+ messages in thread
From: Venkat Yekkirala @ 2006-09-05 20:01 UTC (permalink / raw)
  To: Joy Latten, jbrindle, paul.moore; +Cc: latten, sds, selinux

> >Or it could just be that I'm retarded and booted up on the 
> wrong kernel
> >after cloning the VM. The new results (with no SAD or SPD 
> entries) is a
> >nice "Protocol not available" on both sides. With the 
> entries I now get 
> >
> >server: got connection from 10.1.13.104, 
> system_u:object_r:unlabeled_t
> >
> >which is the correct label of the local ipsec socket 
> (changed it to make
> >sure it was getting the local context) which still isn't 
> what I'd expect
> >getpeercon() to tell me.
> >
> 
> Actually, this sounds correct. If neither Cipso nor IPSec or 
> configured,
> then code should return -ENOPROTOPT. Thus the "Protocol not 
> available".
> 
> When using basic IPSec, two SAs, an In & Out SA must exist for each 
> traffic stream you wish to protect and on both the local and 
> remote machines. 
> When using labeled SAs, we have extended this such that 
> whatever you have
> as the label in the SA, is what that socket is restricted to 
> send or receive on 
> both the local and remote machines. Thus you can conclude, that the 
> label getpeercon() gets back from labeled SA is the label of 
> the remote socket.
> 

It should have been whatever context is associated with the incoming SA.
But the current code returns the context associated with the outgoing SA
and this is not right. Even so, this doesn't explain getpeercon returning
the local socket context as opposed to the outgoing SA's context (which
is derived from the SPD entry currently).

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

^ permalink raw reply	[flat|nested] 59+ messages in thread
* RE: ipsec and getpeercon()
@ 2006-09-05 20:04 Venkat Yekkirala
  0 siblings, 0 replies; 59+ messages in thread
From: Venkat Yekkirala @ 2006-09-05 20:04 UTC (permalink / raw)
  To: Joshua Brindle, Stephen Smalley
  Cc: Paul Moore, Joy Latten, latten, Venkat Yekkirala, selinux

> Yes, I'm getting the local socket context. I don't know whether its
> netlabel or ipsec, it only happens when i have an spd policy 
> specifying
> the context for ipsec, without an sa set up i get 
> 
Did you mean to post any results here?

Are you sure you are seeing the socket context as opposed to the
label associated with the outgoing SA? Are you running racoon to negotiate
SAs?
Are you using labels on SPD entries? Can you get us your latest
configeration?

Can you perform the following steps and let us know what you see:

- setkey -DP
- setkey -D
- Run server proc that accepts, does getpeercon and then sleeps for a few
minutes.
- While the server is sleeping, display label on the server proc.
- setkey -DP
- setkey -D

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

^ permalink raw reply	[flat|nested] 59+ messages in thread
* RE: ipsec and getpeercon()
@ 2006-09-06 16:19 Venkat Yekkirala
  0 siblings, 0 replies; 59+ messages in thread
From: Venkat Yekkirala @ 2006-09-06 16:19 UTC (permalink / raw)
  To: Joshua Brindle; +Cc: Joy Latten, paul.moore, latten, sds, selinux

> Actually I think I'm finally getting the expected results, the context
> for the outgoing (which is incorrect but expected?) SPD entry on the
> local machine.

Good. We are all on the same page so far.
> 
> This, however, is not what I'd expect. I guess when I heard "labeled
> network over ipsec" I thought the labels (from the source 
> domain) would
> traverse the wire and be readable on the destination. 

This can very much be accomplished by appropriate policy rules as explained
further down.

> 
> I don't know how useful or even usable the current setup is, 
> what is the
> use case you guys are going for?
> 

Source machine:

- a_t polmatch'es spd entry that's associated with spd1_t
- racoon negotiates/creates sa with a_t (currently it creates
	sa with spd1_t but I am going to change this).
- packet gets encrypted with spi 0x001 (which by now maps to
	a_t on both the source and destination)

Destination machine:

- packet with spi 0x001 received
- packet initially gets secmark'ed with iptables context (ip_t)
	like it currently does.
- secid reconciliation will reconcile a_t (that spi 0x001 maps to)
	with ip_t using the transition sid mechanism and arrives at:
		a. a_t (default when no transition rule exists).
		b. trans_t (which can very well be ip_t or ip_a_t or
			a_ip_t or whatever)
- you now have a packet that has a_t (default) or a local policy
	interpretation (using transition rules).
- Socket Vs. packet.secmark checks and others will follow as they
  currently do.

We essentially leverage the spi on ipsec packets to denote its
context.

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

^ permalink raw reply	[flat|nested] 59+ messages in thread
* RE: ipsec and getpeercon()
@ 2006-09-06 16:20 Venkat Yekkirala
  0 siblings, 0 replies; 59+ messages in thread
From: Venkat Yekkirala @ 2006-09-06 16:20 UTC (permalink / raw)
  To: Joshua Brindle; +Cc: Joy Latten, paul.moore, latten, sds, selinux

Might I also reiterate that the peer_sid on the tcp sock will
be set to the reconciled secmark, and getpeercon will
return this.

> -----Original Message-----
> From: Venkat Yekkirala 
> Sent: Wednesday, September 06, 2006 11:19 AM
> To: 'Joshua Brindle'
> Cc: Joy Latten; paul.moore@hp.com; latten@us.ibm.com; 
> sds@tycho.nsa.gov;
> selinux@tycho.nsa.gov
> Subject: RE: ipsec and getpeercon()
> 
> 
> > Actually I think I'm finally getting the expected results, 
> the context
> > for the outgoing (which is incorrect but expected?) SPD entry on the
> > local machine.
> 
> Good. We are all on the same page so far.
> > 
> > This, however, is not what I'd expect. I guess when I heard "labeled
> > network over ipsec" I thought the labels (from the source 
> > domain) would
> > traverse the wire and be readable on the destination. 
> 
> This can very much be accomplished by appropriate policy 
> rules as explained
> further down.
> 
> > 
> > I don't know how useful or even usable the current setup is, 
> > what is the
> > use case you guys are going for?
> > 
> 
> Source machine:
> 
> - a_t polmatch'es spd entry that's associated with spd1_t
> - racoon negotiates/creates sa with a_t (currently it creates
> 	sa with spd1_t but I am going to change this).
> - packet gets encrypted with spi 0x001 (which by now maps to
> 	a_t on both the source and destination)
> 
> Destination machine:
> 
> - packet with spi 0x001 received
> - packet initially gets secmark'ed with iptables context (ip_t)
> 	like it currently does.
> - secid reconciliation will reconcile a_t (that spi 0x001 maps to)
> 	with ip_t using the transition sid mechanism and arrives at:
> 		a. a_t (default when no transition rule exists).
> 		b. trans_t (which can very well be ip_t or ip_a_t or
> 			a_ip_t or whatever)
> - you now have a packet that has a_t (default) or a local policy
> 	interpretation (using transition rules).
> - Socket Vs. packet.secmark checks and others will follow as they
>   currently do.
> 
> We essentially leverage the spi on ipsec packets to denote its
> context.
> 

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

^ permalink raw reply	[flat|nested] 59+ messages in thread
end of thread, other threads:[~2006-09-06 16:20 UTC | newest]

Thread overview: 59+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-08-29 18:08 ipsec and getpeercon() Joshua Brindle
2006-08-29 18:20 ` Joshua Brindle
2006-08-29 18:28   ` Paul Moore
2006-08-29 19:28 ` Paul Moore
2006-08-29 19:37 ` Stephen Smalley
2006-08-29 19:46   ` Joshua Brindle
2006-08-29 20:25     ` Stephen Smalley
2006-08-29 20:32       ` Stephen Smalley
2006-08-29 21:11         ` Klaus Weidner
2006-08-30 11:28           ` Stephen Smalley
2006-08-29 22:37       ` Joshua Brindle
  -- strict thread matches above, loose matches on Subject: below --
2006-08-30 16:43 Venkat Yekkirala
2006-09-01 12:15 ` Joshua Brindle
2006-09-01 13:16 Venkat Yekkirala
2006-09-01 13:41 ` Stephen Smalley
2006-09-01 14:35 Venkat Yekkirala
2006-09-01 15:25 ` Joshua Brindle
2006-09-01 15:40   ` Paul Moore
2006-09-04 12:59     ` Joshua Brindle
2006-09-05  3:50       ` Paul Moore
2006-09-01 15:49 Venkat Yekkirala
2006-09-01 16:52 ` Stephen Smalley
2006-09-01 17:48 ` Joshua Brindle
2006-09-01 18:17 Joy Latten
2006-09-01 19:34 Venkat Yekkirala
2006-09-01 19:41 Venkat Yekkirala
2006-09-01 19:47 Joy Latten
2006-09-01 20:19 ` Paul Moore
2006-09-04 12:43   ` Joshua Brindle
2006-09-05  3:32     ` Paul Moore
2006-09-05 11:58       ` Joshua Brindle
2006-09-05 13:31         ` Stephen Smalley
2006-09-05 13:34           ` Joshua Brindle
2006-09-05 15:24             ` Paul Moore
2006-09-05 15:22           ` Paul Moore
2006-09-01 19:52 Joy Latten
2006-09-01 20:35 Venkat Yekkirala
2006-09-04 12:38 ` Joshua Brindle
2006-09-01 20:49 Venkat Yekkirala
2006-09-01 20:58 ` Paul Moore
2006-09-01 22:32   ` Paul Moore
2006-09-04 18:51     ` Joshua Brindle
2006-09-05  4:00       ` Paul Moore
2006-09-05 11:53         ` Joshua Brindle
2006-09-05 15:15           ` Paul Moore
2006-09-01 22:42 Joy Latten
2006-09-05 14:36 Joy Latten
2006-09-05 15:43 Venkat Yekkirala
2006-09-05 16:01 ` Paul Moore
2006-09-05 16:14 Venkat Yekkirala
2006-09-05 16:27 ` Paul Moore
2006-09-05 16:27 Venkat Yekkirala
2006-09-05 16:42 Venkat Yekkirala
2006-09-05 17:10 ` Paul Moore
2006-09-05 20:01 Venkat Yekkirala
2006-09-06 15:55 ` Joshua Brindle
2006-09-05 20:04 Venkat Yekkirala
2006-09-06 16:19 Venkat Yekkirala
2006-09-06 16:20 Venkat Yekkirala

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.