Re: [PATCH userspace] fixfiles: do not cross mounts when traversing directories

[Dominick Grift <dominick.grift@defensec.nl>]

Ondrej Mosnacek <omosnace@redhat.com> writes:

> On Mon, Sep 19, 2022 at 1:35 PM Christian Göttsche
> <cgzones@googlemail.com> wrote:
>>
>> On Mon, 19 Sept 2022 at 13:29, Ondrej Mosnacek <omosnace@redhat.com> wrote:
>> >
>> > Always run find with -xdev to avoid unintended deleting/relabeling.
>> > While this may sometimes skip subdirectories that should be relabeled,
>> > the danger of crossing into random mounts is greater than leaving behind
>> > some unlabeled files. The find commands are just best-effort attempts to
>> > fix the labels anyway.
>>
>> The xdev option does not work for bind mounts (they are still followed).
>
> Hm... it does not if the bind mounted dir is on the same filesystem
> (superblock), so in the case where /tmp is a plain directory on the
> root filesystem it will allow traversing to other directories directly
> on the root filesystem. I guess that's still better than nothing,
> though...
>
> An alternative (at least for the more dangerous -delete part) could be
> to change the prompt to suggest switching to do the equivalent of
> `fixfiles -F onboot` + reboot. The current prompt instructs the user
> to reboot the machine anyway, so it wouldn't really make things more
> complicated for the user. Maybe I'll draft a patch for this...

The reason why one is presented with an option to "clear" /tmp is because
/tmp is a shared location. That property makes it so that file context
specifications usually do not work for these locations in general and
/tmp in particular. Relabeling does not apply there -because setfiles is
told to ignore these locations- also not with
fixfiles (-F) onboot. So telling people to run fixfiles onboot && reboot
instead of clearing /tmp does not address the challenge.

What I find strange is that one is not also presented with an option to
clear /var/tmp, because the same applies there. In that sense, I believe,
this opportunity to clear /tmp is half baked. It does not solve the
underlying issue of addressing locations that have no file context
specifications associated with them for one reason or another.

>
> --
> Ondrej Mosnacek
> Senior Software Engineer, Linux Security - SELinux kernel
> Red Hat, Inc.
>

-- 
gpg --locate-keys dominick.grift@defensec.nl
Key fingerprint = FCD2 3660 5D6B 9D27 7FC6  E0FF DA7E 521F 10F6 4098
Dominick Grift