* selftests/capabilities: test FAIL on linux mainline and linux-next and PASS on linux-4.4.70+ @ 2017-06-27 8:40 Naresh Kamboju 2017-06-27 15:13 ` Greg KH 2017-06-27 15:32 ` Shuah Khan 0 siblings, 2 replies; 13+ messages in thread From: Naresh Kamboju @ 2017-06-27 8:40 UTC (permalink / raw) To: luto, keescook; +Cc: Shuah Khan, linux-kselftest, linux-kernel 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: selftests/capabilities: test FAIL on linux mainline and linux-next and PASS on linux-4.4.70+ 2017-06-27 8:40 selftests/capabilities: test FAIL on linux mainline and linux-next and PASS on linux-4.4.70+ Naresh Kamboju @ 2017-06-27 15:13 ` Greg KH 2017-06-27 15:16 ` Greg KH 2017-06-27 15:32 ` Shuah Khan 1 sibling, 1 reply; 13+ messages in thread From: Greg KH @ 2017-06-27 15:13 UTC (permalink / raw) To: Naresh Kamboju; +Cc: luto, keescook, Shuah Khan, linux-kselftest, linux-kernel 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: selftests/capabilities: test FAIL on linux mainline and linux-next and PASS on linux-4.4.70+ 2017-06-27 15:13 ` Greg KH @ 2017-06-27 15:16 ` Greg KH 2017-06-27 15:48 ` Paul Elder 2017-06-27 23:16 ` Shuah Khan 0 siblings, 2 replies; 13+ messages in thread From: Greg KH @ 2017-06-27 15:16 UTC (permalink / raw) To: Naresh Kamboju; +Cc: luto, keescook, Shuah Khan, linux-kselftest, linux-kernel 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: selftests/capabilities: test FAIL on linux mainline and linux-next and PASS on linux-4.4.70+ 2017-06-27 15:16 ` Greg KH @ 2017-06-27 15:48 ` Paul Elder 2017-06-27 23:16 ` Shuah Khan 1 sibling, 0 replies; 13+ messages in thread From: Paul Elder @ 2017-06-27 15:48 UTC (permalink / raw) To: Greg KH, Naresh Kamboju Cc: luto, keescook, Shuah Khan, linux-kselftest, linux-kernel On 06/28/2017 12: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 :) I tried to take down this test as the next one to tapify but all the forking with exec_other_validate_cap("./validate_cap", eff, perm, inh, ambient) was throwing me and the test counter off. > [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 I'm on 4.9.0-3-amd64 (Debian distro kernel) running the test from linux-kselftest-next and I have the exact same output. Paul ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: selftests/capabilities: test FAIL on linux mainline and linux-next and PASS on linux-4.4.70+ 2017-06-27 15:16 ` Greg KH 2017-06-27 15:48 ` Paul Elder @ 2017-06-27 23:16 ` Shuah Khan 2017-06-28 4:35 ` Kees Cook 1 sibling, 1 reply; 13+ messages in thread From: Shuah Khan @ 2017-06-27 23:16 UTC (permalink / raw) To: Greg KH, Naresh Kamboju, luto Cc: keescook, linux-kselftest, linux-kernel, Shuah Khan, Shuah Khan 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: selftests/capabilities: test FAIL on linux mainline and linux-next and PASS on linux-4.4.70+ 2017-06-27 23:16 ` Shuah Khan @ 2017-06-28 4:35 ` Kees Cook 2017-06-28 21:21 ` Andy Lutomirski 0 siblings, 1 reply; 13+ messages in thread From: Kees Cook @ 2017-06-28 4:35 UTC (permalink / raw) To: Shuah Khan, Andy Lutomirski Cc: Greg KH, Naresh Kamboju, open list:KERNEL SELFTEST FRAMEWORK, linux-kernel, Shuah Khan 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: selftests/capabilities: test FAIL on linux mainline and linux-next and PASS on linux-4.4.70+ 2017-06-28 4:35 ` Kees Cook @ 2017-06-28 21:21 ` Andy Lutomirski 2017-06-29 14:02 ` Eric W. Biederman 0 siblings, 1 reply; 13+ messages in thread From: Andy Lutomirski @ 2017-06-28 21:21 UTC (permalink / raw) To: Kees Cook, Eric W. Biederman Cc: Shuah Khan, Andy Lutomirski, Greg KH, Naresh Kamboju, open list:KERNEL SELFTEST FRAMEWORK, linux-kernel, Shuah Khan 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? ^ permalink raw reply related [flat|nested] 13+ messages in thread
* Re: selftests/capabilities: test FAIL on linux mainline and linux-next and PASS on linux-4.4.70+ 2017-06-28 21:21 ` Andy Lutomirski @ 2017-06-29 14:02 ` Eric W. Biederman 2017-06-29 14:23 ` Eric W. Biederman 0 siblings, 1 reply; 13+ messages in thread From: Eric W. Biederman @ 2017-06-29 14:02 UTC (permalink / raw) To: Andy Lutomirski Cc: Kees Cook, Shuah Khan, Greg KH, Naresh Kamboju, open list:KERNEL SELFTEST FRAMEWORK, linux-kernel, Shuah Khan 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: selftests/capabilities: test FAIL on linux mainline and linux-next and PASS on linux-4.4.70+ 2017-06-29 14:02 ` Eric W. Biederman @ 2017-06-29 14:23 ` Eric W. Biederman 2017-06-29 15:39 ` Andy Lutomirski 0 siblings, 1 reply; 13+ messages in thread From: Eric W. Biederman @ 2017-06-29 14:23 UTC (permalink / raw) To: Andy Lutomirski Cc: Kees Cook, Shuah Khan, Greg KH, Naresh Kamboju, open list:KERNEL SELFTEST FRAMEWORK, linux-kernel, Shuah Khan 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: selftests/capabilities: test FAIL on linux mainline and linux-next and PASS on linux-4.4.70+ 2017-06-29 14:23 ` Eric W. Biederman @ 2017-06-29 15:39 ` Andy Lutomirski 2017-06-29 16:26 ` Eric W. Biederman 0 siblings, 1 reply; 13+ messages in thread From: Andy Lutomirski @ 2017-06-29 15:39 UTC (permalink / raw) To: Eric W. Biederman Cc: Andy Lutomirski, Kees Cook, Shuah Khan, Greg KH, Naresh Kamboju, open list:KERNEL SELFTEST FRAMEWORK, linux-kernel, Shuah Khan 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: selftests/capabilities: test FAIL on linux mainline and linux-next and PASS on linux-4.4.70+ 2017-06-29 15:39 ` Andy Lutomirski @ 2017-06-29 16:26 ` Eric W. Biederman 0 siblings, 0 replies; 13+ messages in thread From: Eric W. Biederman @ 2017-06-29 16:26 UTC (permalink / raw) To: Andy Lutomirski Cc: Kees Cook, Shuah Khan, Greg KH, Naresh Kamboju, open list:KERNEL SELFTEST FRAMEWORK, linux-kernel, Shuah Khan 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: selftests/capabilities: test FAIL on linux mainline and linux-next and PASS on linux-4.4.70+ 2017-06-27 8:40 selftests/capabilities: test FAIL on linux mainline and linux-next and PASS on linux-4.4.70+ Naresh Kamboju 2017-06-27 15:13 ` Greg KH @ 2017-06-27 15:32 ` Shuah Khan 2017-06-27 15:40 ` Shuah Khan 1 sibling, 1 reply; 13+ messages in thread From: Shuah Khan @ 2017-06-27 15:32 UTC (permalink / raw) To: Naresh Kamboju, luto, keescook Cc: linux-kselftest, linux-kernel, Shuah Khan, Shuah Khan 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 > ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: selftests/capabilities: test FAIL on linux mainline and linux-next and PASS on linux-4.4.70+ 2017-06-27 15:32 ` Shuah Khan @ 2017-06-27 15:40 ` Shuah Khan 0 siblings, 0 replies; 13+ messages in thread From: Shuah Khan @ 2017-06-27 15:40 UTC (permalink / raw) To: Naresh Kamboju, luto, keescook Cc: linux-kselftest, linux-kernel, Shuah Khan, shuah Khan 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 >> > ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2017-06-29 16:34 UTC | newest] Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-06-27 8:40 selftests/capabilities: test FAIL on linux mainline and linux-next and PASS on linux-4.4.70+ Naresh Kamboju 2017-06-27 15:13 ` Greg KH 2017-06-27 15:16 ` Greg KH 2017-06-27 15:48 ` Paul Elder 2017-06-27 23:16 ` Shuah Khan 2017-06-28 4:35 ` Kees Cook 2017-06-28 21:21 ` Andy Lutomirski 2017-06-29 14:02 ` Eric W. Biederman 2017-06-29 14:23 ` Eric W. Biederman 2017-06-29 15:39 ` Andy Lutomirski 2017-06-29 16:26 ` Eric W. Biederman 2017-06-27 15:32 ` Shuah Khan 2017-06-27 15:40 ` Shuah Khan
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.