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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 28 Jun 2017 14:21:01 -0700
From:   Andy Lutomirski <luto@...nel.org>
To:     Kees Cook <keescook@...omium.org>,
        "Eric W. Biederman" <ebiederm@...ssion.com>
Cc:     Shuah Khan <shuahkh@....samsung.com>,
        Andy Lutomirski <luto@...nel.org>, Greg KH <greg@...ah.com>,
        Naresh Kamboju <naresh.kamboju@...aro.org>,
        "open list:KERNEL SELFTEST FRAMEWORK" 
        <linux-kselftest@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Shuah Khan <shuah@...nel.org>
Subject: Re: selftests/capabilities: test FAIL on linux mainline and
 linux-next and PASS on linux-4.4.70+

On Tue, Jun 27, 2017 at 9:35 PM, Kees Cook <keescook@...omium.org> wrote:
> On Tue, Jun 27, 2017 at 4:16 PM, Shuah Khan <shuahkh@....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@...capital.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?