From: Mark Salyzyn <salyzyn@android.com>
To: Miklos Szeredi <miklos@szeredi.hu>, Amir Goldstein <amir73il@gmail.com>
Cc: linux-kernel <linux-kernel@vger.kernel.org>,
Jonathan Corbet <corbet@lwn.net>, Vivek Goyal <vgoyal@redhat.com>,
"Eric W. Biederman" <ebiederm@xmission.com>,
Randy Dunlap <rdunlap@infradead.org>,
Stephen Smalley <sds@tycho.nsa.gov>,
overlayfs <linux-unionfs@vger.kernel.org>,
linux-doc@vger.kernel.org, kernel-team@android.com
Subject: Re: [PATCH v6 2/2] overlayfs: override_creds=off option bypass creator_cred
Date: Tue, 6 Nov 2018 08:50:16 -0800 [thread overview]
Message-ID: <8beaf21a-2242-3c60-4de7-76190b71842b@android.com> (raw)
In-Reply-To: <CAJfpeguesUtcSVsjkG1aT_bW03+HYpLrmP4w4Zo8MYiz1udrcQ@mail.gmail.com>
On 11/06/2018 12:39 AM, Miklos Szeredi wrote:
> On Mon, Nov 5, 2018 at 7:47 PM, Amir Goldstein <amir73il@gmail.com> wrote:
>> On Mon, Nov 5, 2018 at 8:22 PM Mark Salyzyn <salyzyn@android.com> wrote:
>>> @@ -1549,7 +1569,8 @@ static int ovl_fill_super(struct super_block *sb, void *data, int silent)
>>> ovl_dentry_lower(root_dentry), NULL);
>>>
>>> sb->s_root = root_dentry;
>>> -
>>> + if (!ofs->config.override_creds)
>>> + pr_warn("overlayfs: override_creds=off, caller credentials may not be enough to delete file or directories, create nodes, or search directories.\n");
>> The audience is someone that has this feature on by mistake or someone
>> that turn it
>> on without understanding what it does. I am not sure that this is
>> scary enough, but
>> I don't have a better suggestion.
>> Will let others state their opinion.
> I don't think we need any warning message, writing down the rules in
> the documentation should be enough.
I would be pleased to remove them, but maybe more historical background
is required in the documentation (see below [TL;DR])? I have been told
to not talk rationalization, history, use cases; but only about side
effects in the documentation.
Yes, the documentation (in the v7 patch set) cites this problem, so can
remove this pr_warn in a v8 respin. Does anyone disagree? will respin by
EOD if nothing said.
[TL;DR]
In 4.4 the default behaviour was effectively !override_creds since the
mounter or creator MAC and DAC credentials wrapping the existing caller
credentials had not yet been added until later. Except at that time the
capabilities were temporarily elevated inside the overlayfs driver
during the cited operations to (blindly) permit these few.
When the mounter's MAC and DAC credentials were added (later), security
was greatly improved by not counting on the elevated DAC, but it broke
the expected 4.4 user space API. So in 4.9 and higher Android will
require this patch to restore the behaviour that supports
non-overlapping MAC credentials. But we chose _not_ to re-add the
(inadvisable) hard coded elevated credentials for these specific
accesses thus requiring the caller to _have_ the DAC credentials to
perform them.
- For those using the 4.4 way of doing things, these noted operations work.
- For those using the 4.9 way of doing things, the non-overlapping
creator and caller MAC credentials broke.
- For latest, this patch brought back the support for non-overlapping
MAC credentials, without the security issues of the 4.4 implementation,
but alas breaks the 4.4 way of doing things as noted in this warning
message.
-- Mark
next prev parent reply other threads:[~2018-11-06 16:50 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-05 18:21 [PATCH v6 0/2] Mark Salyzyn
2018-11-05 18:21 ` [PATCH v6 1/2] overlayfs: check CAP_DAC_READ_SEARCH before issuing exportfs_decode_fh Mark Salyzyn
2018-11-05 18:35 ` Amir Goldstein
2018-11-06 1:05 ` kbuild test robot
2018-11-06 1:30 ` kbuild test robot
2018-11-05 18:21 ` [PATCH v6 2/2] overlayfs: override_creds=off option bypass creator_cred Mark Salyzyn
2018-11-05 18:47 ` Amir Goldstein
2018-11-06 8:39 ` Miklos Szeredi
2018-11-06 16:50 ` Mark Salyzyn [this message]
2018-11-05 18:55 ` [PATCH v6 0/2] Amir Goldstein
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=8beaf21a-2242-3c60-4de7-76190b71842b@android.com \
--to=salyzyn@android.com \
--cc=amir73il@gmail.com \
--cc=corbet@lwn.net \
--cc=ebiederm@xmission.com \
--cc=kernel-team@android.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-unionfs@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=rdunlap@infradead.org \
--cc=sds@tycho.nsa.gov \
--cc=vgoyal@redhat.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
all inboxes | Powered by JetHome®