Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1675421 > unrolled thread

selftests/capabilities: test FAIL on linux mainline and linux-next and PASS on linux-4.4.70+

Started byNaresh Kamboju <naresh.kamboju@linaro.org>
First post2017-06-27 10:50 +0200
Last post2017-06-27 17:50 +0200
Articles 12 — 6 participants

Back to article view | Back to linux.kernel

Contents

  selftests/capabilities: test FAIL on linux mainline and linux-next  and PASS on linux-4.4.70+ Naresh Kamboju <naresh.kamboju@linaro.org> - 2017-06-27 10:50 +0200
    Re: selftests/capabilities: test FAIL on linux mainline and  linux-next and PASS on linux-4.4.70+ Greg KH <greg@kroah.com> - 2017-06-27 17:40 +0200
      Re: selftests/capabilities: test FAIL on linux mainline and  linux-next and PASS on linux-4.4.70+ Greg KH <greg@kroah.com> - 2017-06-27 17:40 +0200
        Re: selftests/capabilities: test FAIL on linux mainline and  linux-next and PASS on linux-4.4.70+ Shuah Khan <shuahkh@osg.samsung.com> - 2017-06-28 01:20 +0200
          Re: selftests/capabilities: test FAIL on linux mainline and  linux-next and PASS on linux-4.4.70+ Kees Cook <keescook@chromium.org> - 2017-06-28 06:40 +0200
            Re: selftests/capabilities: test FAIL on linux mainline and  linux-next and PASS on linux-4.4.70+ Andy Lutomirski <luto@kernel.org> - 2017-06-28 23:30 +0200
              Re: selftests/capabilities: test FAIL on linux mainline and linux-next and PASS on linux-4.4.70+ ebiederm@xmission.com (Eric W. Biederman) - 2017-06-29 16:20 +0200
                Re: selftests/capabilities: test FAIL on linux mainline and linux-next and PASS on linux-4.4.70+ ebiederm@xmission.com (Eric W. Biederman) - 2017-06-29 16:40 +0200
                  Re: selftests/capabilities: test FAIL on linux mainline and  linux-next and PASS on linux-4.4.70+ Andy Lutomirski <luto@kernel.org> - 2017-06-29 17:50 +0200
                    Re: selftests/capabilities: test FAIL on linux mainline and linux-next and PASS on linux-4.4.70+ ebiederm@xmission.com (Eric W. Biederman) - 2017-06-29 18:40 +0200
    Re: selftests/capabilities: test FAIL on linux mainline and  linux-next and PASS on linux-4.4.70+ Shuah Khan <shuahkh@osg.samsung.com> - 2017-06-27 17:40 +0200
      Re: selftests/capabilities: test FAIL on linux mainline and  linux-next and PASS on linux-4.4.70+ Shuah Khan <shuahkh@osg.samsung.com> - 2017-06-27 17:50 +0200

#1675421 — selftests/capabilities: test FAIL on linux mainline and linux-next and PASS on linux-4.4.70+

FromNaresh Kamboju <naresh.kamboju@linaro.org>
Date2017-06-27 10:50 +0200
Subjectselftests/capabilities: test FAIL on linux mainline and linux-next and PASS on linux-4.4.70+
Message-ID<tWUm6-6qI-17@gated-at.bofh.it>
selftest capabilities test failed on linux mainline and linux-next and
PASS on linux-4.4.70+
Tested on HiKey ARM64 Development board.

A bug reported in Linaro bug tracking system,
LKFT: Capabilities test_execve fail Wrong effective state AT_SECURE is not set
https://bugs.linaro.org/show_bug.cgi?id=2947

Please guide me to debug the reason for failure.
Kernel config link,
https://pastebin.com/P1uYmdMG

Linux version 4.12.0-rc7-00004-gda8b14e (buildslave@x86-64-08) (gcc
version 6.2.1 20161016 (Linaro GCC 6.2-2016.11) ) #1 SMP PREEMPT Mon
Jun 26 20:04:35 UTC 2017

Linux version 4.12.0-rc7-next-20170627 (buildslave@x86-64-07) (gcc
version 6.2.1 20161016 (Linaro GCC 6.2-2016.11)) #1 SMP PREEMPT Tue
Jun 27 06:33:39 UTC 2017

LAVA job id:
https://lkft.validation.linaro.org/scheduler/job/4397#L1412

Running tests in capabilities
========================================
[OK] Capabilities after execve were correct
[OK] Capabilities after execve were correct
[OK] Capabilities after execve were correct
[OK] Capabilities after execve were correct
[FAIL] Wrong effective state (AT_SECURE is not set)
[OK] Capabilities after execve were correct
[FAIL] Wrong ambient state (AT_SECURE is not set)
[FAIL] Wrong ambient state (AT_SECURE is not set)
[RUN] +++ Tests with uid == 0 +++
[NOTE] Using global UIDs for tests
[RUN] Root => ep
[OK] Child succeeded
[OK] Check cap_ambient manipulation rules
[OK] PR_CAP_AMBIENT_RAISE failed on non-inheritable cap
[OK] PR_CAP_AMBIENT_RAISE failed on non-permitted cap
[OK] PR_CAP_AMBIENT_RAISE worked
[OK] Basic manipulation appears to work
[RUN] Root +i => eip
[OK] Child succeeded
[RUN] UID 0 +ia => eipa
[OK] Child succeeded
[RUN] Root +ia, suidroot => eipa
[OK] Child succeeded
[RUN] Root +ia, suidnonroot => ip
[FAIL] Child failed
[RUN] Root +ia, sgidroot => eipa
[OK] Child succeeded
[FAIL] Child failed
[RUN] Root +ia, sgidnonroot => eip
[FAIL] Child failed
[OK] Capabilities after execve were correct
[OK] Capabilities after execve were correct
[OK] Capabilities after execve were correct
[FAIL] Wrong effective state (AT_SECURE is not set)
[FAIL] Child failed
[FAIL] Child failed
selftests: test_execve [FAIL]

capabilities test PASS on Linux-4.4.70+.

Running tests in capabilities
========================================
case: step_after_suspend_test
definition: 1_kselftest
result: skip
[OK] Capabilities after execve were correct
[OK] Capabilities after execve were correct
[OK] Capabilities after execve were correct
[OK] Capabilities after execve were correct
[OK] Capabilities after execve were correct
[OK] Capabilities after execve were correct
[OK] Capabilities after execve were correct
[OK] Capabilities after execve were correct
[RUN] +++ Tests with uid == 0 +++
[NOTE] Using global UIDs for tests
[RUN] Root => ep
[OK] Child succeeded
[OK] Check cap_ambient manipulation rules
[OK] PR_CAP_AMBIENT_RAISE failed on non-inheritable cap
[OK] PR_CAP_AMBIENT_RAISE failed on non-permitted cap
[OK] PR_CAP_AMBIENT_RAISE worked
[OK] Basic manipulation appears to work
[RUN] Root +i => eip
[OK] Child succeeded
[RUN] UID 0 +ia => eipa
[OK] Child succeeded
[RUN] Root +ia, suidroot => eipa
[OK] Child succeeded
[RUN] Root +ia, suidnonroot => ip
[OK] Child succeeded
[RUN] Root +ia, sgidroot => eipa
[OK] Child succeeded
[OK] Child succeeded
[RUN] Root +ia, sgidnonroot => eip
[OK] Child succeeded
[OK] Capabilities after execve were correct
[OK] Capabilities after execve were correct
[OK] Capabilities after execve were correct
[OK] Capabilities after execve were correct
[OK] Child succeeded
[OK] Child succeeded
selftests: test_execve [PASS]

Thanks and best regards,
Naresh Kamboju

[toc] | [next] | [standalone]

#1675911 — Re: selftests/capabilities: test FAIL on linux mainline and linux-next and PASS on linux-4.4.70+

FromGreg KH <greg@kroah.com>
Date2017-06-27 17:40 +0200
SubjectRe: selftests/capabilities: test FAIL on linux mainline and linux-next and PASS on linux-4.4.70+
Message-ID<tX0KS-2rx-23@gated-at.bofh.it>
In reply to#1675421
On Tue, Jun 27, 2017 at 02:10:32PM +0530, Naresh Kamboju wrote:
> selftest capabilities test failed on linux mainline and linux-next and
> PASS on linux-4.4.70+

Odd.  Any chance you can use 'git bisect' to track down the offending
commit?

Does this also fail on x86 or any other platform you have available?
Let me go try this on my laptop...

thanks,

greg k-h

[toc] | [prev] | [next] | [standalone]

#1675914 — Re: selftests/capabilities: test FAIL on linux mainline and linux-next and PASS on linux-4.4.70+

FromGreg KH <greg@kroah.com>
Date2017-06-27 17:40 +0200
SubjectRe: selftests/capabilities: test FAIL on linux mainline and linux-next and PASS on linux-4.4.70+
Message-ID<tX0KS-2rx-27@gated-at.bofh.it>
In reply to#1675911
On Tue, Jun 27, 2017 at 05:13:59PM +0200, Greg KH wrote:
> On Tue, Jun 27, 2017 at 02:10:32PM +0530, Naresh Kamboju wrote:
> > selftest capabilities test failed on linux mainline and linux-next and
> > PASS on linux-4.4.70+
> 
> Odd.  Any chance you can use 'git bisect' to track down the offending
> commit?
> 
> Does this also fail on x86 or any other platform you have available?
> Let me go try this on my laptop...

Ok, Linus's current tree (4.12.0-rc7+) also fails on this.  I'm guessing
it's failing, it's hard to understand the output.  If only we had TAP
output for this test :)

[RUN]   +++ Tests with uid == 0 +++
[NOTE]  Using global UIDs for tests
[RUN]   Root => ep
[OK]    Capabilities after execve were correct
[OK]    Child succeeded
[OK]    Check cap_ambient manipulation rules
[OK]    PR_CAP_AMBIENT_RAISE failed on non-inheritable cap
[OK]    PR_CAP_AMBIENT_RAISE failed on non-permitted cap
[OK]    PR_CAP_AMBIENT_RAISE worked
[OK]    Basic manipulation appears to work
[RUN]   Root +i => eip
[OK]    Capabilities after execve were correct
[OK]    Child succeeded
[RUN]   UID 0 +ia => eipa
[OK]    Capabilities after execve were correct
[OK]    Child succeeded
[RUN]   Root +ia, suidroot => eipa
[OK]    Capabilities after execve were correct
[OK]    Child succeeded
[RUN]   Root +ia, suidnonroot => ip
[FAIL]  Wrong effective state (AT_SECURE is not set)
[FAIL]  Child failed
[RUN]   Root +ia, sgidroot => eipa
[OK]    Capabilities after execve were correct
[OK]    Child succeeded
[RUN]   Root, gid != 0, +ia, sgidroot => eip
[FAIL]  Wrong ambient state (AT_SECURE is not set)
[FAIL]  Child failed
[RUN]   Root +ia, sgidnonroot => eip
[FAIL]  Wrong ambient state (AT_SECURE is not set)
[FAIL]  Child failed
[FAIL]  Child failed
[RUN]   +++ Tests with uid != 0 +++
[NOTE]  Using global UIDs for tests
[RUN]   Non-root => no caps
[OK]    Capabilities after execve were correct
[OK]    Child succeeded
[OK]    Check cap_ambient manipulation rules
[OK]    PR_CAP_AMBIENT_RAISE failed on non-inheritable cap
[OK]    PR_CAP_AMBIENT_RAISE failed on non-permitted cap
[OK]    PR_CAP_AMBIENT_RAISE worked
[OK]    Basic manipulation appears to work
[RUN]   Non-root +i => i
[OK]    Capabilities after execve were correct
[OK]    Child succeeded
[RUN]   UID 1 +ia => eipa
[OK]    Capabilities after execve were correct
[OK]    Child succeeded
[RUN]   Non-root +ia, sgidnonroot => i
[FAIL]  Wrong effective state (AT_SECURE is not set)
[FAIL]  Child failed

[toc] | [prev] | [next] | [standalone]

#1676255 — Re: selftests/capabilities: test FAIL on linux mainline and linux-next and PASS on linux-4.4.70+

FromShuah Khan <shuahkh@osg.samsung.com>
Date2017-06-28 01:20 +0200
SubjectRe: selftests/capabilities: test FAIL on linux mainline and linux-next and PASS on linux-4.4.70+
Message-ID<tX7W2-7nm-11@gated-at.bofh.it>
In reply to#1675914
On 06/27/2017 09:16 AM, Greg KH wrote:
> On Tue, Jun 27, 2017 at 05:13:59PM +0200, Greg KH wrote:
>> On Tue, Jun 27, 2017 at 02:10:32PM +0530, Naresh Kamboju wrote:
>>> selftest capabilities test failed on linux mainline and linux-next and
>>> PASS on linux-4.4.70+
>>
>> Odd.  Any chance you can use 'git bisect' to track down the offending
>> commit?
>>
>> Does this also fail on x86 or any other platform you have available?
>> Let me go try this on my laptop...
> 
> Ok, Linus's current tree (4.12.0-rc7+) also fails on this.  I'm guessing
> it's failing, it's hard to understand the output.  If only we had TAP
> output for this test :)

As far as the output, it isn't bad. Not TAP13 will help make it better.
The problem seems to with the individual messages error/info. messages
themselves. This test has the quality of a developer unit test and the
messages could be improved for non-developer use.

I ran the test on 4.11.8-rc1+ and 4.9.35-rc1 see the same failure.
It would be difficult to bisect this since it spans multiple releases.
I am hoping Andy can give us some insight.

[RUN]	+++ Tests with uid == 0 +++
[NOTE]	Using global UIDs for tests
[RUN]	Root => ep
[OK]	Capabilities after execve were correct
[OK]	Child succeeded
[OK]	Check cap_ambient manipulation rules
[OK]	PR_CAP_AMBIENT_RAISE failed on non-inheritable cap
[OK]	PR_CAP_AMBIENT_RAISE failed on non-permitted cap
[OK]	PR_CAP_AMBIENT_RAISE worked
[OK]	Basic manipulation appears to work
[RUN]	Root +i => eip
[OK]	Capabilities after execve were correct
[OK]	Child succeeded
[RUN]	UID 0 +ia => eipa
[OK]	Capabilities after execve were correct
[OK]	Child succeeded
[RUN]	Root +ia, suidroot => eipa
[OK]	Capabilities after execve were correct
[OK]	Child succeeded
[RUN]	Root +ia, suidnonroot => ip
[FAIL]	Wrong effective state (AT_SECURE is not set)
[FAIL]	Child failed
[RUN]	Root +ia, sgidroot => eipa
[OK]	Capabilities after execve were correct
[OK]	Child succeeded
[RUN]	Root, gid != 0, +ia, sgidroot => eip
[FAIL]	Wrong ambient state (AT_SECURE is not set)
[FAIL]	Child failed
[RUN]	Root +ia, sgidnonroot => eip
[FAIL]	Wrong ambient state (AT_SECURE is not set)
[FAIL]	Child failed
[FAIL]	Child failed
[RUN]	+++ Tests with uid != 0 +++
[NOTE]	Using global UIDs for tests
[RUN]	Non-root => no caps
[OK]	Capabilities after execve were correct
[OK]	Child succeeded
[OK]	Check cap_ambient manipulation rules
[OK]	PR_CAP_AMBIENT_RAISE failed on non-inheritable cap
[OK]	PR_CAP_AMBIENT_RAISE failed on non-permitted cap
[OK]	PR_CAP_AMBIENT_RAISE worked
[OK]	Basic manipulation appears to work
[RUN]	Non-root +i => i
[OK]	Capabilities after execve were correct
[OK]	Child succeeded
[RUN]	UID 1 +ia => eipa
[OK]	Capabilities after execve were correct
[OK]	Child succeeded
[RUN]	Non-root +ia, sgidnonroot => i
[FAIL]	Wrong effective state (AT_SECURE is not set)
[FAIL]	Child failed

thanks,
-- Shuah

[toc] | [prev] | [next] | [standalone]

#1676362 — Re: selftests/capabilities: test FAIL on linux mainline and linux-next and PASS on linux-4.4.70+

FromKees Cook <keescook@chromium.org>
Date2017-06-28 06:40 +0200
SubjectRe: selftests/capabilities: test FAIL on linux mainline and linux-next and PASS on linux-4.4.70+
Message-ID<tXcVH-27M-3@gated-at.bofh.it>
In reply to#1676255
On Tue, Jun 27, 2017 at 4:16 PM, Shuah Khan <shuahkh@osg.samsung.com> wrote:
> On 06/27/2017 09:16 AM, Greg KH wrote:
>> On Tue, Jun 27, 2017 at 05:13:59PM +0200, Greg KH wrote:
>>> On Tue, Jun 27, 2017 at 02:10:32PM +0530, Naresh Kamboju wrote:
>>>> selftest capabilities test failed on linux mainline and linux-next and
>>>> PASS on linux-4.4.70+
>>>
>>> Odd.  Any chance you can use 'git bisect' to track down the offending
>>> commit?
>>>
>>> Does this also fail on x86 or any other platform you have available?
>>> Let me go try this on my laptop...
>>
>> Ok, Linus's current tree (4.12.0-rc7+) also fails on this.  I'm guessing
>> it's failing, it's hard to understand the output.  If only we had TAP
>> output for this test :)
>
> As far as the output, it isn't bad. Not TAP13 will help make it better.
> The problem seems to with the individual messages error/info. messages
> themselves. This test has the quality of a developer unit test and the
> messages could be improved for non-developer use.
>
> I ran the test on 4.11.8-rc1+ and 4.9.35-rc1 see the same failure.
> It would be difficult to bisect this since it spans multiple releases.
> I am hoping Andy can give us some insight.

I bisected this to:

commit 380cf5ba6b0a0b307f4afb62b186ca801defb203
Author: Andy Lutomirski <luto@amacapital.net>
Date:   Thu Jun 23 16:41:05 2016 -0500

    fs: Treat foreign mounts as nosuid

I assume the test needs updating, but I bet Andy knows for sure. I can
look into this more closely in the morning.

-Kees

-- 
Kees Cook
Pixel Security

[toc] | [prev] | [next] | [standalone]

#1677189 — Re: selftests/capabilities: test FAIL on linux mainline and linux-next and PASS on linux-4.4.70+

FromAndy Lutomirski <luto@kernel.org>
Date2017-06-28 23:30 +0200
SubjectRe: selftests/capabilities: test FAIL on linux mainline and linux-next and PASS on linux-4.4.70+
Message-ID<tXsH8-rB-19@gated-at.bofh.it>
In reply to#1676362
On Tue, Jun 27, 2017 at 9:35 PM, Kees Cook <keescook@chromium.org> wrote:
> On Tue, Jun 27, 2017 at 4:16 PM, Shuah Khan <shuahkh@osg.samsung.com> wrote:
>> On 06/27/2017 09:16 AM, Greg KH wrote:
>>> On Tue, Jun 27, 2017 at 05:13:59PM +0200, Greg KH wrote:
>>>> On Tue, Jun 27, 2017 at 02:10:32PM +0530, Naresh Kamboju wrote:
>>>>> selftest capabilities test failed on linux mainline and linux-next and
>>>>> PASS on linux-4.4.70+
>>>>
>>>> Odd.  Any chance you can use 'git bisect' to track down the offending
>>>> commit?
>>>>
>>>> Does this also fail on x86 or any other platform you have available?
>>>> Let me go try this on my laptop...
>>>
>>> Ok, Linus's current tree (4.12.0-rc7+) also fails on this.  I'm guessing
>>> it's failing, it's hard to understand the output.  If only we had TAP
>>> output for this test :)
>>
>> As far as the output, it isn't bad. Not TAP13 will help make it better.
>> The problem seems to with the individual messages error/info. messages
>> themselves. This test has the quality of a developer unit test and the
>> messages could be improved for non-developer use.
>>
>> I ran the test on 4.11.8-rc1+ and 4.9.35-rc1 see the same failure.
>> It would be difficult to bisect this since it spans multiple releases.
>> I am hoping Andy can give us some insight.
>
> I bisected this to:
>
> commit 380cf5ba6b0a0b307f4afb62b186ca801defb203
> Author: Andy Lutomirski <luto@amacapital.net>
> Date:   Thu Jun 23 16:41:05 2016 -0500
>
>     fs: Treat foreign mounts as nosuid
>
> I assume the test needs updating, but I bet Andy knows for sure. I can
> look into this more closely in the morning.

Hi Eric-

This is rather odd.  The selftest
(tools/testing/selftests/capabilities/test_execve), run as root, fails
on current kernels.  The failure is worked around by this:

diff --git a/tools/testing/selftests/capabilities/test_execve.c
b/tools/testing/selftests/capabilities/test_execve.c
index 10a21a958aaf..6db60889b211 100644
--- a/tools/testing/selftests/capabilities/test_execve.c
+++ b/tools/testing/selftests/capabilities/test_execve.c
@@ -139,8 +139,8 @@ static void chdir_to_tmpfs(void)
        if (chdir(cwd) != 0)
                err(1, "chdir to private tmpfs");

-       if (umount2(".", MNT_DETACH) != 0)
-               err(1, "detach private tmpfs");
+//     if (umount2(".", MNT_DETACH) != 0)
+//             err(1, "detach private tmpfs");
 }

 static void copy_fromat_to(int fromfd, const char *fromname, const
char *toname)

I think this is due to the line:

p->mnt_ns = NULL;

in umount_tree().  The test is putting us into a situation in which
our cwd has ->mnt_ns = NULL, which is making it act as if it's nosuid.
I can imagine this breaking some weird user code (like my test!).  Is
it a real problem, though?

[toc] | [prev] | [next] | [standalone]

#1677787 — Re: selftests/capabilities: test FAIL on linux mainline and linux-next and PASS on linux-4.4.70+

Fromebiederm@xmission.com (Eric W. Biederman)
Date2017-06-29 16:20 +0200
SubjectRe: selftests/capabilities: test FAIL on linux mainline and linux-next and PASS on linux-4.4.70+
Message-ID<tXIsx-bi-3@gated-at.bofh.it>
In reply to#1677189
Andy Lutomirski <luto@kernel.org> writes:

> On Tue, Jun 27, 2017 at 9:35 PM, Kees Cook <keescook@chromium.org> wrote:
>> On Tue, Jun 27, 2017 at 4:16 PM, Shuah Khan <shuahkh@osg.samsung.com> wrote:
>>> On 06/27/2017 09:16 AM, Greg KH wrote:
>>>> On Tue, Jun 27, 2017 at 05:13:59PM +0200, Greg KH wrote:
>>>>> On Tue, Jun 27, 2017 at 02:10:32PM +0530, Naresh Kamboju wrote:
>>>>>> selftest capabilities test failed on linux mainline and linux-next and
>>>>>> PASS on linux-4.4.70+
>>>>>
>>>>> Odd.  Any chance you can use 'git bisect' to track down the offending
>>>>> commit?
>>>>>
>>>>> Does this also fail on x86 or any other platform you have available?
>>>>> Let me go try this on my laptop...
>>>>
>>>> Ok, Linus's current tree (4.12.0-rc7+) also fails on this.  I'm guessing
>>>> it's failing, it's hard to understand the output.  If only we had TAP
>>>> output for this test :)
>>>
>>> As far as the output, it isn't bad. Not TAP13 will help make it better.
>>> The problem seems to with the individual messages error/info. messages
>>> themselves. This test has the quality of a developer unit test and the
>>> messages could be improved for non-developer use.
>>>
>>> I ran the test on 4.11.8-rc1+ and 4.9.35-rc1 see the same failure.
>>> It would be difficult to bisect this since it spans multiple releases.
>>> I am hoping Andy can give us some insight.
>>
>> I bisected this to:
>>
>> commit 380cf5ba6b0a0b307f4afb62b186ca801defb203
>> Author: Andy Lutomirski <luto@amacapital.net>
>> Date:   Thu Jun 23 16:41:05 2016 -0500
>>
>>     fs: Treat foreign mounts as nosuid
>>
>> I assume the test needs updating, but I bet Andy knows for sure. I can
>> look into this more closely in the morning.
>
> Hi Eric-
>
> This is rather odd.  The selftest
> (tools/testing/selftests/capabilities/test_execve), run as root, fails
> on current kernels.  The failure is worked around by this:
>
> diff --git a/tools/testing/selftests/capabilities/test_execve.c
> b/tools/testing/selftests/capabilities/test_execve.c
> index 10a21a958aaf..6db60889b211 100644
> --- a/tools/testing/selftests/capabilities/test_execve.c
> +++ b/tools/testing/selftests/capabilities/test_execve.c
> @@ -139,8 +139,8 @@ static void chdir_to_tmpfs(void)
>         if (chdir(cwd) != 0)
>                 err(1, "chdir to private tmpfs");
>
> -       if (umount2(".", MNT_DETACH) != 0)
> -               err(1, "detach private tmpfs");
> +//     if (umount2(".", MNT_DETACH) != 0)
> +//             err(1, "detach private tmpfs");
>  }
>
>  static void copy_fromat_to(int fromfd, const char *fromname, const
> char *toname)
>
> I think this is due to the line:
>
> p->mnt_ns = NULL;
>
> in umount_tree().  The test is putting us into a situation in which
> our cwd has ->mnt_ns = NULL, which is making it act as if it's nosuid.
> I can imagine this breaking some weird user code (like my test!).  Is
> it a real problem, though?

That umount2(".", MNT_DETACH) creates a poor mans mount namespace in a
mount namespace.

I don't see why you would ever want to do that deliberately we have
mount namespaces.

Beyond that that is a very weird half cleaned up state.  We very
deliberately limit what you can do in that state.  It exists until all
of the references to the mounts are cleaned up.

I think it is very reasonable that we don't allow exec'ing a new
executable on an unmounted filesystem.  That could lead to all kinds of
non-sense.  I am not clever enough but I can imagine there might be an
attack on a suid executable in there somewhere.  Certainly we are
violating ordinary expectations of the starting condition of an
executable.  (AKA not living anywhere reachable with a path).

So even if this breaks userspace we have legitimate security reasons for
doing so in this case.

Eric

[toc] | [prev] | [next] | [standalone]

#1677819 — Re: selftests/capabilities: test FAIL on linux mainline and linux-next and PASS on linux-4.4.70+

Fromebiederm@xmission.com (Eric W. Biederman)
Date2017-06-29 16:40 +0200
SubjectRe: selftests/capabilities: test FAIL on linux mainline and linux-next and PASS on linux-4.4.70+
Message-ID<tXILT-ia-3@gated-at.bofh.it>
In reply to#1677787
ebiederm@xmission.com (Eric W. Biederman) writes:

> Andy Lutomirski <luto@kernel.org> writes:
>>
>> Hi Eric-
>>
>> This is rather odd.  The selftest
>> (tools/testing/selftests/capabilities/test_execve), run as root, fails
>> on current kernels.  The failure is worked around by this:
>>
>> diff --git a/tools/testing/selftests/capabilities/test_execve.c
>> b/tools/testing/selftests/capabilities/test_execve.c
>> index 10a21a958aaf..6db60889b211 100644
>> --- a/tools/testing/selftests/capabilities/test_execve.c
>> +++ b/tools/testing/selftests/capabilities/test_execve.c
>> @@ -139,8 +139,8 @@ static void chdir_to_tmpfs(void)
>>         if (chdir(cwd) != 0)
>>                 err(1, "chdir to private tmpfs");
>>
>> -       if (umount2(".", MNT_DETACH) != 0)
>> -               err(1, "detach private tmpfs");
>> +//     if (umount2(".", MNT_DETACH) != 0)
>> +//             err(1, "detach private tmpfs");
>>  }
>>
>>  static void copy_fromat_to(int fromfd, const char *fromname, const
>> char *toname)
>>
>> I think this is due to the line:
>>
>> p->mnt_ns = NULL;
>>
>> in umount_tree().  The test is putting us into a situation in which
>> our cwd has ->mnt_ns = NULL, which is making it act as if it's nosuid.
>> I can imagine this breaking some weird user code (like my test!).  Is
>> it a real problem, though?

I just wanted to follow up and say this the mnt_may_suid test appears
to be doing exactly what it was designed to do.

It's goal is not to allow a suid exec from another mount namespace and
in this test the umount2(".", MNT_DETACH) creates a poor man's mount
namespace.

So assuming that we want to not allow execing executables from other
mount namespaces the behavior appears to be exactly correct in this
case.

Eric

[toc] | [prev] | [next] | [standalone]

#1677883 — Re: selftests/capabilities: test FAIL on linux mainline and linux-next and PASS on linux-4.4.70+

FromAndy Lutomirski <luto@kernel.org>
Date2017-06-29 17:50 +0200
SubjectRe: selftests/capabilities: test FAIL on linux mainline and linux-next and PASS on linux-4.4.70+
Message-ID<tXJRE-XD-27@gated-at.bofh.it>
In reply to#1677819
On Thu, Jun 29, 2017 at 7:23 AM, Eric W. Biederman
<ebiederm@xmission.com> wrote:
> ebiederm@xmission.com (Eric W. Biederman) writes:
>
>> Andy Lutomirski <luto@kernel.org> writes:
>>>
>>> Hi Eric-
>>>
>>> This is rather odd.  The selftest
>>> (tools/testing/selftests/capabilities/test_execve), run as root, fails
>>> on current kernels.  The failure is worked around by this:
>>>
>>> diff --git a/tools/testing/selftests/capabilities/test_execve.c
>>> b/tools/testing/selftests/capabilities/test_execve.c
>>> index 10a21a958aaf..6db60889b211 100644
>>> --- a/tools/testing/selftests/capabilities/test_execve.c
>>> +++ b/tools/testing/selftests/capabilities/test_execve.c
>>> @@ -139,8 +139,8 @@ static void chdir_to_tmpfs(void)
>>>         if (chdir(cwd) != 0)
>>>                 err(1, "chdir to private tmpfs");
>>>
>>> -       if (umount2(".", MNT_DETACH) != 0)
>>> -               err(1, "detach private tmpfs");
>>> +//     if (umount2(".", MNT_DETACH) != 0)
>>> +//             err(1, "detach private tmpfs");
>>>  }
>>>
>>>  static void copy_fromat_to(int fromfd, const char *fromname, const
>>> char *toname)
>>>
>>> I think this is due to the line:
>>>
>>> p->mnt_ns = NULL;
>>>
>>> in umount_tree().  The test is putting us into a situation in which
>>> our cwd has ->mnt_ns = NULL, which is making it act as if it's nosuid.
>>> I can imagine this breaking some weird user code (like my test!).  Is
>>> it a real problem, though?
>
> I just wanted to follow up and say this the mnt_may_suid test appears
> to be doing exactly what it was designed to do.
>
> It's goal is not to allow a suid exec from another mount namespace and
> in this test the umount2(".", MNT_DETACH) creates a poor man's mount
> namespace.
>
> So assuming that we want to not allow execing executables from other
> mount namespaces the behavior appears to be exactly correct in this
> case.

Fair enough.  Given that the only known failure is my really wonky
test case, I'll just fix my test.

That being said, I do know of production code that uses MNT_DETACH:
Sandstorm.  It mounts a tmpfs, opens an fd to it, and MNT_DETACHes it.
That gives it a directory that can't be seen by its children.  Using
mount namespaces for this would be awkward.  Admittedly, MNT_DETACH is
a bit of an awful way to do this -- what it really wants is the
ability to set up a mount tree that logically belongs to its mount
namespace but isn't bound anywhere.  A couple years ago, we talked
about adding an API for more or less that: first create a filesystem
(i.e. superblock) and then bind it in if you want it bound.

But Sandstorm still works, so this isn't a big deal.

--Andy

[toc] | [prev] | [next] | [standalone]

#1677933 — Re: selftests/capabilities: test FAIL on linux mainline and linux-next and PASS on linux-4.4.70+

Fromebiederm@xmission.com (Eric W. Biederman)
Date2017-06-29 18:40 +0200
SubjectRe: selftests/capabilities: test FAIL on linux mainline and linux-next and PASS on linux-4.4.70+
Message-ID<tXKE2-1tl-13@gated-at.bofh.it>
In reply to#1677883
Andy Lutomirski <luto@kernel.org> writes:

> On Thu, Jun 29, 2017 at 7:23 AM, Eric W. Biederman
> <ebiederm@xmission.com> wrote:
>> ebiederm@xmission.com (Eric W. Biederman) writes:
>>
>>> Andy Lutomirski <luto@kernel.org> writes:
>>>>
>>>> Hi Eric-
>>>>
>>>> This is rather odd.  The selftest
>>>> (tools/testing/selftests/capabilities/test_execve), run as root, fails
>>>> on current kernels.  The failure is worked around by this:
>>>>
>>>> diff --git a/tools/testing/selftests/capabilities/test_execve.c
>>>> b/tools/testing/selftests/capabilities/test_execve.c
>>>> index 10a21a958aaf..6db60889b211 100644
>>>> --- a/tools/testing/selftests/capabilities/test_execve.c
>>>> +++ b/tools/testing/selftests/capabilities/test_execve.c
>>>> @@ -139,8 +139,8 @@ static void chdir_to_tmpfs(void)
>>>>         if (chdir(cwd) != 0)
>>>>                 err(1, "chdir to private tmpfs");
>>>>
>>>> -       if (umount2(".", MNT_DETACH) != 0)
>>>> -               err(1, "detach private tmpfs");
>>>> +//     if (umount2(".", MNT_DETACH) != 0)
>>>> +//             err(1, "detach private tmpfs");
>>>>  }
>>>>
>>>>  static void copy_fromat_to(int fromfd, const char *fromname, const
>>>> char *toname)
>>>>
>>>> I think this is due to the line:
>>>>
>>>> p->mnt_ns = NULL;
>>>>
>>>> in umount_tree().  The test is putting us into a situation in which
>>>> our cwd has ->mnt_ns = NULL, which is making it act as if it's nosuid.
>>>> I can imagine this breaking some weird user code (like my test!).  Is
>>>> it a real problem, though?
>>
>> I just wanted to follow up and say this the mnt_may_suid test appears
>> to be doing exactly what it was designed to do.
>>
>> It's goal is not to allow a suid exec from another mount namespace and
>> in this test the umount2(".", MNT_DETACH) creates a poor man's mount
>> namespace.
>>
>> So assuming that we want to not allow execing executables from other
>> mount namespaces the behavior appears to be exactly correct in this
>> case.
>
> Fair enough.  Given that the only known failure is my really wonky
> test case, I'll just fix my test.
>
> That being said, I do know of production code that uses MNT_DETACH:
> Sandstorm.  It mounts a tmpfs, opens an fd to it, and MNT_DETACHes it.
> That gives it a directory that can't be seen by its children.  Using
> mount namespaces for this would be awkward.  Admittedly, MNT_DETACH is
> a bit of an awful way to do this -- what it really wants is the
> ability to set up a mount tree that logically belongs to its mount
> namespace but isn't bound anywhere.  A couple years ago, we talked
> about adding an API for more or less that: first create a filesystem
> (i.e. superblock) and then bind it in if you want it bound.
>
> But Sandstorm still works, so this isn't a big deal.

If it proved desirable I think we could remove the check_mnt test in
mnt_may_suid.  I believe the current_in_userns check actually handles
the namespace confusion case.

At the same time using check_mnt does make it easier to think about
these things.  Which if it doesn't limit us in the real world is a plus.

Eric

[toc] | [prev] | [next] | [standalone]

#1675912 — Re: selftests/capabilities: test FAIL on linux mainline and linux-next and PASS on linux-4.4.70+

FromShuah Khan <shuahkh@osg.samsung.com>
Date2017-06-27 17:40 +0200
SubjectRe: selftests/capabilities: test FAIL on linux mainline and linux-next and PASS on linux-4.4.70+
Message-ID<tX0KS-2rx-19@gated-at.bofh.it>
In reply to#1675421
Hi Naresh,

On 06/27/2017 02:40 AM, Naresh Kamboju wrote:
> selftest capabilities test failed on linux mainline and linux-next and
> PASS on linux-4.4.70+
> Tested on HiKey ARM64 Development board.
> 
> A bug reported in Linaro bug tracking system,
> LKFT: Capabilities test_execve fail Wrong effective state AT_SECURE is not set
> https://bugs.linaro.org/show_bug.cgi?id=2947
> 
> Please guide me to debug the reason for failure.
> Kernel config link,
> https://pastebin.com/P1uYmdMG
> 
> Linux version 4.12.0-rc7-00004-gda8b14e (buildslave@x86-64-08) (gcc
> version 6.2.1 20161016 (Linaro GCC 6.2-2016.11) ) #1 SMP PREEMPT Mon
> Jun 26 20:04:35 UTC 2017
> 
> Linux version 4.12.0-rc7-next-20170627 (buildslave@x86-64-07) (gcc
> version 6.2.1 20161016 (Linaro GCC 6.2-2016.11)) #1 SMP PREEMPT Tue
> Jun 27 06:33:39 UTC 2017
> 
> LAVA job id:
> https://lkft.validation.linaro.org/scheduler/job/4397#L1412
> 
> Running tests in capabilities
> ========================================
> [OK] Capabilities after execve were correct
> [OK] Capabilities after execve were correct
> [OK] Capabilities after execve were correct
> [OK] Capabilities after execve were correct
> [FAIL] Wrong effective state (AT_SECURE is not set)
> [OK] Capabilities after execve were correct
> [FAIL] Wrong ambient state (AT_SECURE is not set)
> [FAIL] Wrong ambient state (AT_SECURE is not set)
> [RUN] +++ Tests with uid == 0 +++
> [NOTE] Using global UIDs for tests
> [RUN] Root => ep
> [OK] Child succeeded
> [OK] Check cap_ambient manipulation rules
> [OK] PR_CAP_AMBIENT_RAISE failed on non-inheritable cap
> [OK] PR_CAP_AMBIENT_RAISE failed on non-permitted cap
> [OK] PR_CAP_AMBIENT_RAISE worked
> [OK] Basic manipulation appears to work
> [RUN] Root +i => eip
> [OK] Child succeeded
> [RUN] UID 0 +ia => eipa
> [OK] Child succeeded
> [RUN] Root +ia, suidroot => eipa
> [OK] Child succeeded

Okay the following appears to be the first difference
between the runs on the mainline and 4.4.74

When udi != 0 case, these tests fail. Could it be that
there are security related changes to this area and the
tests need updates?

Kees/Andy: Do you have any insight

thanks,
-- Shuah

------------------------------------
> [RUN] Root +ia, suidnonroot => ip
> [FAIL] Child failed
> [RUN] Root +ia, sgidroot => eipa
> [OK] Child succeeded
> [FAIL] Child failed
> [RUN] Root +ia, sgidnonroot => eip
> [FAIL] Child failed
-------------------------------------

> [OK] Capabilities after execve were correct
> [OK] Capabilities after execve were correct
> [OK] Capabilities after execve were correct
> [FAIL] Wrong effective state (AT_SECURE is not set)
> [FAIL] Child failed
> [FAIL] Child failed
> selftests: test_execve [FAIL]
> 
> capabilities test PASS on Linux-4.4.70+.
> 
> Running tests in capabilities
> ========================================
> case: step_after_suspend_test
> definition: 1_kselftest
> result: skip
> [OK] Capabilities after execve were correct
> [OK] Capabilities after execve were correct
> [OK] Capabilities after execve were correct
> [OK] Capabilities after execve were correct
> [OK] Capabilities after execve were correct
> [OK] Capabilities after execve were correct
> [OK] Capabilities after execve were correct
> [OK] Capabilities after execve were correct
> [RUN] +++ Tests with uid == 0 +++
> [NOTE] Using global UIDs for tests
> [RUN] Root => ep
> [OK] Child succeeded
> [OK] Check cap_ambient manipulation rules
> [OK] PR_CAP_AMBIENT_RAISE failed on non-inheritable cap
> [OK] PR_CAP_AMBIENT_RAISE failed on non-permitted cap
> [OK] PR_CAP_AMBIENT_RAISE worked
> [OK] Basic manipulation appears to work
> [RUN] Root +i => eip
> [OK] Child succeeded
> [RUN] UID 0 +ia => eipa
> [OK] Child succeeded
> [RUN] Root +ia, suidroot => eipa
> [OK] Child succeeded
> [RUN] Root +ia, suidnonroot => ip
> [OK] Child succeeded
> [RUN] Root +ia, sgidroot => eipa
> [OK] Child succeeded
> [OK] Child succeeded
> [RUN] Root +ia, sgidnonroot => eip
> [OK] Child succeeded
> [OK] Capabilities after execve were correct
> [OK] Capabilities after execve were correct
> [OK] Capabilities after execve were correct
> [OK] Capabilities after execve were correct
> [OK] Child succeeded
> [OK] Child succeeded
> selftests: test_execve [PASS]
> 
> Thanks and best regards,
> Naresh Kamboju
>

[toc] | [prev] | [next] | [standalone]

#1675936 — Re: selftests/capabilities: test FAIL on linux mainline and linux-next and PASS on linux-4.4.70+

FromShuah Khan <shuahkh@osg.samsung.com>
Date2017-06-27 17:50 +0200
SubjectRe: selftests/capabilities: test FAIL on linux mainline and linux-next and PASS on linux-4.4.70+
Message-ID<tX0Uy-2xM-41@gated-at.bofh.it>
In reply to#1675912
On 06/27/2017 09:32 AM, Shuah Khan wrote:
> Hi Naresh,
> 
> On 06/27/2017 02:40 AM, Naresh Kamboju wrote:
>> selftest capabilities test failed on linux mainline and linux-next and
>> PASS on linux-4.4.70+
>> Tested on HiKey ARM64 Development board.
>>
>> A bug reported in Linaro bug tracking system,
>> LKFT: Capabilities test_execve fail Wrong effective state AT_SECURE is not set
>> https://bugs.linaro.org/show_bug.cgi?id=2947
>>
>> Please guide me to debug the reason for failure.
>> Kernel config link,
>> https://pastebin.com/P1uYmdMG
>>
>> Linux version 4.12.0-rc7-00004-gda8b14e (buildslave@x86-64-08) (gcc
>> version 6.2.1 20161016 (Linaro GCC 6.2-2016.11) ) #1 SMP PREEMPT Mon
>> Jun 26 20:04:35 UTC 2017
>>
>> Linux version 4.12.0-rc7-next-20170627 (buildslave@x86-64-07) (gcc
>> version 6.2.1 20161016 (Linaro GCC 6.2-2016.11)) #1 SMP PREEMPT Tue
>> Jun 27 06:33:39 UTC 2017
>>
>> LAVA job id:
>> https://lkft.validation.linaro.org/scheduler/job/4397#L1412
>>
>> Running tests in capabilities
>> ========================================
>> [OK] Capabilities after execve were correct
>> [OK] Capabilities after execve were correct
>> [OK] Capabilities after execve were correct
>> [OK] Capabilities after execve were correct
>> [FAIL] Wrong effective state (AT_SECURE is not set)
>> [OK] Capabilities after execve were correct
>> [FAIL] Wrong ambient state (AT_SECURE is not set)
>> [FAIL] Wrong ambient state (AT_SECURE is not set)
>> [RUN] +++ Tests with uid == 0 +++
>> [NOTE] Using global UIDs for tests
>> [RUN] Root => ep
>> [OK] Child succeeded
>> [OK] Check cap_ambient manipulation rules
>> [OK] PR_CAP_AMBIENT_RAISE failed on non-inheritable cap
>> [OK] PR_CAP_AMBIENT_RAISE failed on non-permitted cap
>> [OK] PR_CAP_AMBIENT_RAISE worked
>> [OK] Basic manipulation appears to work
>> [RUN] Root +i => eip
>> [OK] Child succeeded
>> [RUN] UID 0 +ia => eipa
>> [OK] Child succeeded
>> [RUN] Root +ia, suidroot => eipa
>> [OK] Child succeeded
> 
> Okay the following appears to be the first difference
> between the runs on the mainline and 4.4.74
> 
> When udi != 0 case, these tests fail. Could it be that
> there are security related changes to this area and the
> tests need updates?

uid is still 0!

> 
> Kees/Andy: Do you have any insight
> 

Sorry hit return too soon. There is no change to the test
itself. I wonder if this is new in mainline or the failure
occurs in 4.11 - I am building stables now, I will try the test
on 4.9 and 4.11 and see how it behaves and let you know

> 
> ------------------------------------
>> [RUN] Root +ia, suidnonroot => ip
>> [FAIL] Child failed
>> [RUN] Root +ia, sgidroot => eipa
>> [OK] Child succeeded
>> [FAIL] Child failed
>> [RUN] Root +ia, sgidnonroot => eip
>> [FAIL] Child failed
> -------------------------------------
> 
>> [OK] Capabilities after execve were correct
>> [OK] Capabilities after execve were correct
>> [OK] Capabilities after execve were correct
>> [FAIL] Wrong effective state (AT_SECURE is not set)
>> [FAIL] Child failed
>> [FAIL] Child failed
>> selftests: test_execve [FAIL]
>>
>> capabilities test PASS on Linux-4.4.70+.
>>
>> Running tests in capabilities
>> ========================================
>> case: step_after_suspend_test
>> definition: 1_kselftest
>> result: skip
>> [OK] Capabilities after execve were correct
>> [OK] Capabilities after execve were correct
>> [OK] Capabilities after execve were correct
>> [OK] Capabilities after execve were correct
>> [OK] Capabilities after execve were correct
>> [OK] Capabilities after execve were correct
>> [OK] Capabilities after execve were correct
>> [OK] Capabilities after execve were correct
>> [RUN] +++ Tests with uid == 0 +++
>> [NOTE] Using global UIDs for tests
>> [RUN] Root => ep
>> [OK] Child succeeded
>> [OK] Check cap_ambient manipulation rules
>> [OK] PR_CAP_AMBIENT_RAISE failed on non-inheritable cap
>> [OK] PR_CAP_AMBIENT_RAISE failed on non-permitted cap
>> [OK] PR_CAP_AMBIENT_RAISE worked
>> [OK] Basic manipulation appears to work
>> [RUN] Root +i => eip
>> [OK] Child succeeded
>> [RUN] UID 0 +ia => eipa
>> [OK] Child succeeded
>> [RUN] Root +ia, suidroot => eipa
>> [OK] Child succeeded
>> [RUN] Root +ia, suidnonroot => ip
>> [OK] Child succeeded
>> [RUN] Root +ia, sgidroot => eipa
>> [OK] Child succeeded
>> [OK] Child succeeded
>> [RUN] Root +ia, sgidnonroot => eip
>> [OK] Child succeeded
>> [OK] Capabilities after execve were correct
>> [OK] Capabilities after execve were correct
>> [OK] Capabilities after execve were correct
>> [OK] Capabilities after execve were correct
>> [OK] Child succeeded
>> [OK] Child succeeded
>> selftests: test_execve [PASS]
>>
>> Thanks and best regards,
>> Naresh Kamboju
>>
>

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web