Labeled IPSec trying to match policy for peer label?

Labeled IPSec trying to match policy for peer label?

[Sven Vermeulen]

Hi all,

I'm trying to get a Labeled IPSec working, but the moment I enable a context
on the SPD, any attempt to set up an SA (by racoon) fails with the following
message:

Jul  5 20:25:16 test racoon: INFO: respond new phase 2 negotiation: 192.168.100.152[500]<=>192.168.100.153[500]
Jul  5 20:25:16 test racoon: ERROR: no policy found: 10.1.3.0/24[0] 10.1.2.0/24[0] proto=any dir=in sec_ctx:doi=1,alg=1,len=24,str=root:sysadm_r:ping_t:s0
Jul  5 20:25:16 test racoon: ERROR: failed to get proposal for responder.

There is (of course?) no policy for ping_t, only for ipsec_spd_t. Let me
show you the setkey instructions:

spdadd 10.1.2.0/24 10.1.3.0/24 any -ctx 1 1
  "system_u:object_r:ipsec_spd_t:s0" -P out ipsec
  esp/tunnel/192.168.100.152-192.168.100.153/require;

spdadd 10.1.3.0/24 10.1.2.0/24 any -ctx 1 1
  "system_u:object_r:ipsec_spd_t:s0" -P in ipsec
  esp/tunnel/192.168.100.153-192.168.100.152/require;

If I drop the "-ctx 1 1 "system_u:object_r:ipsec_spd_t:s0"" then the IPSec
works (I verified that it is indeed IPSec traffic). For allowing ping to
work across the Labeled IPSec setup, I have added allow rules for kernel_t
and ping_t to association:polmatch against ipsec_spd_t (without those, IPSec
isn't used as expected).

Considering I get the error message on the server side tells me that the
label is properly passed on (so ping_t is the peer label) but I was
expecting that it would match the policy on the ipsec_spd_t context?

What am I missing here? Is there a particular check that IPSec does further
that I'm not seeing (no denials are shown, even disabled all dontaudits)?

On the client side (where ping is invoked) the following is logged:

Jul  5 20:24:32 test racoon: INFO: initiate new phase 2 negotiation: 192.168.100.153[500]<=>192.168.100.152[500]
Jul  5 20:24:58 test racoon: INFO: unsupported PF_KEY message REGISTER
Jul  5 20:25:06 test racoon: INFO: security context doi: 1
Jul  5 20:25:06 test racoon: INFO: security context algorithm: 1
Jul  5 20:25:06 test racoon: INFO: security context length: 24
Jul  5 20:25:06 test racoon: INFO: security context: root:sysadm_r:ping_t:s0
Jul  5 20:25:06 test racoon: NOTIFY: no in-bound policy found: 10.1.2.0/24[0] 10.1.3.0/24[0] proto=any dir=in sec_ctx:doi=1,alg=1,len=24,str=root:sysadm_r:ping_t:s0
Jul  5 20:25:06 test racoon: INFO: initiate new phase 2 negotiation: 192.168.100.153[500]<=>192.168.100.152[500]
Jul  5 20:25:36 test racoon: INFO: IPsec-SA expired: ESP/Tunnel 192.168.100.152[500]->192.168.100.153[500] spi=220218943(0xd20463f)
Jul  5 20:25:36 test racoon: WARNING: PF_KEY EXPIRE message received from kernel for SA being negotiated. Stopping negotiation.


Wkr,
  Sven Vermeulen

--
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: Labeled IPSec trying to match policy for peer label?

[Paul Moore]

On Friday, July 05, 2013 08:39:02 PM Sven Vermeulen wrote:
> Hi all,
> 
> I'm trying to get a Labeled IPSec working, but the moment I enable a context
> on the SPD, any attempt to set up an SA (by racoon) fails with the
> following message:
> 
> Jul  5 20:25:16 test racoon: INFO: respond new phase 2 negotiation:
> 192.168.100.152[500]<=>192.168.100.153[500] Jul  5 20:25:16 test racoon:
> ERROR: no policy found: 10.1.3.0/24[0] 10.1.2.0/24[0] proto=any dir=in
> sec_ctx:doi=1,alg=1,len=24,str=root:sysadm_r:ping_t:s0 Jul  5 20:25:16 test
> racoon: ERROR: failed to get proposal for responder.
> 
> There is (of course?) no policy for ping_t, only for ipsec_spd_t. Let me
> show you the setkey instructions:
> 
> spdadd 10.1.2.0/24 10.1.3.0/24 any -ctx 1 1
>   "system_u:object_r:ipsec_spd_t:s0" -P out ipsec
>   esp/tunnel/192.168.100.152-192.168.100.153/require;
> 
> spdadd 10.1.3.0/24 10.1.2.0/24 any -ctx 1 1
>   "system_u:object_r:ipsec_spd_t:s0" -P in ipsec
>   esp/tunnel/192.168.100.153-192.168.100.152/require;
> 
> If I drop the "-ctx 1 1 "system_u:object_r:ipsec_spd_t:s0"" then the IPSec
> works (I verified that it is indeed IPSec traffic). For allowing ping to
> work across the Labeled IPSec setup, I have added allow rules for kernel_t
> and ping_t to association:polmatch against ipsec_spd_t (without those, IPSec
> isn't used as expected).
> 
> Considering I get the error message on the server side tells me that the
> label is properly passed on (so ping_t is the peer label) but I was
> expecting that it would match the policy on the ipsec_spd_t context?

Is the server side running the same SELinux policy as the client?  Does the 
server have a SPD entry that is labeled, e.g. '-ctx 1 1 
"system_u:object_r:ipsec_spd_t:s0"'?

-- 
paul moore
www.paul-moore.com


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Labeled IPSec trying to match policy for peer label?

[Sven Vermeulen]

On Fri, Jul 05, 2013 at 04:50:41PM -0400, Paul Moore wrote:
> > spdadd 10.1.2.0/24 10.1.3.0/24 any -ctx 1 1
> >   "system_u:object_r:ipsec_spd_t:s0" -P out ipsec
> >   esp/tunnel/192.168.100.152-192.168.100.153/require;
> > 
> > spdadd 10.1.3.0/24 10.1.2.0/24 any -ctx 1 1
> >   "system_u:object_r:ipsec_spd_t:s0" -P in ipsec
> >   esp/tunnel/192.168.100.153-192.168.100.152/require;
[...]
> Is the server side running the same SELinux policy as the client?  Does the 
> server have a SPD entry that is labeled, e.g. '-ctx 1 1 
> "system_u:object_r:ipsec_spd_t:s0"'?

Yes, both sides have the same setkey instructions (only the in/out is
switched) and are running the same SELinux policy & type. The racoon
configurations are also the same (of course each one with the right
addresses in the remote { ... } and sainfo { ... } definitions.

I am assuming nothing needs to be changed on racoon when running regular
IPSec or labeled IPSec? In any case, here is one of the configs:

path pre_shared_key "/etc/racoon/psk.txt";
remote 192.168.100.153 
{
        exchange_mode main,aggressive;
        proposal {
                encryption_algorithm 3des;
                hash_algorithm sha1;
                authentication_method pre_shared_key;
                dh_group modp1024;
        }
}

sainfo address 10.1.2.0/24 any address 10.1.3.0/24 any
{
        pfs_group modp768;
        encryption_algorithm 3des, blowfish 448, rijndael;
        authentication_algorithm hmac_sha1, hmac_md5;
        compression_algorithm deflate;
}

I am using ipsec-tools 0.8.0 build with --enable-security-context. There are
a few additional patches applied by the distribution ("sysctl", "def-psk"
and "include-vendoridh")

I'll be trying with ipsec-tools 0.8.1 later today.

Wkr,
	Sven Vermeulen

--
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: Labeled IPSec trying to match policy for peer label?

[Sven Vermeulen]

On Sat, Jul 06, 2013 at 08:39:52AM +0200, Sven Vermeulen wrote:
> On Fri, Jul 05, 2013 at 04:50:41PM -0400, Paul Moore wrote:
> > > spdadd 10.1.2.0/24 10.1.3.0/24 any -ctx 1 1
> > >   "system_u:object_r:ipsec_spd_t:s0" -P out ipsec
> > >   esp/tunnel/192.168.100.152-192.168.100.153/require;
> > >
> > > spdadd 10.1.3.0/24 10.1.2.0/24 any -ctx 1 1
> > >   "system_u:object_r:ipsec_spd_t:s0" -P in ipsec
> > >   esp/tunnel/192.168.100.153-192.168.100.152/require;
> [...]
> > Is the server side running the same SELinux policy as the client?  Does the
> > server have a SPD entry that is labeled, e.g. '-ctx 1 1
> > "system_u:object_r:ipsec_spd_t:s0"'?
>
> Yes, both sides have the same setkey instructions (only the in/out is
> switched) and are running the same SELinux policy & type. The racoon
> configurations are also the same (of course each one with the right
> addresses in the remote { ... } and sainfo { ... } definitions.

I tried with ipsec-tools 0.8.1 but no difference; I started racoon with
debugging on to see what I could have done wrong. Here is my analysis and
output:

At a certain point in time, isakmp_quick.c's get_proposal_r() method is
called, where the policy is eventually queried for:

#v+
/* get inboud policy */
sp_in = getsp_r(&spidx);
if (sp_in == NULL) {
  ...
  plog(LLV_ERROR, LOCATION, NULL, "no policy found: %s\n", spidx2str(&spidx));
}
#v-

The error I get at the end (no policy found) is triggered when getsp_r
doesn't return any policy. I enabled generate_policy in racoon just to make
sure it is here in the code that getsp_r returns no matches (as racoon then
tries to generate code and I see additional logging events).

So I take a look at the getsp_r() code, which traverses the &sptree list and
does two checks:

#v+
for (p = TAILQ_FIRST(&sptree); p; p = TAILQ_NEXT(p, chain)) {
        if (!cmpspidxstrict(spidx, &p->spidx))
                return p;

        if (!found && !cmpspidxwild(spidx, &p->spidx))
                found = p;
}
#v-

So the spidx one is the information from the packet, while &p->spidx is the
one from the database, right?

The cmpspidxstrict() method checks if the entries match (dir,
prefs, prefd, ul_proto) and if the socket addresses (?) match.

The cmpspidxwild() method checks similar stuff on the dir(ection), protocol,
family, and then it checks the differences on the socket level.

Now, considering the following output:

#v+
Jul  6 13:24:06 test racoon: DEBUG: sub:0x3f88b6e2c58: 10.1.3.0/24[0]
10.1.2.0/24[0] proto=any dir=in
sec_ctx:doi=1,alg=1,len=36,str=root:sysadm_r:ping_t:s0-s0:c0.c1023
Jul  6 13:24:06 test racoon: DEBUG: db :0x7e2229aca0: 10.1.3.0/24[0]
10.1.2.0/24[0] proto=any dir=fwd
sec_ctx:doi=1,alg=1,len=45,str=system_u:object_r:ipsec_spd_t:s0-s0:c0.c1023

Jul  6 13:24:06 test racoon: DEBUG: sub:0x3f88b6e2c58: 10.1.3.0/24[0]
10.1.2.0/24[0] proto=any dir=in
sec_ctx:doi=1,alg=1,len=36,str=root:sysadm_r:ping_t:s0-s0:c0.c1023
Jul  6 13:24:06 test racoon: DEBUG: db: 0x7e2229aca0: 10.1.3.0/24[0]
10.1.2.0/24[0] proto=any dir=fwd
sec_ctx:doi=1,alg=1,len=45,str=system_u:object_r:ipsec_spd_t:s0-s0:c0.c1023
#v-

No match; I get the entries twice (once for cmpspidxstrict() and one for
cmpspidxwild()).

#v+
Jul  6 13:24:06 test racoon: DEBUG: sub:0x3f88b6e2c58: 10.1.3.0/24[0]
10.1.2.0/24[0] proto=any dir=in
sec_ctx:doi=1,alg=1,len=36,str=root:sysadm_r:ping_t:s0-s0:c0.c1023
Jul  6 13:24:06 test racoon: DEBUG: db :0x7e2229af60: 10.1.3.0/24[0]
10.1.2.0/24[0] proto=any dir=in
sec_ctx:doi=1,alg=1,len=45,str=system_u:object_r:ipsec_spd_t:s0-s0:c0.c1023
Jul  6 13:24:06 test racoon: DEBUG: sub:0x3f88b6e2c58: 10.1.3.0/24[0]
10.1.2.0/24[0] proto=any dir=in
sec_ctx:doi=1,alg=1,len=36,str=root:sysadm_r:ping_t:s0-s0:c0.c1023
Jul  6 13:24:06 test racoon: DEBUG: db: 0x7e2229af60: 10.1.3.0/24[0]
10.1.2.0/24[0] proto=any dir=in
sec_ctx:doi=1,alg=1,len=45,str=system_u:object_r:ipsec_spd_t:s0-s0:c0.c1023
Jul  6 13:24:06 test racoon: DEBUG: 0x3f88b6e2c58 masked with /24: 10.1.3.0[0]
Jul  6 13:24:06 test racoon: DEBUG: 0x7e2229af60 masked with /24: 10.1.3.0[0]
Jul  6 13:24:06 test racoon: DEBUG: 0x3f88b6e2c58 masked with /24: 10.1.2.0[0]
Jul  6 13:24:06 test racoon: DEBUG: 0x7e2229af60 masked with /24: 10.1.2.0[0]
#v-

Here, I get the same entries again, but now with the "masked" stuff as well.
These masked stuff entries come from cmspidxwild(), so the earlier checks
all match (which we can see from the output).

Also, because I see two sets of "masked with" events, the first check
succeeds:

#v+
        mask_sockaddr((struct sockaddr *)&sa1, (struct sockaddr *)&a->src,
                b->prefs);
        mask_sockaddr((struct sockaddr *)&sa2, (struct sockaddr *)&b->src,
                b->prefs);
        plog(LLV_DEBUG, LOCATION, NULL, "%p masked with /%d: %s\n",
                a, b->prefs, saddr2str((struct sockaddr *)&sa1));
        plog(LLV_DEBUG, LOCATION, NULL, "%p masked with /%d: %s\n",
                b, b->prefs, saddr2str((struct sockaddr *)&sa2));
        if (cmpsaddr((struct sockaddr *)&sa1, (struct sockaddr *)&sa2)
> CMPSADDR_WILDPORT_MATCH)
                return 1;
#v-

But the second check seems to fail, because after the second check I would
expect information on the range checking:

#v+
        mask_sockaddr((struct sockaddr *)&sa1, (struct sockaddr *)&a->dst,
                b->prefd);
        mask_sockaddr((struct sockaddr *)&sa2, (struct sockaddr *)&b->dst,
                b->prefd);
        plog(LLV_DEBUG, LOCATION, NULL, "%p masked with /%d: %s\n",
                a, b->prefd, saddr2str((struct sockaddr *)&sa1));
        plog(LLV_DEBUG, LOCATION, NULL, "%p masked with /%d: %s\n",
                b, b->prefd, saddr2str((struct sockaddr *)&sa2));
        if (cmpsaddr((struct sockaddr *)&sa1, (struct sockaddr *)&sa2)
> CMPSADDR_WILDPORT_MATCH)
                return 1;
#v-

What is it trying to do here? Why are the checks on b->prefd in both
cases (and not on a->prefd first and then b->prefd)?

When I don't add the contexts, I don't even get to this location. It
nicely matches (I think the match then is in cmpspidxstrict()),
doesn't show the "masked with" information.

#v+
Jul  6 14:32:01 test racoon: DEBUG: sub:0x3a74d3e2418: 10.1.3.0/24[0]
10.1.2.0/24[0] proto=any dir=in
Jul  6 14:32:01 test racoon: DEBUG: db :0x7fde6a2f30: 10.1.3.0/24[0]
10.1.2.0/24[0] proto=any dir=fwd
Jul  6 14:32:01 test racoon: DEBUG: sub:0x3a74d3e2418: 10.1.3.0/24[0]
10.1.2.0/24[0] proto=any dir=in
Jul  6 14:32:01 test racoon: DEBUG: db: 0x7fde6a2f30: 10.1.3.0/24[0]
10.1.2.0/24[0] proto=any dir=fwd
Jul  6 14:32:01 test racoon: DEBUG: sub:0x3a74d3e2418: 10.1.3.0/24[0]
10.1.2.0/24[0] proto=any dir=in
Jul  6 14:32:01 test racoon: DEBUG: db :0x7fde6a31f0: 10.1.3.0/24[0]
10.1.2.0/24[0] proto=any dir=in
#v-

Here it has found a match, because the next check uses an outgoing "sub":

#v+
Jul  6 14:32:01 test racoon: DEBUG: sub:0x3a74d3e2418: 10.1.2.0/24[0]
10.1.3.0/24[0] proto=any dir=out
Jul  6 14:32:01 test racoon: DEBUG: db :0x7fde6a2f30: 10.1.3.0/24[0]
10.1.2.0/24[0] proto=any dir=fwd
Jul  6 14:32:01 test racoon: DEBUG: sub:0x3a74d3e2418: 10.1.2.0/24[0]
10.1.3.0/24[0] proto=any dir=out
Jul  6 14:32:01 test racoon: DEBUG: db: 0x7fde6a2f30: 10.1.3.0/24[0]
10.1.2.0/24[0] proto=any dir=fwd
Jul  6 14:32:01 test racoon: DEBUG: sub:0x3a74d3e2418: 10.1.2.0/24[0]
10.1.3.0/24[0] proto=any dir=out
Jul  6 14:32:01 test racoon: DEBUG: db :0x7fde6a31f0: 10.1.3.0/24[0]
10.1.2.0/24[0] proto=any dir=in
Jul  6 14:32:01 test racoon: DEBUG: sub:0x3a74d3e2418: 10.1.2.0/24[0]
10.1.3.0/24[0] proto=any dir=out
Jul  6 14:32:01 test racoon: DEBUG: db: 0x7fde6a31f0: 10.1.3.0/24[0]
10.1.2.0/24[0] proto=any dir=in
Jul  6 14:32:01 test racoon: DEBUG: sub:0x3a74d3e2418: 10.1.2.0/24[0]
10.1.3.0/24[0] proto=any dir=out
Jul  6 14:32:01 test racoon: DEBUG: db :0x7fde6a35f0: 10.1.2.0/24[0]
10.1.3.0/24[0] proto=any dir=out
Jul  6 14:32:01 test racoon: DEBUG: suitable SP found:10.1.2.0/24[0]
10.1.3.0/24[0] proto=any dir=out
#v-

Wkr,
Sven Vermeulen

--
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: Labeled IPSec trying to match policy for peer label?

[Chad Hanson]

Are you running with MLS policy? I am curious since the last output
showed: system_u:object_r:ipsec_spd_t:s0-s0:c0.c1023. I would expect
the following SPD context for MLS:
system_u:object_r:ipsec_spd_t:s0-s15:c0.c1023.  If not using MLS,  you
would always fail in within_range()  at

if (!mls_ready)    /*mls may not be enabled */
           return 0

There should be a log message at the startup of racoon if MLS is
disabled. I didn't originally notice your original SPD context wasn't
ranged: system_u:object_r:ipsec_spd_t:s0. This typically would be
system_u:object_r:ipsec_spd_t:s0-s15:c0.c1023 on a MLS system.

On Sat, Jul 6, 2013 at 8:41 AM, Sven Vermeulen <sven.vermeulen@siphos.be> wrote:
> On Sat, Jul 06, 2013 at 08:39:52AM +0200, Sven Vermeulen wrote:
>> On Fri, Jul 05, 2013 at 04:50:41PM -0400, Paul Moore wrote:
>> > > spdadd 10.1.2.0/24 10.1.3.0/24 any -ctx 1 1
>> > >   "system_u:object_r:ipsec_spd_t:s0" -P out ipsec
>> > >   esp/tunnel/192.168.100.152-192.168.100.153/require;
>> > >
>> > > spdadd 10.1.3.0/24 10.1.2.0/24 any -ctx 1 1
>> > >   "system_u:object_r:ipsec_spd_t:s0" -P in ipsec
>> > >   esp/tunnel/192.168.100.153-192.168.100.152/require;
>> [...]
>> > Is the server side running the same SELinux policy as the client?  Does the
>> > server have a SPD entry that is labeled, e.g. '-ctx 1 1
>> > "system_u:object_r:ipsec_spd_t:s0"'?
>>
>> Yes, both sides have the same setkey instructions (only the in/out is
>> switched) and are running the same SELinux policy & type. The racoon
>> configurations are also the same (of course each one with the right
>> addresses in the remote { ... } and sainfo { ... } definitions.
>
> I tried with ipsec-tools 0.8.1 but no difference; I started racoon with
> debugging on to see what I could have done wrong. Here is my analysis and
> output:
>
> At a certain point in time, isakmp_quick.c's get_proposal_r() method is
> called, where the policy is eventually queried for:
>
> #v+
> /* get inboud policy */
> sp_in = getsp_r(&spidx);
> if (sp_in == NULL) {
>   ...
>   plog(LLV_ERROR, LOCATION, NULL, "no policy found: %s\n", spidx2str(&spidx));
> }
> #v-
>
> The error I get at the end (no policy found) is triggered when getsp_r
> doesn't return any policy. I enabled generate_policy in racoon just to make
> sure it is here in the code that getsp_r returns no matches (as racoon then
> tries to generate code and I see additional logging events).
>
> So I take a look at the getsp_r() code, which traverses the &sptree list and
> does two checks:
>
> #v+
> for (p = TAILQ_FIRST(&sptree); p; p = TAILQ_NEXT(p, chain)) {
>         if (!cmpspidxstrict(spidx, &p->spidx))
>                 return p;
>
>         if (!found && !cmpspidxwild(spidx, &p->spidx))
>                 found = p;
> }
> #v-
>
> So the spidx one is the information from the packet, while &p->spidx is the
> one from the database, right?
>
> The cmpspidxstrict() method checks if the entries match (dir,
> prefs, prefd, ul_proto) and if the socket addresses (?) match.
>
> The cmpspidxwild() method checks similar stuff on the dir(ection), protocol,
> family, and then it checks the differences on the socket level.
>
> Now, considering the following output:
>
> #v+
> Jul  6 13:24:06 test racoon: DEBUG: sub:0x3f88b6e2c58: 10.1.3.0/24[0]
> 10.1.2.0/24[0] proto=any dir=in
> sec_ctx:doi=1,alg=1,len=36,str=root:sysadm_r:ping_t:s0-s0:c0.c1023
> Jul  6 13:24:06 test racoon: DEBUG: db :0x7e2229aca0: 10.1.3.0/24[0]
> 10.1.2.0/24[0] proto=any dir=fwd
> sec_ctx:doi=1,alg=1,len=45,str=system_u:object_r:ipsec_spd_t:s0-s0:c0.c1023
>
> Jul  6 13:24:06 test racoon: DEBUG: sub:0x3f88b6e2c58: 10.1.3.0/24[0]
> 10.1.2.0/24[0] proto=any dir=in
> sec_ctx:doi=1,alg=1,len=36,str=root:sysadm_r:ping_t:s0-s0:c0.c1023
> Jul  6 13:24:06 test racoon: DEBUG: db: 0x7e2229aca0: 10.1.3.0/24[0]
> 10.1.2.0/24[0] proto=any dir=fwd
> sec_ctx:doi=1,alg=1,len=45,str=system_u:object_r:ipsec_spd_t:s0-s0:c0.c1023
> #v-
>
> No match; I get the entries twice (once for cmpspidxstrict() and one for
> cmpspidxwild()).
>
> #v+
> Jul  6 13:24:06 test racoon: DEBUG: sub:0x3f88b6e2c58: 10.1.3.0/24[0]
> 10.1.2.0/24[0] proto=any dir=in
> sec_ctx:doi=1,alg=1,len=36,str=root:sysadm_r:ping_t:s0-s0:c0.c1023
> Jul  6 13:24:06 test racoon: DEBUG: db :0x7e2229af60: 10.1.3.0/24[0]
> 10.1.2.0/24[0] proto=any dir=in
> sec_ctx:doi=1,alg=1,len=45,str=system_u:object_r:ipsec_spd_t:s0-s0:c0.c1023
> Jul  6 13:24:06 test racoon: DEBUG: sub:0x3f88b6e2c58: 10.1.3.0/24[0]
> 10.1.2.0/24[0] proto=any dir=in
> sec_ctx:doi=1,alg=1,len=36,str=root:sysadm_r:ping_t:s0-s0:c0.c1023
> Jul  6 13:24:06 test racoon: DEBUG: db: 0x7e2229af60: 10.1.3.0/24[0]
> 10.1.2.0/24[0] proto=any dir=in
> sec_ctx:doi=1,alg=1,len=45,str=system_u:object_r:ipsec_spd_t:s0-s0:c0.c1023
> Jul  6 13:24:06 test racoon: DEBUG: 0x3f88b6e2c58 masked with /24: 10.1.3.0[0]
> Jul  6 13:24:06 test racoon: DEBUG: 0x7e2229af60 masked with /24: 10.1.3.0[0]
> Jul  6 13:24:06 test racoon: DEBUG: 0x3f88b6e2c58 masked with /24: 10.1.2.0[0]
> Jul  6 13:24:06 test racoon: DEBUG: 0x7e2229af60 masked with /24: 10.1.2.0[0]
> #v-
>
> Here, I get the same entries again, but now with the "masked" stuff as well.
> These masked stuff entries come from cmspidxwild(), so the earlier checks
> all match (which we can see from the output).
>
> Also, because I see two sets of "masked with" events, the first check
> succeeds:
>
> #v+
>         mask_sockaddr((struct sockaddr *)&sa1, (struct sockaddr *)&a->src,
>                 b->prefs);
>         mask_sockaddr((struct sockaddr *)&sa2, (struct sockaddr *)&b->src,
>                 b->prefs);
>         plog(LLV_DEBUG, LOCATION, NULL, "%p masked with /%d: %s\n",
>                 a, b->prefs, saddr2str((struct sockaddr *)&sa1));
>         plog(LLV_DEBUG, LOCATION, NULL, "%p masked with /%d: %s\n",
>                 b, b->prefs, saddr2str((struct sockaddr *)&sa2));
>         if (cmpsaddr((struct sockaddr *)&sa1, (struct sockaddr *)&sa2)
>> CMPSADDR_WILDPORT_MATCH)
>                 return 1;
> #v-
>
> But the second check seems to fail, because after the second check I would
> expect information on the range checking:
>
> #v+
>         mask_sockaddr((struct sockaddr *)&sa1, (struct sockaddr *)&a->dst,
>                 b->prefd);
>         mask_sockaddr((struct sockaddr *)&sa2, (struct sockaddr *)&b->dst,
>                 b->prefd);
>         plog(LLV_DEBUG, LOCATION, NULL, "%p masked with /%d: %s\n",
>                 a, b->prefd, saddr2str((struct sockaddr *)&sa1));
>         plog(LLV_DEBUG, LOCATION, NULL, "%p masked with /%d: %s\n",
>                 b, b->prefd, saddr2str((struct sockaddr *)&sa2));
>         if (cmpsaddr((struct sockaddr *)&sa1, (struct sockaddr *)&sa2)
>> CMPSADDR_WILDPORT_MATCH)
>                 return 1;
> #v-
>
> What is it trying to do here? Why are the checks on b->prefd in both
> cases (and not on a->prefd first and then b->prefd)?
>
> When I don't add the contexts, I don't even get to this location. It
> nicely matches (I think the match then is in cmpspidxstrict()),
> doesn't show the "masked with" information.
>
> #v+
> Jul  6 14:32:01 test racoon: DEBUG: sub:0x3a74d3e2418: 10.1.3.0/24[0]
> 10.1.2.0/24[0] proto=any dir=in
> Jul  6 14:32:01 test racoon: DEBUG: db :0x7fde6a2f30: 10.1.3.0/24[0]
> 10.1.2.0/24[0] proto=any dir=fwd
> Jul  6 14:32:01 test racoon: DEBUG: sub:0x3a74d3e2418: 10.1.3.0/24[0]
> 10.1.2.0/24[0] proto=any dir=in
> Jul  6 14:32:01 test racoon: DEBUG: db: 0x7fde6a2f30: 10.1.3.0/24[0]
> 10.1.2.0/24[0] proto=any dir=fwd
> Jul  6 14:32:01 test racoon: DEBUG: sub:0x3a74d3e2418: 10.1.3.0/24[0]
> 10.1.2.0/24[0] proto=any dir=in
> Jul  6 14:32:01 test racoon: DEBUG: db :0x7fde6a31f0: 10.1.3.0/24[0]
> 10.1.2.0/24[0] proto=any dir=in
> #v-
>
> Here it has found a match, because the next check uses an outgoing "sub":
>
> #v+
> Jul  6 14:32:01 test racoon: DEBUG: sub:0x3a74d3e2418: 10.1.2.0/24[0]
> 10.1.3.0/24[0] proto=any dir=out
> Jul  6 14:32:01 test racoon: DEBUG: db :0x7fde6a2f30: 10.1.3.0/24[0]
> 10.1.2.0/24[0] proto=any dir=fwd
> Jul  6 14:32:01 test racoon: DEBUG: sub:0x3a74d3e2418: 10.1.2.0/24[0]
> 10.1.3.0/24[0] proto=any dir=out
> Jul  6 14:32:01 test racoon: DEBUG: db: 0x7fde6a2f30: 10.1.3.0/24[0]
> 10.1.2.0/24[0] proto=any dir=fwd
> Jul  6 14:32:01 test racoon: DEBUG: sub:0x3a74d3e2418: 10.1.2.0/24[0]
> 10.1.3.0/24[0] proto=any dir=out
> Jul  6 14:32:01 test racoon: DEBUG: db :0x7fde6a31f0: 10.1.3.0/24[0]
> 10.1.2.0/24[0] proto=any dir=in
> Jul  6 14:32:01 test racoon: DEBUG: sub:0x3a74d3e2418: 10.1.2.0/24[0]
> 10.1.3.0/24[0] proto=any dir=out
> Jul  6 14:32:01 test racoon: DEBUG: db: 0x7fde6a31f0: 10.1.3.0/24[0]
> 10.1.2.0/24[0] proto=any dir=in
> Jul  6 14:32:01 test racoon: DEBUG: sub:0x3a74d3e2418: 10.1.2.0/24[0]
> 10.1.3.0/24[0] proto=any dir=out
> Jul  6 14:32:01 test racoon: DEBUG: db :0x7fde6a35f0: 10.1.2.0/24[0]
> 10.1.3.0/24[0] proto=any dir=out
> Jul  6 14:32:01 test racoon: DEBUG: suitable SP found:10.1.2.0/24[0]
> 10.1.3.0/24[0] proto=any dir=out
> #v-
>
> Wkr,
> Sven Vermeulen
>
> --
> 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.

--
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: Labeled IPSec trying to match policy for peer label?

[Sven Vermeulen]

On Sat, Jul 06, 2013 at 11:40:46AM -0400, Chad Hanson wrote:
> Are you running with MLS policy? I am curious since the last output
> showed: system_u:object_r:ipsec_spd_t:s0-s0:c0.c1023. I would expect
> the following SPD context for MLS:
> system_u:object_r:ipsec_spd_t:s0-s15:c0.c1023.  If not using MLS,  you
> would always fail in within_range()  at
> 
> if (!mls_ready)    /*mls may not be enabled */
>            return 0
> 
> There should be a log message at the startup of racoon if MLS is
> disabled. I didn't originally notice your original SPD context wasn't
> ranged: system_u:object_r:ipsec_spd_t:s0. This typically would be
> system_u:object_r:ipsec_spd_t:s0-s15:c0.c1023 on a MLS system.

I'm running an MLS-enabled policy (but its MCS, so only a single sensitivity
level but multiple categories). I was thinking about the range as well, but
that doesn't seem to help.

Right now, my spdadd statements include the c0.c1023 range, and I'm trying
to generate communication through both a s0:c0.c1023-ranged process as well as
"just" s0 to see what happens. Still no luck.

spdadd 10.1.2.0/24 10.1.3.0/24 any -ctx 1 1
  "system_u:object_r:ipsec_spd_t:s0-s0:c0.c1023" -P out ipsec
  esp/tunnel/192.168.100.152-192.168.100.153/require;

spdadd 10.1.3.0/24 10.1.2.0/24 any -ctx 1 1
  "system_u:object_r:ipsec_spd_t:s0-s0:c0.c1023" -P in ipsec
  esp/tunnel/192.168.100.153-192.168.100.152/require;

There is no logging related to MLS.

I also changed SELinux from enforcing to permissive but that didn't change
the behavior here. I'm going to start inserting the necessary print
statements in the code to see when (and why) the association isn't set up.

Wkr,
	Sven Vermeulen

--
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: Labeled IPSec trying to match policy for peer label?

[Joe Nall]

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

We use transport instead of tunnel, but this is out of a working mls client configuration script:

CLEARANCE=s15:c0.c1023
...
spdadd ${LOCAL_IP} ${REMOTE_IP} any -ctx 1 1 "system_u:object_r:ipsec_spd_t:s0-${CLEARANCE}" -P out ipsec esp/transport//require;
spdadd ${REMOTE_IP} ${LOCAL_IP} any -ctx 1 1 "system_u:object_r:ipsec_spd_t:s0-${CLEARANCE}" -P in  ipsec esp/transport//require;

The environment is RHEL 6.2 with racoon (not openswan). racoon.conf:
...
sainfo anonymous
{
    lifetime time 36 hours ;
    encryption_algorithm aes ;
    authentication_algorithm hmac_sha1 ;
    compression_algorithm deflate ;
}

remote anonymous
{
    dpd_delay 10;
    exchange_mode main,base;
    lifetime time 36 hours ;
    proposal {
        encryption_algorithm aes;
        hash_algorithm sha1;
        authentication_method pre_shared_key;
        dh_group 1;
    }
}
---
joe

On Jul 6, 2013, at 2:21 PM, Sven Vermeulen <sven.vermeulen@siphos.be> wrote:

> On Sat, Jul 06, 2013 at 11:40:46AM -0400, Chad Hanson wrote:
>> Are you running with MLS policy? I am curious since the last output
>> showed: system_u:object_r:ipsec_spd_t:s0-s0:c0.c1023. I would expect
>> the following SPD context for MLS:
>> system_u:object_r:ipsec_spd_t:s0-s15:c0.c1023.  If not using MLS,  you
>> would always fail in within_range()  at
>> 
>> if (!mls_ready)    /*mls may not be enabled */
>>           return 0
>> 
>> There should be a log message at the startup of racoon if MLS is
>> disabled. I didn't originally notice your original SPD context wasn't
>> ranged: system_u:object_r:ipsec_spd_t:s0. This typically would be
>> system_u:object_r:ipsec_spd_t:s0-s15:c0.c1023 on a MLS system.
> 
> I'm running an MLS-enabled policy (but its MCS, so only a single sensitivity
> level but multiple categories). I was thinking about the range as well, but
> that doesn't seem to help.
> 
> Right now, my spdadd statements include the c0.c1023 range, and I'm trying
> to generate communication through both a s0:c0.c1023-ranged process as well as
> "just" s0 to see what happens. Still no luck.
> 
> spdadd 10.1.2.0/24 10.1.3.0/24 any -ctx 1 1
>  "system_u:object_r:ipsec_spd_t:s0-s0:c0.c1023" -P out ipsec
>  esp/tunnel/192.168.100.152-192.168.100.153/require;
> 
> spdadd 10.1.3.0/24 10.1.2.0/24 any -ctx 1 1
>  "system_u:object_r:ipsec_spd_t:s0-s0:c0.c1023" -P in ipsec
>  esp/tunnel/192.168.100.153-192.168.100.152/require;
> 
> There is no logging related to MLS.
> 
> I also changed SELinux from enforcing to permissive but that didn't change
> the behavior here. I'm going to start inserting the necessary print
> statements in the code to see when (and why) the association isn't set up.
> 
> Wkr,
> 	Sven Vermeulen
> 
> --
> 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.


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 6003 bytes --]

Re: Labeled IPSec trying to match policy for peer label? (solved)

[Sven Vermeulen]

On Sat, Jul 06, 2013 at 09:21:47PM +0200, Sven Vermeulen wrote:
> On Sat, Jul 06, 2013 at 11:40:46AM -0400, Chad Hanson wrote:
> > Are you running with MLS policy? I am curious since the last output
> > showed: system_u:object_r:ipsec_spd_t:s0-s0:c0.c1023. I would expect
> > the following SPD context for MLS:
> > system_u:object_r:ipsec_spd_t:s0-s15:c0.c1023.  If not using MLS,  you
> > would always fail in within_range()  at
> > 
> > if (!mls_ready)    /*mls may not be enabled */
> >            return 0
> > 
> > There should be a log message at the startup of racoon if MLS is
> > disabled. I didn't originally notice your original SPD context wasn't
> > ranged: system_u:object_r:ipsec_spd_t:s0. This typically would be
> > system_u:object_r:ipsec_spd_t:s0-s15:c0.c1023 on a MLS system.
> 
> I'm running an MLS-enabled policy (but its MCS, so only a single sensitivity
> level but multiple categories). I was thinking about the range as well, but
> that doesn't seem to help.

Meh, it *was* the mls_ready variable - it was still 0.

I didn't see any logs because ipsec-tools initializes its logging (ploginit)
/after/ it calls the init_avc, so the log message about MLS being disabled
was never shown.

Turns out I had to allow racoon_t getattr rights on the security_t
filesystem and everything works now. I didn't catch it with permissive mode
because I changed to permissive mode /after/ racoon was started.

Thanks for all the help!

	Sven Vermeulen

--
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: Labeled IPSec trying to match policy for peer label? (solved)

[Chad Hanson]

Glad to hear you found the issue. Everything else looked good,
especially once you added the MCS range.

On Sun, Jul 7, 2013 at 4:33 AM, Sven Vermeulen <sven.vermeulen@siphos.be> wrote:
> On Sat, Jul 06, 2013 at 09:21:47PM +0200, Sven Vermeulen wrote:
>> On Sat, Jul 06, 2013 at 11:40:46AM -0400, Chad Hanson wrote:
>> > Are you running with MLS policy? I am curious since the last output
>> > showed: system_u:object_r:ipsec_spd_t:s0-s0:c0.c1023. I would expect
>> > the following SPD context for MLS:
>> > system_u:object_r:ipsec_spd_t:s0-s15:c0.c1023.  If not using MLS,  you
>> > would always fail in within_range()  at
>> >
>> > if (!mls_ready)    /*mls may not be enabled */
>> >            return 0
>> >
>> > There should be a log message at the startup of racoon if MLS is
>> > disabled. I didn't originally notice your original SPD context wasn't
>> > ranged: system_u:object_r:ipsec_spd_t:s0. This typically would be
>> > system_u:object_r:ipsec_spd_t:s0-s15:c0.c1023 on a MLS system.
>>
>> I'm running an MLS-enabled policy (but its MCS, so only a single sensitivity
>> level but multiple categories). I was thinking about the range as well, but
>> that doesn't seem to help.
>
> Meh, it *was* the mls_ready variable - it was still 0.
>
> I didn't see any logs because ipsec-tools initializes its logging (ploginit)
> /after/ it calls the init_avc, so the log message about MLS being disabled
> was never shown.
>
> Turns out I had to allow racoon_t getattr rights on the security_t
> filesystem and everything works now. I didn't catch it with permissive mode
> because I changed to permissive mode /after/ racoon was started.
>
> Thanks for all the help!
>
>         Sven Vermeulen

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