Bug 982761

Created attachment 771202 [details]
coredump from the reproducer

A fix pushed in iproute-3.10.0-2.el7

Petr, unfortunately the fix seems not work correctly. Even though there is no segfault with iproute-3.10.0-2.1.el7, no SA is being added into kernel:

# ip xfrm state add src 10.0.0.2 dst 10.0.0.1 proto ah spi 0x12345678 ctx staff_u:lspp_test_r:lspp_harness_t:s0-s15:c0.c1023 auth md5 012345678901234 ; ip xfrm state
#

(see? no SA)

It should work as follows:

# ip xfrm state add src 10.0.0.2 dst 10.0.0.1 proto ah spi 0x12345678 ctx staff_u:lspp_test_r:lspp_harness_t:s0-s15:c0.c1023 auth md5 012345678901234 ; ip xfrm state
src 10.0.0.2 dst 10.0.0.1
        proto ah spi 0x12345678 reqid 0 mode transport
        replay-window 0 
        auth hmac(md5) 0x303132333435363738393031323334
        sel src 0.0.0.0/0 dst 0.0.0.0/0 
        security context staff_u:lspp_test_r:lspp_harness_t:s0-s15:c0.c1023 

Switching back to assigned.

This report is for segfault. This has been fixed. Moving back to ON_QA.

If you think the security associations are not set or listed properly, file a new bug report.

(I want to remark that the reproducer you provided does not work anywhere (RHEL-6, F21, upstream iproute sources).)

I also faced the same issue running the ipv6 TAHI tests on Fedora 19 . I debugged and found the issue to be in iproute2 with xfrm add command.
This is more a SIGABRT issue than a SIGSEGV when the strncpy's latest implementation causes it to spew buffer overflow detection failure with _strncpy_chk. 
I was able to fix this with strnlen+1 fix but there is a different fix available upstream : 
http://git.kernel.org/cgit/linux/kernel/git/shemminger/iproute2.git/commit/?id=99500b56d94dfa735a3d088fdbdde6c0c2638e78

Yes, the fix is different, but effectively equal.

The reason why the compiler complained and glibc aborted is that: 

struct xfrm_algo {
    char        alg_name[64];
    unsigned int    alg_key_len;    /* in bits */
    char        alg_key[0];
};

struct {
    union {
        struct xfrm_algo alg;
        struct xfrm_algo_aead aead;
        struct xfrm_algo_auth auth;
    } u;
    char buf[XFRM_ALGO_KEY_BUF_SIZE];
} alg = {};

buf = alg.u.alg.alg_key;

xfrm_algo_parse((void *)&alg, type, name, key,
                   buf, sizeof(alg.buf));

xfrm_algo_parse() did strncpy(buf, key, len). The xfrm_algo.alg_key is just a pointer that obviously should be set to alg.buf, but it isn't. At least I cannot find where it is done so. Thus glibc aborted. GCC warned just because xfrm_algo.alg_key is declared char[0].

I think the write to wrong address is still there. Upstream just replaced strncpy() with memcpy(). It maybe satisfies GCC, but does not fix the the real problem. That could explain why I cannot set the SA. Or am I missing something?

Sohny, does the latest upstream source work for you? It does not for me. Or do I have to load some kernel module manually?

(In reply to Petr Pisar from comment #7)
> 
> If you think the security associations are not set or listed properly, file
> a new bug report.
> 
Adding SA with SELinux context does not work only. I don't know how is responsible for translating the SELinux symbolic names into kernel internal identifiers. Ondrej, do you the labels exist in your system (staff_u:lspp_test_r:lspp_harness_t:s0-s15:c0.c1023)?

(In reply to Petr Pisar from comment #10)
> (In reply to Petr Pisar from comment #7)
> > 
> > If you think the security associations are not set or listed properly, file
> > a new bug report.
> > 
> Adding SA with SELinux context does not work only. I don't know how is
> responsible for translating the SELinux symbolic names into kernel internal
> identifiers. Ondrej, do you the labels exist in your system
> (staff_u:lspp_test_r:lspp_harness_t:s0-s15:c0.c1023)?

That is strange, with iproute-3.10.0-2.1.el7.x86_64, kernel-3.10.0-15.el7.x86_64 and selinux-policy-3.12.1-73.el7.noarch it works:

# ip xfrm state
# ip xfrm state add src 10.0.0.2 dst 10.0.0.1 proto ah spi 0x12345678 ctx staff_u:lspp_test_r:lspp_harness_t:s0-s15:c0.c1023 auth md5 0123456789012345
# ip xfrm state
src 10.0.0.2 dst 10.0.0.1
        proto ah spi 0x12345678 reqid 0 mode transport
        replay-window 0 
        auth-trunc hmac(md5) 0x30313233343536373839303132333435 96
        sel src 0.0.0.0/0 dst 0.0.0.0/0 
        security context staff_u:lspp_test_r:lspp_harness_t:s0-s15:c0.c1023 
# ip xfrm state flush
# ip xfrm state
#

The problem was probably in kernel, I cannot downgrade right now. Petr could you confirm that with the aforementioned kernel it works?

I tried latest packages (newer than your) and it does not work. Even if I replace your context with domains I have on the system (staff_u:staff_r:staff_t:s0-s15:c0.c1023). I will try to downgrade later, but I guess there is something that has to be enabled we miss.

Mirek,
would you know what can be wrong from a quick look? Some SElinux changes, some conditional loading of modules...

> Sohny, does the latest upstream source work for you? It does not for me. Or
> do I have to load some kernel module manually?

Well with F19 i get the following output. So i think it works

[root@llm128 ~]# ip xfrm state add src 10.0.0.2 dst 10.0.0.1 proto ah spi 0x12345678 auth md5 12
[root@llm128 ~]# ip xfrm state
src 10.0.0.2 dst 10.0.0.1
	proto ah spi 0x12345678 reqid 0 mode transport
	replay-window 0 
	auth-trunc hmac(md5) 0x3132 96
	sel src 0.0.0.0/0 dst 0.0.0.0/0 
[root@llm128 ~]# uname -a
Linux llm128.in.ibm.com 3.9.5-301.fc19.x86_64 #1 SMP Tue Jun 11 19:39:38 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

(In reply to Sohny from comment #14)
> > Sohny, does the latest upstream source work for you? It does not for me. Or
> > do I have to load some kernel module manually?
> 
> Well with F19 i get the following output. So i think it works
> 
> [root@llm128 ~]# ip xfrm state add src 10.0.0.2 dst 10.0.0.1 proto ah spi
> 0x12345678 auth md5 12

I've already narrowed the non-working scenario. It does not works only with the SELinux labeling in F19. I.e. if the ctx argument is specified.

Giving this for retesting to Ondrej. The original reported case should be tested explicitly by execution of tp/ipsec* tests on RHEL7 (that is done continuously).

I am confirming that on RHEL-7.0-20131018 it works as described in Comment #11. Petr - are you sure you have MLS selinux policy? Obviously you can use ctx only in MLS, otherwise it makes no sense. Base on Comment #11, #14 and #15 I consider this one to be verified.

Setting qe_test_coverage+ since we are testing this issue periodically as a part of Common Criteria testing as suggested in Comment #17.

(In reply to Ondrej Moriš from comment #18)
>  Petr - are you sure you have MLS selinux policy? Obviously you can use
> ctx only in MLS, otherwise it makes no sense.

That's it. I forgot completely on the policy type. You are right.

If I switch to the MLS, then attempt to add the IPSec policy with unresolvable context results into no error message or exit code but no policy is added. Attempt to add the policy with resolvable context results in success and I can see the new IPSec policy in the security policy dump incuding the SELinux context.

(I get SELinux denial in enforcing mode, so I had to switch into permissive mode, but that's another problem or misconfiguration of my system.)

So I also confirm it works within MLS SELlinux policy loaded.

This request was resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you have further questions about the request.