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: <87wn5a9z4m.fsf@redhat.com>
Date:   Wed, 25 Jan 2023 20:45:45 +0100
From:   Giuseppe Scrivano <gscrivan@...hat.com>
To:     Amir Goldstein <amir73il@...il.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

Amir Goldstein <amir73il@...il.com> writes:

>> >> 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....

I might be missing something obvious about metacopy, so please correct
me if I am wrong, but I don't see how it is any different than just
copying the file and chowning it.  Of course, as long as overlay uses
the same security model so that a file that wasn't originally possible
to access must be still blocked, even if referenced through metacopy.

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

composefs, if it is going to be used from a user namespace, should be
doing the same check as overlay and do not allow accessing files that
weren't accessible before.  It could be even stricter than overlay, and
expect the payload files to be owned by the user who mounted the file
system (or be world readable) instead of any ID mapped inside the user
namespace.

Thanks,
Giuseppe

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ