linux-kernel - Re: [PATCH v3 0/6] Composefs: an opportunistically sharing verified image filesystem

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: <CAOQ4uxgos8m72icX+u2_6Gh7eMmctTTt6XZ=BRt3VzeOZH+UuQ@mail.gmail.com>
Date:   Wed, 25 Jan 2023 20:07:26 +0200
From:   Amir Goldstein <amir73il@...il.com>
To:     Giuseppe Scrivano <gscrivan@...hat.com>
Cc:     Dave Chinner <david@...morbit.com>,
        Alexander Larsson <alexl@...hat.com>,
        linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
        brauner@...nel.org, viro@...iv.linux.org.uk,
        Vivek Goyal <vgoyal@...hat.com>,
        Miklos Szeredi <miklos@...redi.hu>
Subject: Re: [PATCH v3 0/6] Composefs: an opportunistically sharing verified
 image filesystem

> >> I previously mentioned my wish of using it from a user namespace, the
> >> goal seems more challenging with EROFS or any other block devices.  I
> >> don't know about the difficulty of getting overlay metacopy working in a
> >> user namespace, even though it would be helpful for other use cases as
> >> well.
> >>
> >
> > There is no restriction of metacopy in user namespace.
> > overlayfs needs to be mounted with -o userxattr and the overlay
> > xattrs needs to use user.overlay. prefix.
>
> if I specify both userxattr and metacopy=on then the mount ends up in
> the following check:
>
> if (config->userxattr) {
>         [...]
>         if (config->metacopy && metacopy_opt) {
>                 pr_err("conflicting options: userxattr,metacopy=on\n");
>                 return -EINVAL;
>         }
> }
>

Right, my bad.

> to me it looks like it was done on purpose to prevent metacopy from a
> user namespace, but I don't know the reason for sure.
>

With hand crafted metacopy, an unpriv user can chmod
any files to anything by layering another file with different
mode on top of it....

Not sure how the composefs security model intends to handle
this scenario with userns mount, but it sounds like a similar
problem.

Thanks,
Amir.