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
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
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
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
>
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
>>
>
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
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
On Tue, Jun 27, 2017 at 4:16 PM, Shuah Khan <[email protected]> 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 <[email protected]>
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
On Tue, Jun 27, 2017 at 9:35 PM, Kees Cook <[email protected]> wrote:
> On Tue, Jun 27, 2017 at 4:16 PM, Shuah Khan <[email protected]> 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 <[email protected]>
> 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?
Andy Lutomirski <[email protected]> writes:
> On Tue, Jun 27, 2017 at 9:35 PM, Kees Cook <[email protected]> wrote:
>> On Tue, Jun 27, 2017 at 4:16 PM, Shuah Khan <[email protected]> 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 <[email protected]>
>> 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
[email protected] (Eric W. Biederman) writes:
> Andy Lutomirski <[email protected]> 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
On Thu, Jun 29, 2017 at 7:23 AM, Eric W. Biederman
<[email protected]> wrote:
> [email protected] (Eric W. Biederman) writes:
>
>> Andy Lutomirski <[email protected]> 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
Andy Lutomirski <[email protected]> writes:
> On Thu, Jun 29, 2017 at 7:23 AM, Eric W. Biederman
> <[email protected]> wrote:
>> [email protected] (Eric W. Biederman) writes:
>>
>>> Andy Lutomirski <[email protected]> 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