Labeling traffic over loopback

Labeling traffic over loopback

[Venkat Yekkirala]

The following describes a proposal to label traffic over loopback
by using a bit in the sk_buff structure. We have:

struct sk_buff {
...
        struct  sec_path        *sp;
...
        __u8                    pkt_type:3,
                                fclone:2,
                                ipvs_property:1;
...
}

We could use an additional bit (local_label) to denote that
"sp" holds the source label sid (no blob, so no lifecycle mgmt).

What do people think?

--
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: Labeling traffic over loopback

[Paul Moore]

Venkat Yekkirala wrote:
> The following describes a proposal to label traffic over loopback
> by using a bit in the sk_buff structure. We have:
> 
> struct sk_buff {
> ...
>         struct  sec_path        *sp;
> ...
>         __u8                    pkt_type:3,
>                                 fclone:2,
>                                 ipvs_property:1;
> ...
> }
> 
> We could use an additional bit (local_label) to denote that
> "sp" holds the source label sid (no blob, so no lifecycle mgmt).
> 
> What do people think?

Can you give an example of what the *sp value would look like?  Are you thinking
of adding a new field to 'sec_path' or would you create a sort of dummy
'xfrm_state' entry?  Or is it something else entirely that I am missing?

-- 
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: Labeling traffic over loopback

[Venkat Yekkirala]

> > We could use an additional bit (local_label) to denote that
> > "sp" holds the source label sid (no blob, so no lifecycle mgmt).
> > 
> > What do people think?
> 
> Can you give an example of what the *sp value would look 
> like?  Are you thinking
> of adding a new field to 'sec_path' or would you create a 
> sort of dummy
> 'xfrm_state' entry?

Nope. Note "(no blob, so no lifecycle mgmt)".
More specifically, we could use a union in place of sp and
when we are looking at a loopback packet and no xfrm in use
we could use the union to hold the secid.

--
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: Labeling traffic over loopback

[Paul Moore]

Venkat Yekkirala wrote:
>>>We could use an additional bit (local_label) to denote that
>>>"sp" holds the source label sid (no blob, so no lifecycle mgmt).
>>>
>>>What do people think?
>>
>>Can you give an example of what the *sp value would look 
>>like?  Are you thinking
>>of adding a new field to 'sec_path' or would you create a 
>>sort of dummy
>>'xfrm_state' entry?
> 
> Nope. Note "(no blob, so no lifecycle mgmt)".

True *sp is a blob, but it already has all the lifecycle mgmt code in place so I
don't think adding to it would be an 'evil' thing.  However, I could be wrong.

> More specifically, we could use a union in place of sp and
> when we are looking at a loopback packet and no xfrm in use
> we could use the union to hold the secid.

Do you have some pseudo code for setting this value, i.e. where are you thinking
of setting it on the outbound packet?

-- 
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: Labeling traffic over loopback

[Venkat Yekkirala]

> > Nope. Note "(no blob, so no lifecycle mgmt)".
> 
> True *sp is a blob, but it already has all the lifecycle mgmt 
> code

which we wouldn't want to invoke for loopback to avoid the
expense involved.

> in place so I
> don't think adding to it would be an 'evil' thing.  However, 
> I could be wrong.
> 
> > More specifically, we could use a union in place of sp and
> > when we are looking at a loopback packet and no xfrm in use
> > we could use the union to hold the secid.
> 
> Do you have some pseudo code for setting this value, i.e. 
> where are you thinking
> of setting it on the outbound packet?

I would like to hear James' and others' thoughts
before diving into code. James?

--
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: Labeling traffic over loopback

[James Morris]

On Tue, 12 Dec 2006, Venkat Yekkirala wrote:

> I would like to hear James' and others' thoughts
> before diving into code. James?

I tend to agree with Casey, in that it's generally bad to re-use pointers.

I think it's unlikely to be accepted upstream.


- James
-- 
James Morris
<jmorris@namei.org>

--
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: Labeling traffic over loopback

[Venkat Yekkirala]

> I tend to agree with Casey, in that it's generally bad to 
> re-use pointers.
> 
> I think it's unlikely to be accepted upstream.

I wasn't specific initially, but later in the thread I clarified
that we were actually looking at a union to take the place of sp
which isn't used for loopback any way and when it is, the label
would come from the SA anyway.

--
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: Labeling traffic over loopback

[James Morris]

On Wed, 13 Dec 2006, Venkat Yekkirala wrote:

> I wasn't specific initially, but later in the thread I clarified
> that we were actually looking at a union to take the place of sp
> which isn't used for loopback any way and when it is, the label
> would come from the SA anyway.

I guess you could ask on netdev, using some psuedo-code to illustrate.
All existing direct references to sp may need to be encpauslated with 
static inlines which assert the correct state.


-- 
James Morris
<jmorris@namei.org>

--
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: Labeling traffic over loopback

[Joy Latten]

On Tue, 2006-12-12 at 10:00 -0600, Venkat Yekkirala wrote:
> The following describes a proposal to label traffic over loopback
> by using a bit in the sk_buff structure. We have:
> 
> struct sk_buff {
> ...
>         struct  sec_path        *sp;
> ...
>         __u8                    pkt_type:3,
>                                 fclone:2,
>                                 ipvs_property:1;
> ...
> }
> 
> We could use an additional bit (local_label) to denote that
> "sp" holds the source label sid (no blob, so no lifecycle mgmt).
> 
> What do people think?

I just took a quick look at racoon code... in the samples directory
where sample configs live, I saw a config with,

sainfo address ::1 icmp6 address ::1 icmp6
{
        pfs_group 3;
        lifetime time 60 sec;
        encryption_algorithm 3des, blowfish, aes;
        authentication_algorithm hmac_sha1, hmac_md5;
        compression_algorithm deflate;
}

My thinking (and I could be wrong as I am not an ipv6 nor racoon expert)
is this specifies SA info over loopback for icmp6. 
If we can specify it for ipv6 then we should be able to specify
it for ipv4.

I think we should play around with racoon and its config... I'll also
ask on the ipsec-tools mailing list about racoon working with loopback. 
 

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: Labeling traffic over loopback

[Casey Schaufler]

--- Venkat Yekkirala <vyekkirala@TrustedCS.com> wrote:

> The following describes a proposal to label traffic
> over loopback
> by using a bit in the sk_buff structure. We have:
> 
> struct sk_buff {
> ...
>         struct  sec_path        *sp;
> ...
>         __u8                    pkt_type:3,
>                                 fclone:2,
>                                 ipvs_property:1;
> ...
> }
> 
> We could use an additional bit (local_label) to
> denote that
> "sp" holds the source label sid (no blob, so no
> lifecycle mgmt).
> 
> What do people think?

I can't speak for other people, but every time
I've seen the space in a pointer stolen as
storage for data it's lead to tears.
It may be expediant for the problem at hand,
but you'll never be able to share the
interface* if you break it in this way.
If you must do this sort of thing use a union
so that there's some hope of maintaining the
interface moving forward.

----
* I know that it seems unlikely that you'll
  ever need to, but the network labeling scheme
  is reasonably attractive.


Casey Schaufler
casey@schaufler-ca.com

--
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: Labeling traffic over loopback

[Venkat Yekkirala]

In thinking more about this, we shouldn't actually need to use
the single bit in skbuff. We should just be able to use the
variable that denotes if xfrm over loopback is in use. Any time
xfrm over loopback isn't in use (the default), we could use sp
to hold the secid.

> -----Original Message-----
> From: Venkat Yekkirala [mailto:vyekkirala@trustedcs.com]
> Sent: Tuesday, December 12, 2006 10:01 AM
> To: 'selinux@tycho.nsa.gov'
> Cc: 'jmorris@namei.org'; 'sds@tycho.nsa.gov'
> Subject: Labeling traffic over loopback
> 
> 
> The following describes a proposal to label traffic over loopback
> by using a bit in the sk_buff structure. We have:
> 
> struct sk_buff {
> ...
>         struct  sec_path        *sp;
> ...
>         __u8                    pkt_type:3,
>                                 fclone:2,
>                                 ipvs_property:1;
> ...
> }
> 
> We could use an additional bit (local_label) to denote that
> "sp" holds the source label sid (no blob, so no lifecycle mgmt).
> 
> What do people think?
> 

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