linux-kernel - Re: [PATCH v19 0/4] overlayfs override

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]

Message-ID: <CAOQ4uxhxQfFfrpmRS6tOv5ANVug6d8dGx6Hsc7MYYe63sUOpcg@mail.gmail.com>
Date:   Thu, 18 Nov 2021 22:32:57 +0200
From:   Amir Goldstein <amir73il@...il.com>
To:     David Anderson <dvander@...gle.com>
Cc:     Mark Salyzyn <salyzyn@...roid.com>,
        Miklos Szeredi <miklos@...redi.hu>,
        Jonathan Corbet <corbet@....net>,
        Vivek Goyal <vgoyal@...hat.com>,
        "Eric W . Biederman" <ebiederm@...ssion.com>,
        Randy Dunlap <rdunlap@...radead.org>,
        Stephen Smalley <sds@...ho.nsa.gov>,
        John Stultz <john.stultz@...aro.org>,
        linux-doc@...r.kernel.org,
        linux-kernel <linux-kernel@...r.kernel.org>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        overlayfs <linux-unionfs@...r.kernel.org>,
        LSM List <linux-security-module@...r.kernel.org>,
        kernel-team <kernel-team@...roid.com>, selinux@...r.kernel.org,
        paulmoore@...rosoft.com, luca.boccassi@...rosoft.com
Subject: Re: [PATCH v19 0/4] overlayfs override_creds=off & nested get xattr fix

> > It is something that is not at all easy to fix.
> > In the example above, instead of checking permissions against the
> > overlay inode (on "incoming" readdir) will need to check permissions of every
> > accessing user against all layers, before allowing access to the merged
> > directory content (which is cached).
> > A lot more work - and this is just for this one example.
>
> I see your point. If we could implement that, behind a mount flag, would that be
> an acceptable solution?
>

As I wrote, this is one specific problem that I identified.
If you propose a different behavior base on mount flag you should
be able to argue that is cannot be exploited to circumvent security
access policies, by peaking into cached copies of objects that the user
has no access to, or by any other way.

I have no idea how to implement what you want and prove that
it is safe.
Maybe if you explained the use case in greater details with some
examples someone could help you reach a possible solution.

Thanks,
Amir.