ipsec and getpeercon()

ipsec and getpeercon()

[Joshua Brindle]

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.

Re: ipsec and getpeercon()

[Joshua Brindle]

On Tue, 2006-08-29 at 14:08 -0400, Joshua Brindle wrote:
> 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)
> 

It also doesn't work at all on the client side:

[root@rawhide ~]# ./client 10.1.13.90
getpeercon: Protocol not available


--
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: ipsec and getpeercon()

[Paul Moore]

Joshua Brindle wrote:
> On Tue, 2006-08-29 at 14:08 -0400, Joshua Brindle wrote:
> 
>>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)
>>
> 
> 
> It also doesn't work at all on the client side:
> 
> [root@rawhide ~]# ./client 10.1.13.90
> getpeercon: Protocol not available
> 

I realize they are probably pretty simple, but do you have the sources
of your test programs posted anywhere?

-- 
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: ipsec and getpeercon()

[Paul Moore]

Joshua Brindle wrote:
> 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:

This may not help you, but I did a quick test using both the current
rawhide kernel as well as David Miller's net-2.6.19 git tree (with the
patchset I posted earlier applied) using NetLabel/CIPSO and everything
worked as expected, i.e. the MLS label of the context was correct.

> [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)
> 

-- 
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: ipsec and getpeercon()

[Stephen Smalley]

On Tue, 2006-08-29 at 14:08 -0400, Joshua Brindle wrote:
> 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?

You didn't provide much information above.  Kernel version?  ipsec-tools
version?  racoon version?  ipsec configuration?  setkey -D output?
setkey -DP output?

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

-- 
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: ipsec and getpeercon()

[Joshua Brindle]

On Tue, 2006-08-29 at 15:37 -0400, Stephen Smalley wrote:
> On Tue, 2006-08-29 at 14:08 -0400, Joshua Brindle wrote:
> > 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?
> 
> You didn't provide much information above.  Kernel version?  ipsec-tools
> version?  racoon version?  ipsec configuration?  setkey -D output?
> setkey -DP output?

Sorry,

Linux rawhide-clone 2.6.17-1.2586.fc6 #1 SMP Thu Aug 24 08:51:22 EDT
2006 i686 i686 i386 GNU/Linux

ipsec-tools.i386                         0.6.5-3.1

[root@rawhide-clone ~]# setkey -D
10.1.13.104 10.1.13.90
        esp mode=transport spi=43920387(0x029e2c03) reqid=0(0x00000000)
        E: 3des-cbc  ed1dd172 479fc39e 699c619d d626a652 9489f426
12bec67e
        A: hmac-sha1  6917f1a2 30a207f8 a1680143 5d490f66 431fd11d
        seq=0x00000000 replay=4 flags=0x00000000 state=mature
        created: Aug 15 11:03:34 2006   current: Aug 15 11:50:10 2006
        diff: 2796(s)   hard: 3600(s)   soft: 2880(s)
        last:                           hard: 0(s)      soft: 0(s)
        current: 0(bytes)       hard: 0(bytes)  soft: 0(bytes)
        allocated: 0    hard: 0 soft: 0
        sadb_seq=3 pid=10324 refcnt=0
10.1.13.104 10.1.13.90
        ah mode=transport spi=232904746(0x0de1d82a) reqid=0(0x00000000)
        A: hmac-sha1  d0cb6f60 9f4ce933 adcee87f 7ff92c05 f850eb35
        seq=0x00000000 replay=4 flags=0x00000000 state=mature
        created: Aug 15 11:03:34 2006   current: Aug 15 11:50:10 2006
        diff: 2796(s)   hard: 3600(s)   soft: 2880(s)
        last:                           hard: 0(s)      soft: 0(s)
        current: 0(bytes)       hard: 0(bytes)  soft: 0(bytes)
        allocated: 0    hard: 0 soft: 0
        sadb_seq=2 pid=10324 refcnt=0
10.1.13.90 10.1.13.104
        esp mode=transport spi=161190146(0x099b9102) reqid=0(0x00000000)
        E: 3des-cbc  0a57f388 64520697 db36d889 f0933005 78ec7d6d
a7d2fd42
        A: hmac-sha1  372a4cec 3035f96f fa3e3e33 85e16efb 85d88ba7
        seq=0x00000000 replay=4 flags=0x00000000 state=mature
        created: Aug 15 11:03:35 2006   current: Aug 15 11:50:10 2006
        diff: 2795(s)   hard: 3600(s)   soft: 2880(s)
        last:                           hard: 0(s)      soft: 0(s)
        current: 0(bytes)       hard: 0(bytes)  soft: 0(bytes)
        allocated: 0    hard: 0 soft: 0
        sadb_seq=1 pid=10324 refcnt=0
10.1.13.90 10.1.13.104
        ah mode=transport spi=135759512(0x08178698) reqid=0(0x00000000)
        A: hmac-sha1  fcccf815 4ba32275 78731b59 20659361 6f7ddf81
        seq=0x00000000 replay=4 flags=0x00000000 state=mature
        created: Aug 15 11:03:34 2006   current: Aug 15 11:50:10 2006
        diff: 2796(s)   hard: 3600(s)   soft: 2880(s)
        last:                           hard: 0(s)      soft: 0(s)
        current: 0(bytes)       hard: 0(bytes)  soft: 0(bytes)
        allocated: 0    hard: 0 soft: 0
        sadb_seq=0 pid=10324 refcnt=0


[root@rawhide-clone ~]# setkey -D
10.1.13.104 10.1.13.90
        esp mode=transport spi=43920387(0x029e2c03) reqid=0(0x00000000)
        E: 3des-cbc  ed1dd172 479fc39e 699c619d d626a652 9489f426
12bec67e
        A: hmac-sha1  6917f1a2 30a207f8 a1680143 5d490f66 431fd11d
        seq=0x00000000 replay=4 flags=0x00000000 state=mature
        created: Aug 15 11:03:34 2006   current: Aug 15 11:50:10 2006
        diff: 2796(s)   hard: 3600(s)   soft: 2880(s)
        last:                           hard: 0(s)      soft: 0(s)
        current: 0(bytes)       hard: 0(bytes)  soft: 0(bytes)
        allocated: 0    hard: 0 soft: 0
        sadb_seq=3 pid=10324 refcnt=0
10.1.13.104 10.1.13.90
        ah mode=transport spi=232904746(0x0de1d82a) reqid=0(0x00000000)
        A: hmac-sha1  d0cb6f60 9f4ce933 adcee87f 7ff92c05 f850eb35
        seq=0x00000000 replay=4 flags=0x00000000 state=mature
        created: Aug 15 11:03:34 2006   current: Aug 15 11:50:10 2006
        diff: 2796(s)   hard: 3600(s)   soft: 2880(s)
        last:                           hard: 0(s)      soft: 0(s)
        current: 0(bytes)       hard: 0(bytes)  soft: 0(bytes)
        allocated: 0    hard: 0 soft: 0
        sadb_seq=2 pid=10324 refcnt=0
10.1.13.90 10.1.13.104
        esp mode=transport spi=161190146(0x099b9102) reqid=0(0x00000000)
        E: 3des-cbc  0a57f388 64520697 db36d889 f0933005 78ec7d6d
a7d2fd42
        A: hmac-sha1  372a4cec 3035f96f fa3e3e33 85e16efb 85d88ba7
        seq=0x00000000 replay=4 flags=0x00000000 state=mature
        created: Aug 15 11:03:35 2006   current: Aug 15 11:50:10 2006
        diff: 2795(s)   hard: 3600(s)   soft: 2880(s)
        last:                           hard: 0(s)      soft: 0(s)
        current: 0(bytes)       hard: 0(bytes)  soft: 0(bytes)
        allocated: 0    hard: 0 soft: 0
        sadb_seq=1 pid=10324 refcnt=0
10.1.13.90 10.1.13.104
        ah mode=transport spi=135759512(0x08178698) reqid=0(0x00000000)
        A: hmac-sha1  fcccf815 4ba32275 78731b59 20659361 6f7ddf81
        seq=0x00000000 replay=4 flags=0x00000000 state=mature
        created: Aug 15 11:03:34 2006   current: Aug 15 11:50:10 2006
        diff: 2796(s)   hard: 3600(s)   soft: 2880(s)
        last:                           hard: 0(s)      soft: 0(s)
        current: 0(bytes)       hard: 0(bytes)  soft: 0(bytes)
        allocated: 0    hard: 0 soft: 0
        sadb_seq=0 pid=10324 refcnt=0


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

Re: ipsec and getpeercon()

[Stephen Smalley]

On Tue, 2006-08-29 at 15:46 -0400, Joshua Brindle wrote:
> On Tue, 2006-08-29 at 15:37 -0400, Stephen Smalley wrote:
> > On Tue, 2006-08-29 at 14:08 -0400, Joshua Brindle wrote:
> > > 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?
> > 
> > You didn't provide much information above.  Kernel version?  ipsec-tools
> > version?  racoon version?  ipsec configuration?  setkey -D output?
> > setkey -DP output?
> 
> Sorry,
> 
> Linux rawhide-clone 2.6.17-1.2586.fc6 #1 SMP Thu Aug 24 08:51:22 EDT
> 2006 i686 i686 i386 GNU/Linux
> 
> ipsec-tools.i386                         0.6.5-3.1
> 
> [root@rawhide-clone ~]# setkey -D
<snip>
> [root@rawhide-clone ~]# setkey -D

One of those was supposed to be a setkey -DP.

You did remember to specify a -ctx option when you added spd entries,
right?

-- 
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: ipsec and getpeercon()

[Stephen Smalley]

On Tue, 2006-08-29 at 16:25 -0400, Stephen Smalley wrote:
> On Tue, 2006-08-29 at 15:46 -0400, Joshua Brindle wrote:
> > On Tue, 2006-08-29 at 15:37 -0400, Stephen Smalley wrote:
> > > On Tue, 2006-08-29 at 14:08 -0400, Joshua Brindle wrote:
> > > > 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?
> > > 
> > > You didn't provide much information above.  Kernel version?  ipsec-tools
> > > version?  racoon version?  ipsec configuration?  setkey -D output?
> > > setkey -DP output?
> > 
> > Sorry,
> > 
> > Linux rawhide-clone 2.6.17-1.2586.fc6 #1 SMP Thu Aug 24 08:51:22 EDT
> > 2006 i686 i686 i386 GNU/Linux
> > 
> > ipsec-tools.i386                         0.6.5-3.1
> > 
> > [root@rawhide-clone ~]# setkey -D
> <snip>
> > [root@rawhide-clone ~]# setkey -D
> 
> One of those was supposed to be a setkey -DP.
> 
> You did remember to specify a -ctx option when you added spd entries,
> right?

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?

-- 
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: ipsec and getpeercon()

[Klaus Weidner]

On Tue, Aug 29, 2006 at 04:32:51PM -0400, Stephen Smalley wrote:
> 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?

I have the impression that the Fedora SELinux wiki isn't being updated
anymore since it's not editable without jumping through hoops that seem
excessive even to people working on a MLS/RBAC system...

-Klaus

--
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: ipsec and getpeercon()

[Joshua Brindle]

On Tue, 2006-08-29 at 16:25 -0400, Stephen Smalley wrote:
> On Tue, 2006-08-29 at 15:46 -0400, Joshua Brindle wrote:
> > On Tue, 2006-08-29 at 15:37 -0400, Stephen Smalley wrote:
> > > On Tue, 2006-08-29 at 14:08 -0400, Joshua Brindle wrote:
> > > > 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?
> > > 
> > > You didn't provide much information above.  Kernel version?  ipsec-tools
> > > version?  racoon version?  ipsec configuration?  setkey -D output?
> > > setkey -DP output?
> > 
> > Sorry,
> > 
> > Linux rawhide-clone 2.6.17-1.2586.fc6 #1 SMP Thu Aug 24 08:51:22 EDT
> > 2006 i686 i686 i386 GNU/Linux
> > 
> > ipsec-tools.i386                         0.6.5-3.1
> > 
> > [root@rawhide-clone ~]# setkey -D
> <snip>
> > [root@rawhide-clone ~]# setkey -D
> 
> One of those was supposed to be a setkey -DP.
> 

err, yea, i mispasted
[root@joker-rawhide-clone ~]# setkey -DP
10.1.13.104[any] 10.1.13.90[any] any
        in prio def ipsec
        esp/transport//require
        ah/transport//require
        created: Aug 15 08:25:20 2006  lastused: Aug 15 10:15:35 2006
        lifetime: 0(s) validtime: 0(s)
        spid=1192 seq=10 pid=10325
        refcnt=1
10.1.13.90[any] 10.1.13.104[any] any
        out prio def ipsec
        esp/transport//require
        ah/transport//require
        created: Aug 15 08:25:20 2006  lastused: Aug 15 10:15:35 2006
        lifetime: 0(s) validtime: 0(s)
        spid=1185 seq=9 pid=10325
        refcnt=1
10.1.13.104[any] 10.1.13.90[any] any
        fwd prio def ipsec
        esp/transport//require
        ah/transport//require
        created: Aug 15 08:25:20 2006  lastused:
        lifetime: 0(s) validtime: 0(s)
        spid=1202 seq=8 pid=10325
        refcnt=1
(per-socket policy)
        in none
        created: Aug 15 08:25:21 2006  lastused:
        lifetime: 0(s) validtime: 0(s)
        security context doi: 1
        security context algorithm: 1
        security context length: 41
        security context: root:system_r:unconfined_t:s0-s0:c0.c255
        spid=1259 seq=7 pid=10325
        refcnt=1
(per-socket policy)
        in none
        created: Aug 15 08:25:21 2006  lastused:
        lifetime: 0(s) validtime: 0(s)
        security context doi: 1
        security context algorithm: 1
        security context length: 41
        security context: root:system_r:unconfined_t:s0-s0:c0.c255
        spid=1243 seq=6 pid=10325
        refcnt=1
(per-socket policy)
        in none
        created: Aug 15 08:25:21 2006  lastused: Aug 15 11:03:34 2006
        lifetime: 0(s) validtime: 0(s)
        security context doi: 1
        security context algorithm: 1
        security context length: 41
        security context: root:system_r:unconfined_t:s0-s0:c0.c255
        spid=1227 seq=5 pid=10325
        refcnt=1
(per-socket policy)
        in none
        created: Aug 15 08:25:21 2006  lastused:
        lifetime: 0(s) validtime: 0(s)
        security context doi: 1
        security context algorithm: 1
        security context length: 41
        security context: root:system_r:unconfined_t:s0-s0:c0.c255
        spid=1211 seq=4 pid=10325
        refcnt=1
(per-socket policy)
        out none
        created: Aug 15 08:25:21 2006  lastused:
        lifetime: 0(s) validtime: 0(s)
        security context doi: 1
        security context algorithm: 1
        security context length: 41
        security context: root:system_r:unconfined_t:s0-s0:c0.c255
        spid=1268 seq=3 pid=10325
        refcnt=1
(per-socket policy)
        out none
        created: Aug 15 08:25:21 2006  lastused:
        lifetime: 0(s) validtime: 0(s)
        security context doi: 1
        security context algorithm: 1
        security context length: 41
        security context: root:system_r:unconfined_t:s0-s0:c0.c255
        spid=1252 seq=2 pid=10325
        refcnt=1
(per-socket policy)
        out none
        created: Aug 15 08:25:21 2006  lastused: Aug 15 11:03:34 2006
        lifetime: 0(s) validtime: 0(s)
        security context doi: 1
        security context algorithm: 1
        security context length: 41
        security context: root:system_r:unconfined_t:s0-s0:c0.c255
        spid=1236 seq=1 pid=10325
        refcnt=1
(per-socket policy)
        out none
        created: Aug 15 08:25:21 2006  lastused:
        lifetime: 0(s) validtime: 0(s)
        security context doi: 1
        security context algorithm: 1
        security context length: 41
        security context: root:system_r:unconfined_t:s0-s0:c0.c255
        spid=1220 seq=0 pid=10325
        refcnt=1


> You did remember to specify a -ctx option when you added spd entries,
> right?
> 

I didn't add anything, I used system-config-network :) I'm pretty new to
ipsec actually so that was the only thing I could find on doing this in
Fedora. I found nothing on the selinux parts


--
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: ipsec and getpeercon()

[Stephen Smalley]

On Tue, 2006-08-29 at 16:11 -0500, Klaus Weidner wrote:
> On Tue, Aug 29, 2006 at 04:32:51PM -0400, Stephen Smalley wrote:
> > 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?
> 
> I have the impression that the Fedora SELinux wiki isn't being updated
> anymore since it's not editable without jumping through hoops that seem
> excessive even to people working on a MLS/RBAC system...

I see.  Well, if someone would like to add documentation to the
sourceforge selinux project, I can add access for people known to me.
Not a wiki, but hopefully not too cumbersome to use as a place to upload
documents.

-- 
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: ipsec and getpeercon()

[Venkat Yekkirala]

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

RE: ipsec and getpeercon()

[Joshua Brindle]

On Wed, 2006-08-30 at 12:43 -0400, Venkat Yekkirala wrote:
> > 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.
> 

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.

So basically to use ipsec in any useful way you have to have separate
ipsec connections between 2 machines for every domain you plan to
communicate across (with the expectation of knowing what domain is on
the other side)..

This seems very fragile to me and difficult to keep working (especially
since the ipsec policy isn't tied to the selinux policy in any way)


--
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: ipsec and getpeercon()

[Venkat Yekkirala]

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

RE: ipsec and getpeercon()

[Stephen Smalley]

On Fri, 2006-09-01 at 09:16 -0400, Venkat Yekkirala wrote:
> > 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.

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

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?

-- 
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: ipsec and getpeercon()

[Venkat Yekkirala]

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

RE: ipsec and getpeercon()

[Joshua Brindle]

On Fri, 2006-09-01 at 10:35 -0400, Venkat Yekkirala wrote:
> > 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 :).

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

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.

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

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

is any of this possible?


--
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: ipsec and getpeercon()

[Paul Moore]

Joshua Brindle wrote:
> Hrm, am I right in understanding that the selinux context from one
> machine is never sent over ipsec to the destination? 
> 
> 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.
> 
> 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).
> 
> Note that we may be sending contexts that aren't even valid on the local
> machine, but would be valid on the destination machine. 
> 
> is any of this possible?

WARNING: *shameless* plug ahead, read at your own risk :)

NetLabel takes it's security context directly from the socket which is
writing the data to the network, not from a separate source.  This
allows for the dynamic context packet labeling I think you are looking
for ... yes?

However, in the interest of full disclosure I should point out that
currently NetLabel only supports the MLS label portion of the context
but I plan on extending that in the future.  Also, NetLabel only offers
packet labeling, not packet autentication or encryption like IPsec.
However, NetLabel could be used in conjunction with regular IPsec
without problems.  This would allow you a dynamically labeled, secure
connection between two parties with as few SAs as you desire.

-- 
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: ipsec and getpeercon()

[Venkat Yekkirala]

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

RE: ipsec and getpeercon()

[Stephen Smalley]

On Fri, 2006-09-01 at 11:49 -0400, Venkat Yekkirala wrote:
> > 
> > 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.

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.

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


-- 
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: ipsec and getpeercon()

[Joshua Brindle]

On Fri, 2006-09-01 at 11:49 -0400, Venkat Yekkirala wrote:
<snip>
> 
> 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.
> 

so you want to implicitly label the SA's? 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.

> 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? How can
you do things like RPC where the port will be dynamic with multiple SA's
in use?

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

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) 

> > 
> > is any of this possible?
> > 
> 
> Sounds like we are making some progress here. Thanks for the discussion.

Thank you, I'm getting an understanding of how all this works now..


--
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: ipsec and getpeercon()

[Joy Latten]

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

RE: ipsec and getpeercon()

[Venkat Yekkirala]

[-- 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 --]

RE: ipsec and getpeercon()

[Venkat Yekkirala]

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

RE: ipsec and getpeercon()

[Joy Latten]

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.

RE: ipsec and getpeercon()

[Joy Latten]

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

Re: ipsec and getpeercon()

[Paul Moore]

Joy Latten wrote:
> 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... 
> 

A simple 'dmesg | grep NetLabel' will answer that question.

I'll work on this and post something next week.  Unfortunately, the fix
is not immediately obvious.

-- 
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: ipsec and getpeercon()

[Venkat Yekkirala]

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

RE: ipsec and getpeercon()

[Venkat Yekkirala]

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

Re: ipsec and getpeercon()

[Paul Moore]

Venkat Yekkirala wrote:
>>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.

That is not the issue I am dealing with right now.

I now have a solution in mind, however, it is doubtful I will have a
chance to do any sort of testing on it before I leave tonight.  Once I
can give it a quick test to verify that it doesn't break anything I'll
post a patch for you and Joy to verify.

-- 
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: ipsec and getpeercon()

[Paul Moore]

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

Paul Moore wrote:
> Venkat Yekkirala wrote:
> 
>>>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.
> 
> 
> That is not the issue I am dealing with right now.
> 
> I now have a solution in mind, however, it is doubtful I will have a
> chance to do any sort of testing on it before I leave tonight.  Once I
> can give it a quick test to verify that it doesn't break anything I'll
> post a patch for you and Joy to verify.
> 

Sorry for attaching the patch as an attachment but I'm in a rush to get
out of here ...

This patch is against David Miller's net-2.6.19 tree from a day or two
ago, depending on your kernel you may have some fuzz when applying this
patch.  I've only done some quick functional tests, but it seems to
solve this problem.

Joy, Venkat if you are able to test this and let me know the results I
would appreciate it.

Thanks.

-- 
paul moore
linux security @ hp

[-- Attachment #2: netlabel-bug_peersec --]
[-- Type: text/plain, Size: 7574 bytes --]

Subject: NetLabel: correct improper handling on non-NetLabel peer contexts
From: Paul Moore <paul.moore@hp.com>

Fix a problem where NetLabel would always set the value of 
sk_security_struct->peer_sid in selinux_netlbl_sock_graft() to the context of
the socket, causing problems when users would query the context of the
connection.  This patch fixes this so that the value in
sk_security_struct->peer_sid is only set when the connection is NetLabel based,
otherwise the value is untouched.

Signed-off-by: Paul Moore <paul.moore@hp.com>
---
 include/net/cipso_ipv4.h       |    7 +++++
 include/net/netlabel.h         |    8 ++++++
 net/ipv4/cipso_ipv4.c          |   48 ++++++++++++++++++++++++++++-------------
 net/netlabel/netlabel_kapi.c   |   23 +++++++++++++++++++
 security/selinux/ss/services.c |   12 +++++++++-
 5 files changed, 82 insertions(+), 16 deletions(-)

Index: net-2.6.19/include/net/cipso_ipv4.h
===================================================================
--- net-2.6.19.orig/include/net/cipso_ipv4.h
+++ net-2.6.19/include/net/cipso_ipv4.h
@@ -205,6 +205,7 @@ void cipso_v4_error(struct sk_buff *skb,
 int cipso_v4_socket_setattr(const struct socket *sock,
 			    const struct cipso_v4_doi *doi_def,
 			    const struct netlbl_lsm_secattr *secattr);
+int cipso_v4_sock_getattr(struct sock *sk, struct netlbl_lsm_secattr *secattr);
 int cipso_v4_socket_getattr(const struct socket *sock,
 			    struct netlbl_lsm_secattr *secattr);
 int cipso_v4_skbuff_getattr(const struct sk_buff *skb,
@@ -225,6 +226,12 @@ static inline int cipso_v4_socket_setatt
 	return -ENOSYS;
 }
 
+static inline int cipso_v4_sock_getattr(struct sock *sk,
+					struct netlbl_lsm_secattr *secattr)
+{
+	return -ENOSYS;
+}
+
 static inline int cipso_v4_socket_getattr(const struct socket *sock,
 					  struct netlbl_lsm_secattr *secattr)
 {
Index: net-2.6.19/include/net/netlabel.h
===================================================================
--- net-2.6.19.orig/include/net/netlabel.h
+++ net-2.6.19/include/net/netlabel.h
@@ -238,6 +238,8 @@ static inline void netlbl_secattr_free(s
 #ifdef CONFIG_NETLABEL
 int netlbl_socket_setattr(const struct socket *sock,
 			  const struct netlbl_lsm_secattr *secattr);
+int netlbl_sock_getattr(struct sock *sk,
+			struct netlbl_lsm_secattr *secattr);
 int netlbl_socket_getattr(const struct socket *sock,
 			  struct netlbl_lsm_secattr *secattr);
 int netlbl_skbuff_getattr(const struct sk_buff *skb,
@@ -250,6 +252,12 @@ static inline int netlbl_socket_setattr(
 	return -ENOSYS;
 }
 
+static inline int netlbl_sock_getattr(struct sock *sk,
+				      struct netlbl_lsm_secattr *secattr)
+{
+	return -ENOSYS;
+}
+
 static inline int netlbl_socket_getattr(const struct socket *sock,
 					struct netlbl_lsm_secattr *secattr)
 {
Index: net-2.6.19/net/ipv4/cipso_ipv4.c
===================================================================
--- net-2.6.19.orig/net/ipv4/cipso_ipv4.c
+++ net-2.6.19/net/ipv4/cipso_ipv4.c
@@ -1486,43 +1486,40 @@ socket_setattr_failure:
 }
 
 /**
- * cipso_v4_socket_getattr - Get the security attributes from a socket
- * @sock: the socket
+ * cipso_v4_sock_getattr - Get the security attributes from a sock
+ * @sk: the sock
  * @secattr: the security attributes
  *
  * Description:
- * Query @sock to see if there is a CIPSO option attached to the socket and if
- * there is return the CIPSO security attributes in @secattr.  Returns zero on
- * success and negative values on failure.
+ * Query @sk to see if there is a CIPSO option attached to the sock and if
+ * there is return the CIPSO security attributes in @secattr.  This function
+ * requires that @sk be locked, or privately held, but it does not do any
+ * locking itself.  Returns zero on success and negative values on failure.
  *
  */
-int cipso_v4_socket_getattr(const struct socket *sock,
-			    struct netlbl_lsm_secattr *secattr)
+int cipso_v4_sock_getattr(struct sock *sk, struct netlbl_lsm_secattr *secattr)
 {
 	int ret_val = -ENOMSG;
-	struct sock *sk;
 	struct inet_sock *sk_inet;
 	unsigned char *cipso_ptr;
 	u32 doi;
 	struct cipso_v4_doi *doi_def;
 
-	sk = sock->sk;
-	lock_sock(sk);
 	sk_inet = inet_sk(sk);
 	if (sk_inet->opt == NULL || sk_inet->opt->cipso == 0)
-		goto socket_getattr_return;
+		return -ENOMSG;
 	cipso_ptr = sk_inet->opt->__data + sk_inet->opt->cipso -
 		sizeof(struct iphdr);
 	ret_val = cipso_v4_cache_check(cipso_ptr, cipso_ptr[1], secattr);
 	if (ret_val == 0)
-		goto socket_getattr_return;
+		return ret_val;
 
 	doi = ntohl(*(u32 *)&cipso_ptr[2]);
 	rcu_read_lock();
 	doi_def = cipso_v4_doi_getdef(doi);
 	if (doi_def == NULL) {
 		rcu_read_unlock();
-		goto socket_getattr_return;
+		return -ENOMSG;
 	}
 	switch (cipso_ptr[6]) {
 	case CIPSO_V4_TAG_RBITMAP:
@@ -1533,8 +1530,29 @@ int cipso_v4_socket_getattr(const struct
 	}
 	rcu_read_unlock();
 
-socket_getattr_return:
-	release_sock(sk);
+	return ret_val;
+}
+
+/**
+ * cipso_v4_socket_getattr - Get the security attributes from a socket
+ * @sock: the socket
+ * @secattr: the security attributes
+ *
+ * Description:
+ * Query @sock to see if there is a CIPSO option attached to the socket and if
+ * there is return the CIPSO security attributes in @secattr.  Returns zero on
+ * success and negative values on failure.
+ *
+ */
+int cipso_v4_socket_getattr(const struct socket *sock,
+			    struct netlbl_lsm_secattr *secattr)
+{
+	int ret_val;
+
+	lock_sock(sock->sk);
+	ret_val = cipso_v4_sock_getattr(sock->sk, secattr);
+	release_sock(sock->sk);
+
 	return ret_val;
 }
 
Index: net-2.6.19/net/netlabel/netlabel_kapi.c
===================================================================
--- net-2.6.19.orig/net/netlabel/netlabel_kapi.c
+++ net-2.6.19/net/netlabel/netlabel_kapi.c
@@ -85,6 +85,29 @@ socket_setattr_return:
 }
 
 /**
+ * netlbl_sock_getattr - Determine the security attributes of a sock
+ * @sk: the sock
+ * @secattr: the security attributes
+ *
+ * Description:
+ * Examines the given sock to see any NetLabel style labeling has been
+ * applied to the sock, if so it parses the socket label and returns the
+ * security attributes in @secattr.  Returns zero on success, negative values
+ * on failure.
+ *
+ */
+int netlbl_sock_getattr(struct sock *sk, struct netlbl_lsm_secattr *secattr)
+{
+	int ret_val;
+
+	ret_val = cipso_v4_sock_getattr(sk, secattr);
+	if (ret_val == 0)
+		return 0;
+
+	return netlbl_unlabel_getattr(secattr);
+}
+
+/**
  * netlbl_socket_getattr - Determine the security attributes of a socket
  * @sock: the socket
  * @secattr: the security attributes
Index: net-2.6.19/security/selinux/ss/services.c
===================================================================
--- net-2.6.19.orig/security/selinux/ss/services.c
+++ net-2.6.19/security/selinux/ss/services.c
@@ -2502,14 +2502,24 @@ void selinux_netlbl_sock_graft(struct so
 {
 	struct inode_security_struct *isec = SOCK_INODE(sock)->i_security;
 	struct sk_security_struct *sksec = sk->sk_security;
+	struct netlbl_lsm_secattr secattr;
+	u32 nlbl_peer_sid;
 
 	sksec->sclass = isec->sclass;
 
 	if (sk->sk_family != PF_INET)
 		return;
 
+	netlbl_secattr_init(&secattr);
+	if (netlbl_sock_getattr(sk, &secattr) == 0 &&
+	    selinux_netlbl_secattr_to_sid(NULL,
+					  &secattr,
+					  sksec->sid,
+					  &nlbl_peer_sid) == 0)
+		sksec->peer_sid = nlbl_peer_sid;
+	netlbl_secattr_destroy(&secattr, 0);
+
 	sksec->nlbl_state = NLBL_REQUIRE;
-	sksec->peer_sid = sksec->sid;
 
 	/* 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

RE: ipsec and getpeercon()

[Joy Latten]

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

RE: ipsec and getpeercon()

[Joshua Brindle]

On Fri, 2006-09-01 at 16:35 -0400, Venkat Yekkirala wrote:
> <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).
> 

Right, this still means many SA's per machine, possibly one per domain,
is this a problem? Would we expect production systems to be able to
handle large loads this way?

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

Not sure I understand, are you saying its possible to automatically
create an SA when you run a new application that needs one? How does
this work? 

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

How long term? 


--
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: ipsec and getpeercon()

[Joshua Brindle]

On Fri, 2006-09-01 at 16:19 -0400, Paul Moore wrote:
> Joy Latten wrote:
> > 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... 
> > 
> 
> A simple 'dmesg | grep NetLabel' will answer that question.
> 
> I'll work on this and post something next week.  Unfortunately, the fix
> is not immediately obvious.
> 

Right, so I do have NetLabel running (didn't know that it shipped on in
Fedora kernels already)..

There were no maps set up, it looks like all I had was the unlabeled
module. 

This getpeercon() overloading seems to be a problem, how can an
application react reasonably if the label it gets when it calls
getpeercon() could come from multiple objects and have multiple
meanings? 

To me getpeercon() means the context of the domain on the other side,
granted the implementation has been the socket context which, until now,
was always the domain on the other side. With the ability to label
sockets and with ipsec socket labeling and NetLabel (domain?) labeling
perhaps getpeercon() should be refactored into 2 functions, getpeercon()
and getsocketcon()?


--
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: ipsec and getpeercon()

[Joshua Brindle]

On Fri, 2006-09-01 at 11:40 -0400, Paul Moore wrote:
> Joshua Brindle wrote:
> > Hrm, am I right in understanding that the selinux context from one
> > machine is never sent over ipsec to the destination? 
> > 
> > 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.
> > 
> > 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).
> > 
> > Note that we may be sending contexts that aren't even valid on the local
> > machine, but would be valid on the destination machine. 
> > 
> > is any of this possible?
> 
> WARNING: *shameless* plug ahead, read at your own risk :)
> 
> NetLabel takes it's security context directly from the socket which is
> writing the data to the network, not from a separate source.  This
> allows for the dynamic context packet labeling I think you are looking
> for ... yes?
> 
> However, in the interest of full disclosure I should point out that
> currently NetLabel only supports the MLS label portion of the context
> but I plan on extending that in the future.  Also, NetLabel only offers
> packet labeling, not packet autentication or encryption like IPsec.
> However, NetLabel could be used in conjunction with regular IPsec
> without problems.  This would allow you a dynamically labeled, secure
> connection between two parties with as few SAs as you desire.
> 

Yes, I have considered NetLabel, contingent on it getting merged into
mainline and supporting full contexts. I've been looking in to the specs
and it looks like you are going to have to make an entirely new tag for
full contexts. This will eliminate its ability to communicate with tsol,
et al right? (unless you change the netlabel policy obviously, I mean by
default). 

It also looks like the tags currently use bitmaps (which is fair since
levels are better represented that way) but for full contexts we'd want
just a u32 right? (u32 is used in the sidtab so a machine can't have
more contexts than that active).

I'm just thinking out loud here.. are there plans at HP to support full
contexts or is this more of a 'someone might do this in the future and
it should work' thing?


--
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: ipsec and getpeercon()

[Joshua Brindle]

On Fri, 2006-09-01 at 18:32 -0400, Paul Moore wrote:
> Paul Moore wrote:
> > Venkat Yekkirala wrote:
> > 
> >>>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.
> > 
> > 
> > That is not the issue I am dealing with right now.
> > 
> > I now have a solution in mind, however, it is doubtful I will have a
> > chance to do any sort of testing on it before I leave tonight.  Once I
> > can give it a quick test to verify that it doesn't break anything I'll
> > post a patch for you and Joy to verify.
> > 
> 
> Sorry for attaching the patch as an attachment but I'm in a rush to get
> out of here ...
> 
> This patch is against David Miller's net-2.6.19 tree from a day or two
> ago, depending on your kernel you may have some fuzz when applying this
> patch.  I've only done some quick functional tests, but it seems to
> solve this problem.
> 
> Joy, Venkat if you are able to test this and let me know the results I
> would appreciate it.
> 
> Thanks.

I tried the (rebased patch below, there were some rejects when applying
it to todays net-2.6.19) and got the same behavior as before:

[root@joker-rawhide-clone ~]# ./server
server: got connection from 10.1.13.104, root:system_r:unconfined_t:s0

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

my spd is the same as before:
[root@joker-rawhide-clone ~]# setkey -DP
10.1.13.104[any] 10.1.13.100[any] any
        in prio def ipsec
        esp/transport//require
        created: Sep  4 14:40:33 2006  lastused: Sep  4 14:41:38 2006
        lifetime: 0(s) validtime: 0(s)
        security context doi: 1
        security context algorithm: 1
        security context length: 33
        security context: system_u:object_r:unlabeled_t:s0
        spid=32 seq=2 pid=2384
        refcnt=1
10.1.13.100[any] 10.1.13.104[any] any
        out prio def ipsec
        esp/transport//require
        created: Sep  4 14:40:33 2006  lastused: Sep  4 14:41:38 2006
        lifetime: 0(s) validtime: 0(s)
        security context doi: 1
        security context algorithm: 1
        security context length: 33
        security context: system_u:object_r:unlabeled_t:s0
        spid=25 seq=1 pid=2384
        refcnt=1
10.1.13.104[any] 10.1.13.100[any] any
        fwd prio def ipsec
        esp/transport//require
        created: Sep  4 14:40:33 2006  lastused:
        lifetime: 0(s) validtime: 0(s)
        security context doi: 1
        security context algorithm: 1
        security context length: 33
        security context: system_u:object_r:unlabeled_t:s0
        spid=42 seq=0 pid=2384
        refcnt=1



diff --git a/include/net/cipso_ipv4.h b/include/net/cipso_ipv4.h
index c7175e7..b2bd7a6 100644
--- a/include/net/cipso_ipv4.h
+++ b/include/net/cipso_ipv4.h
@@ -211,6 +211,7 @@ int cipso_v4_socket_getopt(const struct 
 			   u32 *opt_len);
 int cipso_v4_socket_getattr(const struct socket *sock,
 			    struct netlbl_lsm_secattr *secattr);
+int cipso_v4_sock_getattr(struct sock *sk, struct netlbl_lsm_secattr *secattr);
 int cipso_v4_skbuff_getattr(const struct sk_buff *skb,
 			    struct netlbl_lsm_secattr *secattr);
 int cipso_v4_validate(unsigned char **option);
@@ -229,6 +230,12 @@ static inline int cipso_v4_socket_setatt
 	return -ENOSYS;
 }
 
+static inline int cipso_v4_sock_getattr(struct sock *sk,
+					struct netlbl_lsm_secattr *secattr)
+{
+	return -ENOSYS;
+}
+
 static inline int cipso_v4_socket_getattr(const struct socket *sock,
 					  struct netlbl_lsm_secattr *secattr)
 {
diff --git a/include/net/netlabel.h b/include/net/netlabel.h
index 7cae730..6addb41 100644
--- a/include/net/netlabel.h
+++ b/include/net/netlabel.h
@@ -237,6 +237,8 @@ static inline void netlbl_secattr_free(s
 #ifdef CONFIG_NETLABEL
 int netlbl_socket_setattr(const struct socket *sock,
 			  const struct netlbl_lsm_secattr *secattr);
+int netlbl_sock_getattr(struct sock *sk,
+			struct netlbl_lsm_secattr *secattr);
 int netlbl_socket_getattr(const struct socket *sock,
 			  struct netlbl_lsm_secattr *secattr);
 int netlbl_skbuff_getattr(const struct sk_buff *skb,
@@ -249,6 +251,12 @@ static inline int netlbl_socket_setattr(
 	return -ENOSYS;
 }
 
+static inline int netlbl_sock_getattr(struct sock *sk,
+				      struct netlbl_lsm_secattr *secattr)
+{
+	return -ENOSYS;
+}
+
 static inline int netlbl_socket_getattr(const struct socket *sock,
 					struct netlbl_lsm_secattr *secattr)
 {
diff --git a/net/ipv4/cipso_ipv4.c b/net/ipv4/cipso_ipv4.c
index 80a2a09..a3bae2c 100644
--- a/net/ipv4/cipso_ipv4.c
+++ b/net/ipv4/cipso_ipv4.c
@@ -1486,43 +1486,40 @@ socket_setattr_failure:
 }
 
 /**
- * cipso_v4_socket_getattr - Get the security attributes from a socket
- * @sock: the socket
+ * cipso_v4_sock_getattr - Get the security attributes from a sock
+ * @sk: the sock
  * @secattr: the security attributes
  *
  * Description:
- * Query @sock to see if there is a CIPSO option attached to the socket and if
- * there is return the CIPSO security attributes in @secattr.  Returns zero on
- * success and negative values on failure.
+ * Query @sk to see if there is a CIPSO option attached to the sock and if
+ * there is return the CIPSO security attributes in @secattr.  This function
+ * requires that @sk be locked, or privately held, but it does not do any
+ * locking itself.  Returns zero on success and negative values on failure.
  *
  */
-int cipso_v4_socket_getattr(const struct socket *sock,
-			    struct netlbl_lsm_secattr *secattr)
+int cipso_v4_sock_getattr(struct sock *sk, struct netlbl_lsm_secattr *secattr)
 {
 	int ret_val = -ENOMSG;
-	struct sock *sk;
 	struct inet_sock *sk_inet;
 	unsigned char *cipso_ptr;
 	u32 doi;
 	struct cipso_v4_doi *doi_def;
 
-	sk = sock->sk;
-	lock_sock(sk);
 	sk_inet = inet_sk(sk);
 	if (sk_inet->opt == NULL || sk_inet->opt->cipso == 0)
-		goto socket_getattr_return;
+		return -ENOMSG;
 	cipso_ptr = sk_inet->opt->__data + sk_inet->opt->cipso -
 		sizeof(struct iphdr);
 	ret_val = cipso_v4_cache_check(cipso_ptr, cipso_ptr[1], secattr);
 	if (ret_val == 0)
-		goto socket_getattr_return;
+		return ret_val;
 
 	doi = ntohl(*(u32 *)&cipso_ptr[2]);
 	rcu_read_lock();
 	doi_def = cipso_v4_doi_getdef(doi);
 	if (doi_def == NULL) {
 		rcu_read_unlock();
-		goto socket_getattr_return;
+		return -ENOMSG;
 	}
 	switch (cipso_ptr[6]) {
 	case CIPSO_V4_TAG_RBITMAP:
@@ -1533,8 +1530,29 @@ int cipso_v4_socket_getattr(const struct
 	}
 	rcu_read_unlock();
 
-socket_getattr_return:
-	release_sock(sk);
+	return ret_val;
+}
+
+/**
+ * cipso_v4_socket_getattr - Get the security attributes from a socket
+ * @sock: the socket
+ * @secattr: the security attributes
+ *
+ * Description:
+ * Query @sock to see if there is a CIPSO option attached to the socket and if
+ * there is return the CIPSO security attributes in @secattr.  Returns zero on
+ * success and negative values on failure.
+ *
+ */
+int cipso_v4_socket_getattr(const struct socket *sock,
+			    struct netlbl_lsm_secattr *secattr)
+{
+	int ret_val;
+
+	lock_sock(sock->sk);
+	ret_val = cipso_v4_sock_getattr(sock->sk, secattr);
+	release_sock(sock->sk);
+
 	return ret_val;
 }
 
diff --git a/net/netlabel/netlabel_kapi.c b/net/netlabel/netlabel_kapi.c
index 0fd8aaa..54fb7de 100644
--- a/net/netlabel/netlabel_kapi.c
+++ b/net/netlabel/netlabel_kapi.c
@@ -85,6 +85,29 @@ socket_setattr_return:
 }
 
 /**
+ * netlbl_sock_getattr - Determine the security attributes of a sock
+ * @sk: the sock
+ * @secattr: the security attributes
+ *
+ * Description:
+ * Examines the given sock to see any NetLabel style labeling has been
+ * applied to the sock, if so it parses the socket label and returns the
+ * security attributes in @secattr.  Returns zero on success, negative values
+ * on failure.
+ *
+ */
+int netlbl_sock_getattr(struct sock *sk, struct netlbl_lsm_secattr *secattr)
+{
+	int ret_val;
+
+	ret_val = cipso_v4_sock_getattr(sk, secattr);
+	if (ret_val == 0)
+		return 0;
+
+	return netlbl_unlabel_getattr(secattr);
+}
+
+/**
  * netlbl_socket_getattr - Determine the security attributes of a socket
  * @sock: the socket
  * @secattr: the security attributes
diff --git a/security/selinux/ss/services.c b/security/selinux/ss/services.c
index 910afa1..5497ad9 100644
--- a/security/selinux/ss/services.c
+++ b/security/selinux/ss/services.c
@@ -2462,12 +2462,23 @@ void selinux_netlbl_sock_graft(struct so
 {
 	struct inode_security_struct *isec = SOCK_INODE(sock)->i_security;
 	struct sk_security_struct *sksec = sk->sk_security;
+	struct netlbl_lsm_secattr secattr;
+	u32 nlbl_peer_sid;
+
 
 	if (sk->sk_family != PF_INET)
 		return;
 
+	netlbl_secattr_init(&secattr);
+	if (netlbl_sock_getattr(sk, &secattr) == 0 &&
+			selinux_netlbl_secattr_to_sid(NULL,
+				&secattr,
+				sksec->sid,
+				&nlbl_peer_sid) == 0)
+		sksec->peer_sid = nlbl_peer_sid;
+	netlbl_secattr_destroy(&secattr, 0);
+
 	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




--
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: ipsec and getpeercon()

[Paul Moore]

On Monday 04 September 2006 8:43 am, Joshua Brindle wrote:
> On Fri, 2006-09-01 at 16:19 -0400, Paul Moore wrote:
> > Joy Latten wrote:
> > > 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...
> >
> > A simple 'dmesg | grep NetLabel' will answer that question.
> >
> > I'll work on this and post something next week.  Unfortunately, the fix
> > is not immediately obvious.
>
> Right, so I do have NetLabel running (didn't know that it shipped on in
> Fedora kernels already)..
>
> There were no maps set up, it looks like all I had was the unlabeled
> module.

That is what caused the problem then.  You don't need to have anything 
actively configured, just having NetLabel built into the kernel and activated 
will cause the bug.  If you feel like spinning your own kernel you can try 
the patch I posted last Friday, it should fix the bug.

> This getpeercon() overloading seems to be a problem, how can an
> application react reasonably if the label it gets when it calls
> getpeercon() could come from multiple objects and have multiple
> meanings?

It may be a problem right now but I think it is more of an issue of 
reconciling the different network labeling systems.  The good news is that 
work is ongoing to deal with this.

> To me getpeercon() means the context of the domain on the other side,
> granted the implementation has been the socket context which, until now,
> was always the domain on the other side. With the ability to label
> sockets and with ipsec socket labeling and NetLabel (domain?) labeling
> perhaps getpeercon() should be refactored into 2 functions, getpeercon()
> and getsocketcon()?

I'm not sure that solves anything, all it does it make it the applications 
problem as now the app developer has to have knowledge of the underlying 
network labeling.  I think the best solution is to let the network labeling 
reconciliation work take place, let the bugs get shaken out, and go from 
there.

-- 
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: ipsec and getpeercon()

[Paul Moore]

On Monday 04 September 2006 8:59 am, Joshua Brindle wrote:
> On Fri, 2006-09-01 at 11:40 -0400, Paul Moore wrote:
> > Joshua Brindle wrote:
> > > Hrm, am I right in understanding that the selinux context from one
> > > machine is never sent over ipsec to the destination?
> > >
> > > 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.
> > >
> > > 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).
> > >
> > > Note that we may be sending contexts that aren't even valid on the
> > > local machine, but would be valid on the destination machine.
> > >
> > > is any of this possible?
> >
> > WARNING: *shameless* plug ahead, read at your own risk :)
> >
> > NetLabel takes it's security context directly from the socket which is
> > writing the data to the network, not from a separate source.  This
> > allows for the dynamic context packet labeling I think you are looking
> > for ... yes?
> >
> > However, in the interest of full disclosure I should point out that
> > currently NetLabel only supports the MLS label portion of the context
> > but I plan on extending that in the future.  Also, NetLabel only offers
> > packet labeling, not packet autentication or encryption like IPsec.
> > However, NetLabel could be used in conjunction with regular IPsec
> > without problems.  This would allow you a dynamically labeled, secure
> > connection between two parties with as few SAs as you desire.
>
> Yes, I have considered NetLabel, contingent on it getting merged into
> mainline and supporting full contexts. I've been looking in to the specs
> and it looks like you are going to have to make an entirely new tag for
> full contexts. This will eliminate its ability to communicate with tsol,
> et al right? (unless you change the netlabel policy obviously, I mean by
> default).

The good news it that the NetLabel patches have been picked up by David Miller 
in his net-2.6.19 git tree.  Baring any major problems I think this means 
it's stands a good chance for 2.6.19.

You are correct that the CIPSO spec only defines tags which are useful for 
sending MLS labels but as James Morris' selopt implementation demonstrated it 
is possibile to extend CIPSO using the FIPS 188 freefrom (#7) tag.  There may 
also be other options to labeling packets with a full SELinux context but I 
haven't had much time to look into them yet.  Regardless, it's important to 
note the adding this functionality would not in any way eliminate the ability 
to communicate with other MLS implementations through CIPSO (or other 
explicit labeling protocols supported by NetLabel).  NetLabel supports the 
ability to specify labeling protocols per-domain; meaning each LSM/SELinux 
domain could be configured to either send traditional MLS CIPSO labels, new 
full SELinux context labels, or plain 'ole unlabeled traffic.

Look at the "map" commands for netlabelctl for more details on how to do this.

> It also looks like the tags currently use bitmaps (which is fair since
> levels are better represented that way) but for full contexts we'd want
> just a u32 right? (u32 is used in the sidtab so a machine can't have
> more contexts than that active).

Using the existing MLS tags defined in the CIPSO draft the (I'm going from 
memory here, I don't have a copy of the draft in front of me) MLS sensitivity 
level is an 8 bit value while the categories can be defined in a variety of 
ways including a 240 bit bitmap (all Linux supports right now) and a 16 bit 
value.

In order to get around these limitations the Linux CIPSO implementation 
supports multiple CIPSO Domains Of Interpretations (DOI) which can be 
configured on a per-domain basis, each DOI having the ability to "translate" 
MLS values between local and remote hosts.  Please see the NetLabel kernel 
documentation and the netlabel_tools documentation for more details.

 * kernel-*/Documentation/netlabel
 * http://netlabel.sf.net

> I'm just thinking out loud here.. are there plans at HP to support full
> contexts or is this more of a 'someone might do this in the future and
> it should work' thing?

There are several things I would like to add to NetLabel, full SELinux 
contexts are very close to the top of the list.  However, right now my focus 
is getting the NetLabel patch into a mainline kernel with enough support so 
that we can interoperate with other MLS operating systems.  Without 
CIPSO/NetLabel we don't have any sort of interoperable labeled networking so 
this seemed to be the most significant task.

-- 
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: ipsec and getpeercon()

[Paul Moore]

On Monday 04 September 2006 2:51 pm, Joshua Brindle wrote:
> On Fri, 2006-09-01 at 18:32 -0400, Paul Moore wrote:
> > Paul Moore wrote:
> > > Venkat Yekkirala wrote:
> > >>>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.
> > >
> > > That is not the issue I am dealing with right now.
> > >
> > > I now have a solution in mind, however, it is doubtful I will have a
> > > chance to do any sort of testing on it before I leave tonight.  Once I
> > > can give it a quick test to verify that it doesn't break anything I'll
> > > post a patch for you and Joy to verify.
> >
> > Sorry for attaching the patch as an attachment but I'm in a rush to get
> > out of here ...
> >
> > This patch is against David Miller's net-2.6.19 tree from a day or two
> > ago, depending on your kernel you may have some fuzz when applying this
> > patch.  I've only done some quick functional tests, but it seems to
> > solve this problem.
> >
> > Joy, Venkat if you are able to test this and let me know the results I
> > would appreciate it.
> >
> > Thanks.
>
> I tried the (rebased patch below, there were some rejects when applying
> it to todays net-2.6.19) and got the same behavior as before:
>
> [root@joker-rawhide-clone ~]# ./server
> server: got connection from 10.1.13.104, root:system_r:unconfined_t:s0
>
> [root@joker-rawhide-clone ~]# runcon -t passwd_t ./server
> server: got connection from 10.1.13.104, root:system_r:passwd_t:s0

Thanks for giving the patch a try.  I'm confused as to why it didn't work for 
you, can you try it without IPsec configured to see what results you get 
(that is what I did and it worked fine)?

Thanks.

> my spd is the same as before:
> [root@joker-rawhide-clone ~]# setkey -DP
> 10.1.13.104[any] 10.1.13.100[any] any
>         in prio def ipsec
>         esp/transport//require
>         created: Sep  4 14:40:33 2006  lastused: Sep  4 14:41:38 2006
>         lifetime: 0(s) validtime: 0(s)
>         security context doi: 1
>         security context algorithm: 1
>         security context length: 33
>         security context: system_u:object_r:unlabeled_t:s0
>         spid=32 seq=2 pid=2384
>         refcnt=1
> 10.1.13.100[any] 10.1.13.104[any] any
>         out prio def ipsec
>         esp/transport//require
>         created: Sep  4 14:40:33 2006  lastused: Sep  4 14:41:38 2006
>         lifetime: 0(s) validtime: 0(s)
>         security context doi: 1
>         security context algorithm: 1
>         security context length: 33
>         security context: system_u:object_r:unlabeled_t:s0
>         spid=25 seq=1 pid=2384
>         refcnt=1
> 10.1.13.104[any] 10.1.13.100[any] any
>         fwd prio def ipsec
>         esp/transport//require
>         created: Sep  4 14:40:33 2006  lastused:
>         lifetime: 0(s) validtime: 0(s)
>         security context doi: 1
>         security context algorithm: 1
>         security context length: 33
>         security context: system_u:object_r:unlabeled_t:s0
>         spid=42 seq=0 pid=2384
>         refcnt=1
>
>
>
> diff --git a/include/net/cipso_ipv4.h b/include/net/cipso_ipv4.h
> index c7175e7..b2bd7a6 100644
> --- a/include/net/cipso_ipv4.h
> +++ b/include/net/cipso_ipv4.h
> @@ -211,6 +211,7 @@ int cipso_v4_socket_getopt(const struct
>  			   u32 *opt_len);
>  int cipso_v4_socket_getattr(const struct socket *sock,
>  			    struct netlbl_lsm_secattr *secattr);
> +int cipso_v4_sock_getattr(struct sock *sk, struct netlbl_lsm_secattr
> *secattr); int cipso_v4_skbuff_getattr(const struct sk_buff *skb,
>  			    struct netlbl_lsm_secattr *secattr);
>  int cipso_v4_validate(unsigned char **option);
> @@ -229,6 +230,12 @@ static inline int cipso_v4_socket_setatt
>  	return -ENOSYS;
>  }
>
> +static inline int cipso_v4_sock_getattr(struct sock *sk,
> +					struct netlbl_lsm_secattr *secattr)
> +{
> +	return -ENOSYS;
> +}
> +
>  static inline int cipso_v4_socket_getattr(const struct socket *sock,
>  					  struct netlbl_lsm_secattr *secattr)
>  {
> diff --git a/include/net/netlabel.h b/include/net/netlabel.h
> index 7cae730..6addb41 100644
> --- a/include/net/netlabel.h
> +++ b/include/net/netlabel.h
> @@ -237,6 +237,8 @@ static inline void netlbl_secattr_free(s
>  #ifdef CONFIG_NETLABEL
>  int netlbl_socket_setattr(const struct socket *sock,
>  			  const struct netlbl_lsm_secattr *secattr);
> +int netlbl_sock_getattr(struct sock *sk,
> +			struct netlbl_lsm_secattr *secattr);
>  int netlbl_socket_getattr(const struct socket *sock,
>  			  struct netlbl_lsm_secattr *secattr);
>  int netlbl_skbuff_getattr(const struct sk_buff *skb,
> @@ -249,6 +251,12 @@ static inline int netlbl_socket_setattr(
>  	return -ENOSYS;
>  }
>
> +static inline int netlbl_sock_getattr(struct sock *sk,
> +				      struct netlbl_lsm_secattr *secattr)
> +{
> +	return -ENOSYS;
> +}
> +
>  static inline int netlbl_socket_getattr(const struct socket *sock,
>  					struct netlbl_lsm_secattr *secattr)
>  {
> diff --git a/net/ipv4/cipso_ipv4.c b/net/ipv4/cipso_ipv4.c
> index 80a2a09..a3bae2c 100644
> --- a/net/ipv4/cipso_ipv4.c
> +++ b/net/ipv4/cipso_ipv4.c
> @@ -1486,43 +1486,40 @@ socket_setattr_failure:
>  }
>
>  /**
> - * cipso_v4_socket_getattr - Get the security attributes from a socket
> - * @sock: the socket
> + * cipso_v4_sock_getattr - Get the security attributes from a sock
> + * @sk: the sock
>   * @secattr: the security attributes
>   *
>   * Description:
> - * Query @sock to see if there is a CIPSO option attached to the socket
> and if - * there is return the CIPSO security attributes in @secattr. 
> Returns zero on - * success and negative values on failure.
> + * Query @sk to see if there is a CIPSO option attached to the sock and if
> + * there is return the CIPSO security attributes in @secattr.  This
> function + * requires that @sk be locked, or privately held, but it does
> not do any + * locking itself.  Returns zero on success and negative values
> on failure. *
>   */
> -int cipso_v4_socket_getattr(const struct socket *sock,
> -			    struct netlbl_lsm_secattr *secattr)
> +int cipso_v4_sock_getattr(struct sock *sk, struct netlbl_lsm_secattr
> *secattr) {
>  	int ret_val = -ENOMSG;
> -	struct sock *sk;
>  	struct inet_sock *sk_inet;
>  	unsigned char *cipso_ptr;
>  	u32 doi;
>  	struct cipso_v4_doi *doi_def;
>
> -	sk = sock->sk;
> -	lock_sock(sk);
>  	sk_inet = inet_sk(sk);
>  	if (sk_inet->opt == NULL || sk_inet->opt->cipso == 0)
> -		goto socket_getattr_return;
> +		return -ENOMSG;
>  	cipso_ptr = sk_inet->opt->__data + sk_inet->opt->cipso -
>  		sizeof(struct iphdr);
>  	ret_val = cipso_v4_cache_check(cipso_ptr, cipso_ptr[1], secattr);
>  	if (ret_val == 0)
> -		goto socket_getattr_return;
> +		return ret_val;
>
>  	doi = ntohl(*(u32 *)&cipso_ptr[2]);
>  	rcu_read_lock();
>  	doi_def = cipso_v4_doi_getdef(doi);
>  	if (doi_def == NULL) {
>  		rcu_read_unlock();
> -		goto socket_getattr_return;
> +		return -ENOMSG;
>  	}
>  	switch (cipso_ptr[6]) {
>  	case CIPSO_V4_TAG_RBITMAP:
> @@ -1533,8 +1530,29 @@ int cipso_v4_socket_getattr(const struct
>  	}
>  	rcu_read_unlock();
>
> -socket_getattr_return:
> -	release_sock(sk);
> +	return ret_val;
> +}
> +
> +/**
> + * cipso_v4_socket_getattr - Get the security attributes from a socket
> + * @sock: the socket
> + * @secattr: the security attributes
> + *
> + * Description:
> + * Query @sock to see if there is a CIPSO option attached to the socket
> and if + * there is return the CIPSO security attributes in @secattr. 
> Returns zero on + * success and negative values on failure.
> + *
> + */
> +int cipso_v4_socket_getattr(const struct socket *sock,
> +			    struct netlbl_lsm_secattr *secattr)
> +{
> +	int ret_val;
> +
> +	lock_sock(sock->sk);
> +	ret_val = cipso_v4_sock_getattr(sock->sk, secattr);
> +	release_sock(sock->sk);
> +
>  	return ret_val;
>  }
>
> diff --git a/net/netlabel/netlabel_kapi.c b/net/netlabel/netlabel_kapi.c
> index 0fd8aaa..54fb7de 100644
> --- a/net/netlabel/netlabel_kapi.c
> +++ b/net/netlabel/netlabel_kapi.c
> @@ -85,6 +85,29 @@ socket_setattr_return:
>  }
>
>  /**
> + * netlbl_sock_getattr - Determine the security attributes of a sock
> + * @sk: the sock
> + * @secattr: the security attributes
> + *
> + * Description:
> + * Examines the given sock to see any NetLabel style labeling has been
> + * applied to the sock, if so it parses the socket label and returns the
> + * security attributes in @secattr.  Returns zero on success, negative
> values + * on failure.
> + *
> + */
> +int netlbl_sock_getattr(struct sock *sk, struct netlbl_lsm_secattr
> *secattr) +{
> +	int ret_val;
> +
> +	ret_val = cipso_v4_sock_getattr(sk, secattr);
> +	if (ret_val == 0)
> +		return 0;
> +
> +	return netlbl_unlabel_getattr(secattr);
> +}
> +
> +/**
>   * netlbl_socket_getattr - Determine the security attributes of a socket
>   * @sock: the socket
>   * @secattr: the security attributes
> diff --git a/security/selinux/ss/services.c
> b/security/selinux/ss/services.c index 910afa1..5497ad9 100644
> --- a/security/selinux/ss/services.c
> +++ b/security/selinux/ss/services.c
> @@ -2462,12 +2462,23 @@ void selinux_netlbl_sock_graft(struct so
>  {
>  	struct inode_security_struct *isec = SOCK_INODE(sock)->i_security;
>  	struct sk_security_struct *sksec = sk->sk_security;
> +	struct netlbl_lsm_secattr secattr;
> +	u32 nlbl_peer_sid;
> +
>
>  	if (sk->sk_family != PF_INET)
>  		return;
>
> +	netlbl_secattr_init(&secattr);
> +	if (netlbl_sock_getattr(sk, &secattr) == 0 &&
> +			selinux_netlbl_secattr_to_sid(NULL,
> +				&secattr,
> +				sksec->sid,
> +				&nlbl_peer_sid) == 0)
> +		sksec->peer_sid = nlbl_peer_sid;
> +	netlbl_secattr_destroy(&secattr, 0);
> +
>  	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

-- 
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: ipsec and getpeercon()

[Joshua Brindle]

On Tue, 2006-09-05 at 00:00 -0400, Paul Moore wrote:
> On Monday 04 September 2006 2:51 pm, Joshua Brindle wrote:
> > On Fri, 2006-09-01 at 18:32 -0400, Paul Moore wrote:
> > > Paul Moore wrote:
> > > > Venkat Yekkirala wrote:
> > > >>>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.
> > > >
> > > > That is not the issue I am dealing with right now.
> > > >
> > > > I now have a solution in mind, however, it is doubtful I will have a
> > > > chance to do any sort of testing on it before I leave tonight.  Once I
> > > > can give it a quick test to verify that it doesn't break anything I'll
> > > > post a patch for you and Joy to verify.
> > >
> > > Sorry for attaching the patch as an attachment but I'm in a rush to get
> > > out of here ...
> > >
> > > This patch is against David Miller's net-2.6.19 tree from a day or two
> > > ago, depending on your kernel you may have some fuzz when applying this
> > > patch.  I've only done some quick functional tests, but it seems to
> > > solve this problem.
> > >
> > > Joy, Venkat if you are able to test this and let me know the results I
> > > would appreciate it.
> > >
> > > Thanks.
> >
> > I tried the (rebased patch below, there were some rejects when applying
> > it to todays net-2.6.19) and got the same behavior as before:
> >
> > [root@joker-rawhide-clone ~]# ./server
> > server: got connection from 10.1.13.104, root:system_r:unconfined_t:s0
> >
> > [root@joker-rawhide-clone ~]# runcon -t passwd_t ./server
> > server: got connection from 10.1.13.104, root:system_r:passwd_t:s0
> 
> Thanks for giving the patch a try.  I'm confused as to why it didn't work for 
> you, can you try it without IPsec configured to see what results you get 
> (that is what I did and it worked fine)?
> 
> Thanks.

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.



--
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: ipsec and getpeercon()

[Joshua Brindle]

On Mon, 2006-09-04 at 23:32 -0400, Paul Moore wrote:
> On Monday 04 September 2006 8:43 am, Joshua Brindle wrote:
> > On Fri, 2006-09-01 at 16:19 -0400, Paul Moore wrote:
> > > Joy Latten wrote:
> > > > 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...
> > >
> > > A simple 'dmesg | grep NetLabel' will answer that question.
> > >
> > > I'll work on this and post something next week.  Unfortunately, the fix
> > > is not immediately obvious.
> >
> > Right, so I do have NetLabel running (didn't know that it shipped on in
> > Fedora kernels already)..
> >
> > There were no maps set up, it looks like all I had was the unlabeled
> > module.
> 
> That is what caused the problem then.  You don't need to have anything 
> actively configured, just having NetLabel built into the kernel and activated 
> will cause the bug.  If you feel like spinning your own kernel you can try 
> the patch I posted last Friday, it should fix the bug.
> 
> > This getpeercon() overloading seems to be a problem, how can an
> > application react reasonably if the label it gets when it calls
> > getpeercon() could come from multiple objects and have multiple
> > meanings?
> 
> It may be a problem right now but I think it is more of an issue of 
> reconciling the different network labeling systems.  The good news is that 
> work is ongoing to deal with this.
> 
> > To me getpeercon() means the context of the domain on the other side,
> > granted the implementation has been the socket context which, until now,
> > was always the domain on the other side. With the ability to label
> > sockets and with ipsec socket labeling and NetLabel (domain?) labeling
> > perhaps getpeercon() should be refactored into 2 functions, getpeercon()
> > and getsocketcon()?
> 
> I'm not sure that solves anything, all it does it make it the applications 
> problem as now the app developer has to have knowledge of the underlying 
> network labeling.  I think the best solution is to let the network labeling 
> reconciliation work take place, let the bugs get shaken out, and go from 
> there.
> 

I don't know, how are you really going to be able to reconcile multiple
labels on the underlying network connection? You don't think application
developers should be able to get the one they really want? 

Either way getpeercon() currently gets the context of the socket which I
don't think is expected by application developers, either when it is on
a local machine or with network labeling.

On the other hand using the socket label locally at least implements a
kind of IPC impersonation that flask specifies and can be very useful to
object managers, which is why I think the application developer should
be able to get the context that is actually interesting to them. Perhaps
a version that takes a class value that way one could get the
association context, the tcp socket (netlbl), process (actual remote
domain) and so on.


--
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: ipsec and getpeercon()

[Stephen Smalley]

On Tue, 2006-09-05 at 07:58 -0400, Joshua Brindle wrote:
> I don't know, how are you really going to be able to reconcile multiple
> labels on the underlying network connection? You don't think application
> developers should be able to get the one they really want?

See the secid reconciliation threads, along with Venkat's earlier
Labeled Networking Requirements and Design postings.

Application developers want a uniform way to get the peer security
information, without needing to know what mechanism was used to convey
it.

> Either way getpeercon() currently gets the context of the socket which I
> don't think is expected by application developers, either when it is on
> a local machine or with network labeling.

Do you mean the context of the peer socket or the context of the local
socket?  I'd agree that getting the context of the local socket makes no
sense for a getpeercon() call; I'm not sure what NetLabel is doing
there.  But if your concern is with using the context of the peer socket
vs. the peer process, that is intentional and part of the original Flask
design, pre-SELinux.  The sockets are the endpoints and serve as proxies
for the processes.

> On the other hand using the socket label locally at least implements a
> kind of IPC impersonation that flask specifies and can be very useful to
> object managers, which is why I think the application developer should
> be able to get the context that is actually interesting to them. Perhaps
> a version that takes a class value that way one could get the
> association context, the tcp socket (netlbl), process (actual remote
> domain) and so on.

No, that exposes the mechanism, and the application shouldn't have to
care.  It just wants security data for the peer, regardless of how it is
determined.  Whether that security data is determined based on the IPSEC
SA corresponding to the packet's SPI or from an IP option in the packet
or based on iptables secmark configuration (e.g. all packets received on
netif eth0 get a given context) is immaterial.

-- 
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: ipsec and getpeercon()

[Joshua Brindle]

On Tue, 2006-09-05 at 09:31 -0400, Stephen Smalley wrote:
> On Tue, 2006-09-05 at 07:58 -0400, Joshua Brindle wrote:
> > I don't know, how are you really going to be able to reconcile multiple
> > labels on the underlying network connection? You don't think application
> > developers should be able to get the one they really want?
> 
> See the secid reconciliation threads, along with Venkat's earlier
> Labeled Networking Requirements and Design postings.
> 
> Application developers want a uniform way to get the peer security
> information, without needing to know what mechanism was used to convey
> it.
> 
> > Either way getpeercon() currently gets the context of the socket which I
> > don't think is expected by application developers, either when it is on
> > a local machine or with network labeling.
> 
> Do you mean the context of the peer socket or the context of the local
> socket?  I'd agree that getting the context of the local socket makes no
> sense for a getpeercon() call; I'm not sure what NetLabel is doing
> there.  But if your concern is with using the context of the peer socket
> vs. the peer process, that is intentional and part of the original Flask
> design, pre-SELinux.  The sockets are the endpoints and serve as proxies
> for the processes.
> 

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 

> > On the other hand using the socket label locally at least implements a
> > kind of IPC impersonation that flask specifies and can be very useful to
> > object managers, which is why I think the application developer should
> > be able to get the context that is actually interesting to them. Perhaps
> > a version that takes a class value that way one could get the
> > association context, the tcp socket (netlbl), process (actual remote
> > domain) and so on.
> 
> No, that exposes the mechanism, and the application shouldn't have to
> care.  It just wants security data for the peer, regardless of how it is
> determined.  Whether that security data is determined based on the IPSEC
> SA corresponding to the packet's SPI or from an IP option in the packet
> or based on iptables secmark configuration (e.g. all packets received on
> netif eth0 get a given context) is immaterial.
> 

That's fine, I was suggesting a way for application developers to get
labels from various points if they want, getpeercon() should always get
the remote context though, which I guess means remote socket which is
very unfortunate for ipsec since that means at least 1 SPD entry per
domain connecting to the local machine.


--
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: ipsec and getpeercon()

[Joy Latten]

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

Re: ipsec and getpeercon()

[Paul Moore]

Joshua Brindle wrote:
> On Tue, 2006-09-05 at 00:00 -0400, Paul Moore wrote:
> 
>>On Monday 04 September 2006 2:51 pm, Joshua Brindle wrote:
>>
>>>On Fri, 2006-09-01 at 18:32 -0400, Paul Moore wrote:
>>>
>>>>Paul Moore wrote:
>>>>
>>>>>Venkat Yekkirala wrote:
>>>>>
>>>>>>>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.
>>>>>
>>>>>That is not the issue I am dealing with right now.
>>>>>
>>>>>I now have a solution in mind, however, it is doubtful I will have a
>>>>>chance to do any sort of testing on it before I leave tonight.  Once I
>>>>>can give it a quick test to verify that it doesn't break anything I'll
>>>>>post a patch for you and Joy to verify.
>>>>
>>>>Sorry for attaching the patch as an attachment but I'm in a rush to get
>>>>out of here ...
>>>>
>>>>This patch is against David Miller's net-2.6.19 tree from a day or two
>>>>ago, depending on your kernel you may have some fuzz when applying this
>>>>patch.  I've only done some quick functional tests, but it seems to
>>>>solve this problem.
>>>>
>>>>Joy, Venkat if you are able to test this and let me know the results I
>>>>would appreciate it.
>>>>
>>>>Thanks.
>>>
>>>I tried the (rebased patch below, there were some rejects when applying
>>>it to todays net-2.6.19) and got the same behavior as before:
>>>
>>>[root@joker-rawhide-clone ~]# ./server
>>>server: got connection from 10.1.13.104, root:system_r:unconfined_t:s0
>>>
>>>[root@joker-rawhide-clone ~]# runcon -t passwd_t ./server
>>>server: got connection from 10.1.13.104, root:system_r:passwd_t:s0
>>
>>Thanks for giving the patch a try.  I'm confused as to why it didn't work for 
>>you, can you try it without IPsec configured to see what results you get 
>>(that is what I did and it worked fine)?
>>
>>Thanks.
> 
> 
> 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 

Glad to see I'm not the only one who boots old kernels, personally I
like to blame those pesky, meddling sunspots ;)

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

-- 
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: ipsec and getpeercon()

[Paul Moore]

Stephen Smalley wrote:
> On Tue, 2006-09-05 at 07:58 -0400, Joshua Brindle wrote:
>>Either way getpeercon() currently gets the context of the socket which I
>>don't think is expected by application developers, either when it is on
>>a local machine or with network labeling.
> 
> 
> Do you mean the context of the peer socket or the context of the local
> socket?  I'd agree that getting the context of the local socket makes no
> sense for a getpeercon() call; I'm not sure what NetLabel is doing
> there.  But if your concern is with using the context of the peer socket
> vs. the peer process, that is intentional and part of the original Flask
> design, pre-SELinux.  The sockets are the endpoints and serve as proxies
> for the processes.

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

Re: ipsec and getpeercon()

[Paul Moore]

Joshua Brindle wrote:
> On Tue, 2006-09-05 at 09:31 -0400, Stephen Smalley wrote:
> 
>>On Tue, 2006-09-05 at 07:58 -0400, Joshua Brindle wrote:
>>
>>>I don't know, how are you really going to be able to reconcile multiple
>>>labels on the underlying network connection? You don't think application
>>>developers should be able to get the one they really want?
>>
>>See the secid reconciliation threads, along with Venkat's earlier
>>Labeled Networking Requirements and Design postings.
>>
>>Application developers want a uniform way to get the peer security
>>information, without needing to know what mechanism was used to convey
>>it.
>>
>>
>>>Either way getpeercon() currently gets the context of the socket which I
>>>don't think is expected by application developers, either when it is on
>>>a local machine or with network labeling.
>>
>>Do you mean the context of the peer socket or the context of the local
>>socket?  I'd agree that getting the context of the local socket makes no
>>sense for a getpeercon() call; I'm not sure what NetLabel is doing
>>there.  But if your concern is with using the context of the peer socket
>>vs. the peer process, that is intentional and part of the original Flask
>>design, pre-SELinux.  The sockets are the endpoints and serve as proxies
>>for the processes.
>>
> 
> 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 

Assuming you are running a version of the patch I posted last Friday and
you have not configured NetLabel at all (other than the default config
you get from booting with NetLabel built into the kernel) this context
is coming from the IPsec code and not the NetLabel code.

-- 
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: ipsec and getpeercon()

[Venkat Yekkirala]

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

Re: ipsec and getpeercon()

[Paul Moore]

Venkat Yekkirala wrote:
>>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).

What would you propose the proper behavior for when there is no xfrm or
node sid?  It seems to be much more consistent (and desirable) to pull
the TE bits from a single source.  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.

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

-- 
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: ipsec and getpeercon()

[Venkat Yekkirala]

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

Re: ipsec and getpeercon()

[Paul Moore]

Venkat Yekkirala wrote:
>>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.

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

>> 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 ;)

-- 
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: ipsec and getpeercon()

[Venkat Yekkirala]

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

RE: ipsec and getpeercon()

[Venkat Yekkirala]

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

Re: ipsec and getpeercon()

[Paul Moore]

Venkat Yekkirala wrote:
>>>>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.

See my above statement about not wanting to use the unlabeled sid
regardless of the MLS label because of it's implied meaning.  Using
unlabeled here doesn't seem (to me anyway) to be consistent with other
uses of the unlabeled sid.

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

I think in the case of no xfrm or nodeif sid the TE information is truly
absent.

-- 
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: ipsec and getpeercon()

[Venkat Yekkirala]

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

RE: ipsec and getpeercon()

[Venkat Yekkirala]

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

RE: ipsec and getpeercon()

[Joshua Brindle]

On Tue, 2006-09-05 at 16:01 -0400, Venkat Yekkirala wrote:
> > >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).

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.

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. 

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


--
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: ipsec and getpeercon()

[Venkat Yekkirala]

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

RE: ipsec and getpeercon()

[Venkat Yekkirala]

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.