From: ebiederm@xmission.com (Eric W. Biederman)
To: Andy Lutomirski <luto@kernel.org>
Cc: Kees Cook <keescook@chromium.org>,
Shuah Khan <shuahkh@osg.samsung.com>, Greg KH <greg@kroah.com>,
Naresh Kamboju <naresh.kamboju@linaro.org>,
"open list\:KERNEL SELFTEST FRAMEWORK"
<linux-kselftest@vger.kernel.org>,
"linux-kernel\@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Shuah Khan <shuah@kernel.org>
Subject: Re: selftests/capabilities: test FAIL on linux mainline and linux-next and PASS on linux-4.4.70+
Date: Thu, 29 Jun 2017 09:02:53 -0500 [thread overview]
Message-ID: <87fuei6gdu.fsf@xmission.com> (raw)
In-Reply-To: <CALCETrVJYwoLT6=kQx9fRXzv7eVvC6dBiSHowjHHRrDCDFGJ1A@mail.gmail.com> (Andy Lutomirski's message of "Wed, 28 Jun 2017 14:21:01 -0700")
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
next prev parent reply other threads:[~2017-06-29 14:10 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87fuei6gdu.fsf@xmission.com \
--to=ebiederm@xmission.com \
--cc=greg@kroah.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=luto@kernel.org \
--cc=naresh.kamboju@linaro.org \
--cc=shuah@kernel.org \
--cc=shuahkh@osg.samsung.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).