From: Ilya Matveychikov <matvejchikov@gmail.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: linux-kernel@vger.kernel.org,
Alexander Viro <viro@zeniv.linux.org.uk>,
linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH] ksys_mount: check for permissions before resource allocation
Date: Wed, 6 Jun 2018 13:32:12 +0400 [thread overview]
Message-ID: <64021AF2-81EE-439C-91D4-9A33AB0D08F7@gmail.com> (raw)
In-Reply-To: <87o9gpatxs.fsf@xmission.com>
> On Jun 5, 2018, at 11:56 PM, Eric W. Biederman <ebiederm@xmission.com> wrote:
>
> Ilya Matveychikov <matvejchikov@gmail.com> writes:
>
>> Just CC’ed to some of maintainers.
>>
>> $ perl scripts/get_maintainer.pl fs/0001-ksys_mount-check-for-permissions-before-resource-all.patch
>> Alexander Viro <viro@zeniv.linux.org.uk> (maintainer:FILESYSTEMS (VFS and infrastructure))
>> linux-fsdevel@vger.kernel.org (open list:FILESYSTEMS (VFS and infrastructure))
>> linux-kernel@vger.kernel.org (open list)
>>
>>> On Jun 5, 2018, at 6:00 AM, Ilya Matveychikov <matvejchikov@gmail.com> wrote:
>>>
>>> Early check for mount permissions prevents possible allocation of 3
>>> pages from kmalloc() pool by unpriveledged user which can be used for
>>> spraying the kernel heap.
>
> *Snort*
>
> You clearly have not read may_mount. Your modified code still
> let's unprivileged users in. So even if all of Al's good objections
> were not applicable this change would still be buggy and wrong.
>
> Nacked-by: "Eric W. Biederman" <ebiederm@xmission.com>
Don’t get me wrong but may_mount() is:
static inline bool may_mount(void)
{
return ns_capable(current->nsproxy->mnt_ns->user_ns, CAP_SYS_ADMIN);
}
What do you mean by "You clearly have not read may_mount”? The only thing that
can affect may_mount result (as mentioned earlier) is that task’s NS capability
might be changed by security_sb_mount() hook.
So, do you think that is’s possible to NOT have CAP_SYS_ADMIN while entering to
ksys_mount() but getting it with the security_sb_mount() hook?
This is the only case I see that using may_mount() before security_sb_mount()
is wrong. This was the point?
next prev parent reply other threads:[~2018-06-06 9:32 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <D2317950-0DB0-4311-ADB1-FF677B676E04@gmail.com>
2018-06-05 6:59 ` [PATCH] ksys_mount: check for permissions before resource allocation Ilya Matveychikov
2018-06-05 11:26 ` Al Viro
2018-06-05 11:35 ` Ilya Matveychikov
2018-06-05 11:53 ` Al Viro
2018-06-05 12:07 ` Ilya Matveychikov
2018-06-05 12:28 ` David Sterba
2018-06-05 12:42 ` Ilya Matveychikov
2018-06-05 12:34 ` Al Viro
2018-06-05 19:56 ` Eric W. Biederman
2018-06-06 9:32 ` Ilya Matveychikov [this message]
2018-06-06 14:22 ` Eric W. Biederman
2018-06-06 15:26 ` Ilya Matveychikov
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=64021AF2-81EE-439C-91D4-9A33AB0D08F7@gmail.com \
--to=matvejchikov@gmail.com \
--cc=ebiederm@xmission.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=viro@zeniv.linux.org.uk \
/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).