Question regarding restorecon and btrfs read-only snapshots

Question regarding restorecon and btrfs read-only snapshots

[Cathy Hu]

[-- Attachment #1.1.1: Type: text/plain, Size: 1541 bytes --]

Hi all,

I have a question regarding restorecon and btrfs read-only snapshot handling.

restorecon is failing with "restorecon: Could not set context for <path>:  Read-only file system"
and return code 255 on btrfs read-only snapshots.

Currently we are setting <<none>> for those read-only btrfs snapshots in the selinux policy, as
we use restorecon in our autorelabelling [0] during boot and restorecon would fail with code 255 otherwise.
We do not want to ignore non-zero return codes, since issues might be overlooked.

However, this is also not optimal as we have to write every possible path into the policy or asking
users to set the <<none>> tag manually.

I was wondering if there was interest/plans in implementing to skip read-only btrfs subvolumes in restorecon
entirely or provide a different return code other than the catchall LABEL_FILE_KIND_INVALID?
Or is there another way that we did not see?

For more context, this is the bug on our side: https://bugzilla.suse.com/show_bug.cgi?id=1232226
There was also some comments about possible implementation, see comment 1 in the bug.

Thanks :)

Kind regards,

Cathy

[0] https://github.com/openSUSE/microos-tools/blob/master/selinux/selinux-autorelabel-generator

-- 
Cathy Hu <cahu@suse.de>
SELinux Security Engineer
GPG: 5873 CFD1 8C0E A6D4 9CBB F6C4 062A 1016 1505 A08A

SUSE Software Solutions Germany GmbH
Frankenstrasse 146
90461 Nürnberg

Geschäftsführer: Ivo Totev, Andrew McDonald, Werner Knoblich
(HRB 36809, AG Nürnberg)


[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 6345 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Question regarding restorecon and btrfs read-only snapshots

[Petr Lautrbach]

Cathy Hu <cahu@suse.de> writes:

> Hi all,
>
> I have a question regarding restorecon and btrfs read-only snapshot handling.
>
> restorecon is failing with "restorecon: Could not set context for <path>:  Read-only file system"
> and return code 255 on btrfs read-only snapshots.
>
> Currently we are setting <<none>> for those read-only btrfs snapshots in the selinux policy, as
> we use restorecon in our autorelabelling [0] during boot and restorecon would fail with code 255 otherwise.
> We do not want to ignore non-zero return codes, since issues might be overlooked.
>
> However, this is also not optimal as we have to write every possible path into the policy or asking
> users to set the <<none>> tag manually.
>
> I was wondering if there was interest/plans in implementing to skip read-only btrfs subvolumes in restorecon
> entirely or provide a different return code other than the catchall LABEL_FILE_KIND_INVALID?
> Or is there another way that we did not see?
>
> For more context, this is the bug on our side: https://bugzilla.suse.com/show_bug.cgi?id=1232226
> There was also some comments about possible implementation, see comment 1 in the bug.

You could use `-e <directory>` to exclude read only subdirectories.

Petr

>
> Thanks :)
>
> Kind regards,
>
> Cathy
>
> [0] https://github.com/openSUSE/microos-tools/blob/master/selinux/selinux-autorelabel-generator
>
> -- 
> Cathy Hu <cahu@suse.de>
> SELinux Security Engineer
> GPG: 5873 CFD1 8C0E A6D4 9CBB F6C4 062A 1016 1505 A08A
>
> SUSE Software Solutions Germany GmbH
> Frankenstrasse 146
> 90461 Nürnberg
>
> Geschäftsführer: Ivo Totev, Andrew McDonald, Werner Knoblich
> (HRB 36809, AG Nürnberg)

Re: Question regarding restorecon and btrfs read-only snapshots

[Cathy Hu]

[-- Attachment #1.1.1: Type: text/plain, Size: 786 bytes --]

On 17.03.25 15:29, Petr Lautrbach wrote:
> 
> You could use `-e <directory>` to exclude read only subdirectories.
> 

Yes that is possible, but also requires a manual change by the user to set
this up together with the snapshot (same as telling them to add <<none>>),
which we would like to avoid.
Is there a reason why these r-o subvolumes are not skipped by default?
Could they be skipped without a problem and it is just missing the implementation?

Thanks :)

Kind regards,
Cathy

-- 
Cathy Hu <cahu@suse.de>
SELinux Security Engineer
GPG: 5873 CFD1 8C0E A6D4 9CBB F6C4 062A 1016 1505 A08A

SUSE Software Solutions Germany GmbH
Frankenstrasse 146
90461 Nürnberg

Geschäftsführer: Ivo Totev, Andrew McDonald, Werner Knoblich
(HRB 36809, AG Nürnberg)


[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 6345 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Question regarding restorecon and btrfs read-only snapshots

[Petr Lautrbach]

Cathy Hu <cahu@suse.de> writes:

> On 17.03.25 15:29, Petr Lautrbach wrote:
>> 
>> You could use `-e <directory>` to exclude read only subdirectories.
>> 
>
> Yes that is possible, but also requires a manual change by the user to set
> this up together with the snapshot (same as telling them to add <<none>>),
> which we would like to avoid.

Your -relabel.service's are generated and so can be restorecon options
there.

Fedora uses fixfiles -
https://github.com/SELinuxProject/selinux/blob/main/policycoreutils/scripts/fixfiles
- which detects ro filesystems and skip them.



> Is there a reason why these r-o subvolumes are not skipped by default?
> Could they be skipped without a problem and it is just missing the implementation?
>
> Thanks :)
>
> Kind regards,
> Cathy
>
> -- 
> Cathy Hu <cahu@suse.de>
> SELinux Security Engineer
> GPG: 5873 CFD1 8C0E A6D4 9CBB F6C4 062A 1016 1505 A08A
>
> SUSE Software Solutions Germany GmbH
> Frankenstrasse 146
> 90461 Nürnberg
>
> Geschäftsführer: Ivo Totev, Andrew McDonald, Werner Knoblich
> (HRB 36809, AG Nürnberg)

Re: Question regarding restorecon and btrfs read-only snapshots

[Cathy Hu]

[-- Attachment #1.1.1: Type: text/plain, Size: 1529 bytes --]

Ah thanks for the clarification!

On 17.03.25 18:29, Petr Lautrbach wrote:
> Cathy Hu <cahu@suse.de> writes:
> 
>> On 17.03.25 15:29, Petr Lautrbach wrote:
>>>
>>> You could use `-e <directory>` to exclude read only subdirectories.
>>>
>>
>> Yes that is possible, but also requires a manual change by the user to set
>> this up together with the snapshot (same as telling them to add <<none>>),
>> which we would like to avoid.
> 
> Your -relabel.service's are generated and so can be restorecon options
> there.
> 
> Fedora uses fixfiles -
> https://github.com/SELinuxProject/selinux/blob/main/policycoreutils/scripts/fixfiles
> - which detects ro filesystems and skip them.
> 
> 
> 
>> Is there a reason why these r-o subvolumes are not skipped by default?
>> Could they be skipped without a problem and it is just missing the implementation?
>>
>> Thanks :)
>>
>> Kind regards,
>> Cathy
>>
>> -- 
>> Cathy Hu <cahu@suse.de>
>> SELinux Security Engineer
>> GPG: 5873 CFD1 8C0E A6D4 9CBB F6C4 062A 1016 1505 A08A
>>
>> SUSE Software Solutions Germany GmbH
>> Frankenstrasse 146
>> 90461 Nürnberg
>>
>> Geschäftsführer: Ivo Totev, Andrew McDonald, Werner Knoblich
>> (HRB 36809, AG Nürnberg)
> 

-- 
Cathy Hu <cahu@suse.de>
SELinux Security Engineer
GPG: 5873 CFD1 8C0E A6D4 9CBB F6C4 062A 1016 1505 A08A

SUSE Software Solutions Germany GmbH
Frankenstrasse 146
90461 Nürnberg

Geschäftsführer: Ivo Totev, Andrew McDonald, Werner Knoblich
(HRB 36809, AG Nürnberg)


[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 6345 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Question regarding restorecon and btrfs read-only snapshots

[Stephen Smalley]

On Mon, Mar 17, 2025 at 1:32 PM Petr Lautrbach <lautrbach@redhat.com> wrote:
>
> Cathy Hu <cahu@suse.de> writes:
>
> > On 17.03.25 15:29, Petr Lautrbach wrote:
> >>
> >> You could use `-e <directory>` to exclude read only subdirectories.
> >>
> >
> > Yes that is possible, but also requires a manual change by the user to set
> > this up together with the snapshot (same as telling them to add <<none>>),
> > which we would like to avoid.
>
> Your -relabel.service's are generated and so can be restorecon options
> there.
>
> Fedora uses fixfiles -
> https://github.com/SELinuxProject/selinux/blob/main/policycoreutils/scripts/fixfiles
> - which detects ro filesystems and skip them.

We already have logic in libselinux/src/selinux_restorecon.c to
exclude filesystems that lack seclabel support; should we augment this
to also exclude read-only filesystems to avoid the need to work around
this in all callers?

>
>
>
> > Is there a reason why these r-o subvolumes are not skipped by default?
> > Could they be skipped without a problem and it is just missing the implementation?
> >
> > Thanks :)
> >
> > Kind regards,
> > Cathy
> >

Re: Question regarding restorecon and btrfs read-only snapshots

[Petr Lautrbach]

Stephen Smalley <stephen.smalley.work@gmail.com> writes:

> On Mon, Mar 17, 2025 at 1:32 PM Petr Lautrbach <lautrbach@redhat.com> wrote:
>>
>> Cathy Hu <cahu@suse.de> writes:
>>
>> > On 17.03.25 15:29, Petr Lautrbach wrote:
>> >>
>> >> You could use `-e <directory>` to exclude read only subdirectories.
>> >>
>> >
>> > Yes that is possible, but also requires a manual change by the user to set
>> > this up together with the snapshot (same as telling them to add <<none>>),
>> > which we would like to avoid.
>>
>> Your -relabel.service's are generated and so can be restorecon options
>> there.
>>
>> Fedora uses fixfiles -
>> https://github.com/SELinuxProject/selinux/blob/main/policycoreutils/scripts/fixfiles
>> - which detects ro filesystems and skip them.
>
> We already have logic in libselinux/src/selinux_restorecon.c to
> exclude filesystems that lack seclabel support; should we augment this
> to also exclude read-only filesystems to avoid the need to work around
> this in all callers?
>

https://github.com/SELinuxProject/selinux/blob/main/libselinux/src/selinux_restorecon.c#L238

You're right, I didn't know about that.

I think it would make sense to exclude also `ro` mount points.

>>
>>
>>
>> > Is there a reason why these r-o subvolumes are not skipped by default?
>> > Could they be skipped without a problem and it is just missing the implementation?
>> >
>> > Thanks :)
>> >
>> > Kind regards,
>> > Cathy
>> >

Re: Question regarding restorecon and btrfs read-only snapshots

[Stephen Smalley]

On Tue, Mar 18, 2025 at 9:11 AM Petr Lautrbach <lautrbach@redhat.com> wrote:
>
> Stephen Smalley <stephen.smalley.work@gmail.com> writes:
>
> > On Mon, Mar 17, 2025 at 1:32 PM Petr Lautrbach <lautrbach@redhat.com> wrote:
> >>
> >> Cathy Hu <cahu@suse.de> writes:
> >>
> >> > On 17.03.25 15:29, Petr Lautrbach wrote:
> >> >>
> >> >> You could use `-e <directory>` to exclude read only subdirectories.
> >> >>
> >> >
> >> > Yes that is possible, but also requires a manual change by the user to set
> >> > this up together with the snapshot (same as telling them to add <<none>>),
> >> > which we would like to avoid.
> >>
> >> Your -relabel.service's are generated and so can be restorecon options
> >> there.
> >>
> >> Fedora uses fixfiles -
> >> https://github.com/SELinuxProject/selinux/blob/main/policycoreutils/scripts/fixfiles
> >> - which detects ro filesystems and skip them.
> >
> > We already have logic in libselinux/src/selinux_restorecon.c to
> > exclude filesystems that lack seclabel support; should we augment this
> > to also exclude read-only filesystems to avoid the need to work around
> > this in all callers?
> >
>
> https://github.com/SELinuxProject/selinux/blob/main/libselinux/src/selinux_restorecon.c#L238
>
> You're right, I didn't know about that.
>
> I think it would make sense to exclude also `ro` mount points.

I think the tricky part is the case where the caller deliberately
passed those mount points to restorecon/setfiles. The current
exclusion logic IIRC won't exclude any explicitly passed directories
to avoid silently failing. But skipping read-only mounts on a
traversal of a subdirectory would make sense IMHO.

>
> >>
> >>
> >>
> >> > Is there a reason why these r-o subvolumes are not skipped by default?
> >> > Could they be skipped without a problem and it is just missing the implementation?
> >> >
> >> > Thanks :)
> >> >
> >> > Kind regards,
> >> > Cathy
> >> >
>

Re: Question regarding restorecon and btrfs read-only snapshots

[Stephen Smalley]

On Wed, Mar 19, 2025 at 9:16 AM Stephen Smalley
<stephen.smalley.work@gmail.com> wrote:
>
> On Tue, Mar 18, 2025 at 9:11 AM Petr Lautrbach <lautrbach@redhat.com> wrote:
> >
> > Stephen Smalley <stephen.smalley.work@gmail.com> writes:
> >
> > > On Mon, Mar 17, 2025 at 1:32 PM Petr Lautrbach <lautrbach@redhat.com> wrote:
> > >>
> > >> Cathy Hu <cahu@suse.de> writes:
> > >>
> > >> > On 17.03.25 15:29, Petr Lautrbach wrote:
> > >> >>
> > >> >> You could use `-e <directory>` to exclude read only subdirectories.
> > >> >>
> > >> >
> > >> > Yes that is possible, but also requires a manual change by the user to set
> > >> > this up together with the snapshot (same as telling them to add <<none>>),
> > >> > which we would like to avoid.
> > >>
> > >> Your -relabel.service's are generated and so can be restorecon options
> > >> there.
> > >>
> > >> Fedora uses fixfiles -
> > >> https://github.com/SELinuxProject/selinux/blob/main/policycoreutils/scripts/fixfiles
> > >> - which detects ro filesystems and skip them.
> > >
> > > We already have logic in libselinux/src/selinux_restorecon.c to
> > > exclude filesystems that lack seclabel support; should we augment this
> > > to also exclude read-only filesystems to avoid the need to work around
> > > this in all callers?
> > >
> >
> > https://github.com/SELinuxProject/selinux/blob/main/libselinux/src/selinux_restorecon.c#L238
> >
> > You're right, I didn't know about that.
> >
> > I think it would make sense to exclude also `ro` mount points.
>
> I think the tricky part is the case where the caller deliberately
> passed those mount points to restorecon/setfiles. The current
> exclusion logic IIRC won't exclude any explicitly passed directories
> to avoid silently failing. But skipping read-only mounts on a
> traversal of a subdirectory would make sense IMHO.

Actually, maybe not. Scenario: Read-only mount on a higher level
directory with read-write mount of a lower level directory (e.g.
read-only / with a writable /var), and restorecon or setfiles invoked
on /.
Maybe it is best to just defer this to the callers.

>
> >
> > >>
> > >>
> > >>
> > >> > Is there a reason why these r-o subvolumes are not skipped by default?
> > >> > Could they be skipped without a problem and it is just missing the implementation?
> > >> >
> > >> > Thanks :)
> > >> >
> > >> > Kind regards,
> > >> > Cathy
> > >> >
> >

Re: Question regarding restorecon and btrfs read-only snapshots

[William Roberts]

On Wed, Mar 19, 2025 at 8:25 AM Stephen Smalley
<stephen.smalley.work@gmail.com> wrote:
>
> On Wed, Mar 19, 2025 at 9:16 AM Stephen Smalley
> <stephen.smalley.work@gmail.com> wrote:
> >
> > On Tue, Mar 18, 2025 at 9:11 AM Petr Lautrbach <lautrbach@redhat.com> wrote:
> > >
> > > Stephen Smalley <stephen.smalley.work@gmail.com> writes:
> > >
> > > > On Mon, Mar 17, 2025 at 1:32 PM Petr Lautrbach <lautrbach@redhat.com> wrote:
> > > >>
> > > >> Cathy Hu <cahu@suse.de> writes:
> > > >>
> > > >> > On 17.03.25 15:29, Petr Lautrbach wrote:
> > > >> >>
> > > >> >> You could use `-e <directory>` to exclude read only subdirectories.
> > > >> >>
> > > >> >
> > > >> > Yes that is possible, but also requires a manual change by the user to set
> > > >> > this up together with the snapshot (same as telling them to add <<none>>),
> > > >> > which we would like to avoid.
> > > >>
> > > >> Your -relabel.service's are generated and so can be restorecon options
> > > >> there.
> > > >>
> > > >> Fedora uses fixfiles -
> > > >> https://github.com/SELinuxProject/selinux/blob/main/policycoreutils/scripts/fixfiles
> > > >> - which detects ro filesystems and skip them.
> > > >
> > > > We already have logic in libselinux/src/selinux_restorecon.c to
> > > > exclude filesystems that lack seclabel support; should we augment this
> > > > to also exclude read-only filesystems to avoid the need to work around
> > > > this in all callers?
> > > >
> > >
> > > https://github.com/SELinuxProject/selinux/blob/main/libselinux/src/selinux_restorecon.c#L238
> > >
> > > You're right, I didn't know about that.
> > >
> > > I think it would make sense to exclude also `ro` mount points.
> >
> > I think the tricky part is the case where the caller deliberately
> > passed those mount points to restorecon/setfiles. The current
> > exclusion logic IIRC won't exclude any explicitly passed directories
> > to avoid silently failing. But skipping read-only mounts on a
> > traversal of a subdirectory would make sense IMHO.
>
> Actually, maybe not. Scenario: Read-only mount on a higher level
> directory with read-write mount of a lower level directory (e.g.
> read-only / with a writable /var), and restorecon or setfiles invoked
> on /.
> Maybe it is best to just defer this to the callers.

You beat me to this, I had a draft sitting in my inbox. My suggestion
was to report that it occured, but not
fail and keep going if the return code is for read only failure.

>
> >
> > >
> > > >>
> > > >>
> > > >>
> > > >> > Is there a reason why these r-o subvolumes are not skipped by default?
> > > >> > Could they be skipped without a problem and it is just missing the implementation?
> > > >> >
> > > >> > Thanks :)
> > > >> >
> > > >> > Kind regards,
> > > >> > Cathy
> > > >> >
> > >
>

Re: Question regarding restorecon and btrfs read-only snapshots

[Fabian Vogt]

Hi,

Am Mittwoch, 19. März 2025, 15:35:58 Mitteleuropäische Normalzeit schrieb William Roberts:
> On Wed, Mar 19, 2025 at 8:25 AM Stephen Smalley
> <stephen.smalley.work@gmail.com> wrote:
> >
> > On Wed, Mar 19, 2025 at 9:16 AM Stephen Smalley
> > <stephen.smalley.work@gmail.com> wrote:
> > >
> > > On Tue, Mar 18, 2025 at 9:11 AM Petr Lautrbach <lautrbach@redhat.com> wrote:
> > > >
> > > > Stephen Smalley <stephen.smalley.work@gmail.com> writes:
> > > >
> > > > > On Mon, Mar 17, 2025 at 1:32 PM Petr Lautrbach <lautrbach@redhat.com> wrote:
> > > > >>
> > > > >> Cathy Hu <cahu@suse.de> writes:
> > > > >>
> > > > >> > On 17.03.25 15:29, Petr Lautrbach wrote:
> > > > >> >>
> > > > >> >> You could use `-e <directory>` to exclude read only subdirectories.
> > > > >> >>
> > > > >> >
> > > > >> > Yes that is possible, but also requires a manual change by the user to set
> > > > >> > this up together with the snapshot (same as telling them to add <<none>>),
> > > > >> > which we would like to avoid.
> > > > >>
> > > > >> Your -relabel.service's are generated and so can be restorecon options
> > > > >> there.
> > > > >>
> > > > >> Fedora uses fixfiles -
> > > > >> https://github.com/SELinuxProject/selinux/blob/main/policycoreutils/scripts/fixfiles
> > > > >> - which detects ro filesystems and skip them.
> > > > >
> > > > > We already have logic in libselinux/src/selinux_restorecon.c to
> > > > > exclude filesystems that lack seclabel support; should we augment this
> > > > > to also exclude read-only filesystems to avoid the need to work around
> > > > > this in all callers?
> > > > >
> > > > https://github.com/SELinuxProject/selinux/blob/main/libselinux/src/selinux_restorecon.c#L238
> > > >
> > > > You're right, I didn't know about that.
> > > >
> > > > I think it would make sense to exclude also `ro` mount points.

Note that btrfs subvolumes don't necessarily show up as separate mount points:
Essentially any directory could be a subvolume. That makes it rather annoying
to gather a complete list for -e before calling restorecon (would need full FS
traversal).

To detect ro subols in restorecon, changes of st_dev need to be detected.
Quoting my comment from bugzilla:

> (Some notes for d): This could be implemented in restorecon by adding to the
> if (ftsent->fts_statp->st_dev != state->dev_num) check. The
> BTRFS_IOC_SUBVOL_GETFLAGS ioctl can be called on that FD and the result
> checked against BTRFS_SUBVOL_RDONLY. That is not too complex or expensive and
> does not need additional dependencies on e.g. libbtrfs.)

That leaves the question of what to do with that info. At first maybe just set
a flag that it's within a read-only subvol and soften error handling, i.e.
this:

> > > I think the tricky part is the case where the caller deliberately
> > > passed those mount points to restorecon/setfiles. The current
> > > exclusion logic IIRC won't exclude any explicitly passed directories
> > > to avoid silently failing. But skipping read-only mounts on a
> > > traversal of a subdirectory would make sense IMHO.
> >
> > Actually, maybe not. Scenario: Read-only mount on a higher level
> > directory with read-write mount of a lower level directory (e.g.
> > read-only / with a writable /var), and restorecon or setfiles invoked
> > on /.
> > Maybe it is best to just defer this to the callers.
> 
> You beat me to this, I had a draft sitting in my inbox. My suggestion
> was to report that it occured, but not
> fail and keep going if the return code is for read only failure.

Cheers,
Fabian

> > > > >> > Is there a reason why these r-o subvolumes are not skipped by default?
> > > > >> > Could they be skipped without a problem and it is just missing the implementation?
> > > > >> >
> > > > >> > Thanks :)
> > > > >> >
> > > > >> > Kind regards,
> > > > >> > Cathy
> > > > >> >
> > > >
> >
>