In permissive setting labels that are not in host policy when running unprivileged fails with EINVAL

In permissive setting labels that are not in host policy when running unprivileged fails with EINVAL

[Petr Lautrbach]

Hello,

this is originally reported at
https://github.com/SELinuxProject/selinux/issues/437

There a question why kernel blocks changing SELinux label to some
unknown label and requires CAP_MAC_ADMIN even in permissive mode?

Reproducer:

$ id -u
1000

$ getenforce 
Permissive

$ chcon -t bin_t /var/lib/mock/fedora-rawhide-x86_64/root/usr/lib/systemd/system-generators/systemd-ssh-generator

$ chcon -t selinux_unknown_type_t /var/lib/mock/fedora-rawhide-x86_64/root/usr/lib/systemd/system-generators/systemd-ssh-generator
chcon: failed to change context of '/var/lib/mock/fedora-rawhide-x86_64/root/usr/lib/systemd/system-generators/systemd-ssh-generator' to ‘system_u:object_r:selinux_unknown_type_t:s0’: Invalid argument


Quotes from the issue:

This is happening on a system with SELinux in permissive mode. Applying
your suggestion does not change the result. I assume this is gated
behind CAP_MAC_ADMIN for unprivileged users. Is there any way to make
this work without needing root privileges?

Hmm so the kernel blocks unknown labels unless the user has
CAP_MAC_ADMIN in the initial user namespace. I'm assuming this is for a
good reason and it would be unsafe to allow any user to do this so I
don't think there's anything that can be done here

One thing that's not clear to me, why is an unprivileged user allowed to
write labels known by the host but not labels that are not known to the
host? What specifically is unsafe about unknown labels that's not an
issue with known labels?

Petr

Re: In permissive setting labels that are not in host policy when running unprivileged fails with EINVAL

[Stephen Smalley]

On Wed, Jul 10, 2024 at 9:32 AM Petr Lautrbach <lautrbach@redhat.com> wrote:
>
> Hello,
>
> this is originally reported at
> https://github.com/SELinuxProject/selinux/issues/437
>
> There a question why kernel blocks changing SELinux label to some
> unknown label and requires CAP_MAC_ADMIN even in permissive mode?
>
> Reproducer:
>
> $ id -u
> 1000
>
> $ getenforce
> Permissive
>
> $ chcon -t bin_t /var/lib/mock/fedora-rawhide-x86_64/root/usr/lib/systemd/system-generators/systemd-ssh-generator
>
> $ chcon -t selinux_unknown_type_t /var/lib/mock/fedora-rawhide-x86_64/root/usr/lib/systemd/system-generators/systemd-ssh-generator
> chcon: failed to change context of '/var/lib/mock/fedora-rawhide-x86_64/root/usr/lib/systemd/system-generators/systemd-ssh-generator' to ‘system_u:object_r:selinux_unknown_type_t:s0’: Invalid argument
>
>
> Quotes from the issue:
>
> This is happening on a system with SELinux in permissive mode. Applying
> your suggestion does not change the result. I assume this is gated
> behind CAP_MAC_ADMIN for unprivileged users. Is there any way to make
> this work without needing root privileges?
>
> Hmm so the kernel blocks unknown labels unless the user has
> CAP_MAC_ADMIN in the initial user namespace. I'm assuming this is for a
> good reason and it would be unsafe to allow any user to do this so I
> don't think there's anything that can be done here
>
> One thing that's not clear to me, why is an unprivileged user allowed to
> write labels known by the host but not labels that are not known to the
> host? What specifically is unsafe about unknown labels that's not an
> issue with known labels?

With SELinux disabled, setting of security.* xattrs at all is gated by
CAP_SYS_ADMIN.
With SELinux enabled, the security.selinux xattrs can be set to valid
security contexts without any capability if allowed by policy.
Support for setting unknown security contexts was a later addition to
SELinux for a specific use case (original motivation provided by Red
Hat was to permit rpm to set contexts on files unpacked from a package
before it inserted the corresponding policy module from %post), and
was not expected to be used by unprivileged users.
Smack had already introduced CAP_MAC_ADMIN at that point, and it
seemed reasonable to use it for this purpose, since setting labels
unknown to the policy is effectively like being the admin of the MAC
policy.
The policy can't make useful determinations about what to do with
unknown labels so it can't provide any information flow guarantees.
There may also have been a concern about the facility being abused to
push arbitrary data into a security.selinux xattr to be fetched by
some other privileged process later in a manner that would ultimately
lead to a vulnerability.
Not saying that we can't change things here, but would require a
graceful and compatible transition path.

Re: In permissive setting labels that are not in host policy when running unprivileged fails with EINVAL

[Paul Moore]

On Wed, Jul 10, 2024 at 9:50 AM Stephen Smalley
<stephen.smalley.work@gmail.com> wrote:
> On Wed, Jul 10, 2024 at 9:32 AM Petr Lautrbach <lautrbach@redhat.com> wrote:
> >
> > Hello,
> >
> > this is originally reported at
> > https://github.com/SELinuxProject/selinux/issues/437
> >
> > There a question why kernel blocks changing SELinux label to some
> > unknown label and requires CAP_MAC_ADMIN even in permissive mode?
> >
> > Reproducer:
> >
> > $ id -u
> > 1000
> >
> > $ getenforce
> > Permissive
> >
> > $ chcon -t bin_t /var/lib/mock/fedora-rawhide-x86_64/root/usr/lib/systemd/system-generators/systemd-ssh-generator
> >
> > $ chcon -t selinux_unknown_type_t /var/lib/mock/fedora-rawhide-x86_64/root/usr/lib/systemd/system-generators/systemd-ssh-generator
> > chcon: failed to change context of '/var/lib/mock/fedora-rawhide-x86_64/root/usr/lib/systemd/system-generators/systemd-ssh-generator' to ‘system_u:object_r:selinux_unknown_type_t:s0’: Invalid argument
> >
> >
> > Quotes from the issue:
> >
> > This is happening on a system with SELinux in permissive mode. Applying
> > your suggestion does not change the result. I assume this is gated
> > behind CAP_MAC_ADMIN for unprivileged users. Is there any way to make
> > this work without needing root privileges?
> >
> > Hmm so the kernel blocks unknown labels unless the user has
> > CAP_MAC_ADMIN in the initial user namespace. I'm assuming this is for a
> > good reason and it would be unsafe to allow any user to do this so I
> > don't think there's anything that can be done here
> >
> > One thing that's not clear to me, why is an unprivileged user allowed to
> > write labels known by the host but not labels that are not known to the
> > host? What specifically is unsafe about unknown labels that's not an
> > issue with known labels?
>
> With SELinux disabled, setting of security.* xattrs at all is gated by
> CAP_SYS_ADMIN.
> With SELinux enabled, the security.selinux xattrs can be set to valid
> security contexts without any capability if allowed by policy.
> Support for setting unknown security contexts was a later addition to
> SELinux for a specific use case (original motivation provided by Red
> Hat was to permit rpm to set contexts on files unpacked from a package
> before it inserted the corresponding policy module from %post), and
> was not expected to be used by unprivileged users.
> Smack had already introduced CAP_MAC_ADMIN at that point, and it
> seemed reasonable to use it for this purpose, since setting labels
> unknown to the policy is effectively like being the admin of the MAC
> policy.
> The policy can't make useful determinations about what to do with
> unknown labels so it can't provide any information flow guarantees.
> There may also have been a concern about the facility being abused to
> push arbitrary data into a security.selinux xattr to be fetched by
> some other privileged process later in a manner that would ultimately
> lead to a vulnerability.
> Not saying that we can't change things here, but would require a
> graceful and compatible transition path.

FWIW, we would also need to see a very compelling reason with broad
reach that doesn't have a good workaround before we consider changing
the current behavior.  The scenario described in the original GH issue
is interesting, but my suspicion is that it is fairly limited.

-- 
paul-moore.com

Re: In permissive setting labels that are not in host policy when running unprivileged fails with EINVAL

[Petr Lautrbach]

Paul Moore <paul@paul-moore.com> writes:

> On Wed, Jul 10, 2024 at 9:50 AM Stephen Smalley
> <stephen.smalley.work@gmail.com> wrote:
>> On Wed, Jul 10, 2024 at 9:32 AM Petr Lautrbach <lautrbach@redhat.com> wrote:
>> >
>> > Hello,
>> >
>> > this is originally reported at
>> > https://github.com/SELinuxProject/selinux/issues/437
>> >
>> > There a question why kernel blocks changing SELinux label to some
>> > unknown label and requires CAP_MAC_ADMIN even in permissive mode?
>> >
>> > Reproducer:
>> >
>> > $ id -u
>> > 1000
>> >
>> > $ getenforce
>> > Permissive
>> >
>> > $ chcon -t bin_t /var/lib/mock/fedora-rawhide-x86_64/root/usr/lib/systemd/system-generators/systemd-ssh-generator
>> >
>> > $ chcon -t selinux_unknown_type_t /var/lib/mock/fedora-rawhide-x86_64/root/usr/lib/systemd/system-generators/systemd-ssh-generator
>> > chcon: failed to change context of '/var/lib/mock/fedora-rawhide-x86_64/root/usr/lib/systemd/system-generators/systemd-ssh-generator' to ‘system_u:object_r:selinux_unknown_type_t:s0’: Invalid argument
>> >
>> >
>> > Quotes from the issue:
>> >
>> > This is happening on a system with SELinux in permissive mode. Applying
>> > your suggestion does not change the result. I assume this is gated
>> > behind CAP_MAC_ADMIN for unprivileged users. Is there any way to make
>> > this work without needing root privileges?
>> >
>> > Hmm so the kernel blocks unknown labels unless the user has
>> > CAP_MAC_ADMIN in the initial user namespace. I'm assuming this is for a
>> > good reason and it would be unsafe to allow any user to do this so I
>> > don't think there's anything that can be done here
>> >
>> > One thing that's not clear to me, why is an unprivileged user allowed to
>> > write labels known by the host but not labels that are not known to the
>> > host? What specifically is unsafe about unknown labels that's not an
>> > issue with known labels?
>>
>> With SELinux disabled, setting of security.* xattrs at all is gated by
>> CAP_SYS_ADMIN.
>> With SELinux enabled, the security.selinux xattrs can be set to valid
>> security contexts without any capability if allowed by policy.
>> Support for setting unknown security contexts was a later addition to
>> SELinux for a specific use case (original motivation provided by Red
>> Hat was to permit rpm to set contexts on files unpacked from a package
>> before it inserted the corresponding policy module from %post), and
>> was not expected to be used by unprivileged users.
>> Smack had already introduced CAP_MAC_ADMIN at that point, and it
>> seemed reasonable to use it for this purpose, since setting labels
>> unknown to the policy is effectively like being the admin of the MAC
>> policy.
>> The policy can't make useful determinations about what to do with
>> unknown labels so it can't provide any information flow guarantees.
>> There may also have been a concern about the facility being abused to
>> push arbitrary data into a security.selinux xattr to be fetched by
>> some other privileged process later in a manner that would ultimately
>> lead to a vulnerability.
>> Not saying that we can't change things here, but would require a
>> graceful and compatible transition path.
>
> FWIW, we would also need to see a very compelling reason with broad
> reach that doesn't have a good workaround before we consider changing
> the current behavior.  The scenario described in the original GH issue
> is interesting, but my suspicion is that it is fairly limited.
>

thanks!

Re: In permissive setting labels that are not in host policy when running unprivileged fails with EINVAL

[Dominick Grift]

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

> On Wed, Jul 10, 2024 at 9:32 AM Petr Lautrbach <lautrbach@redhat.com> wrote:
>>
>> Hello,
>>
>> this is originally reported at
>> https://github.com/SELinuxProject/selinux/issues/437
>>
>> There a question why kernel blocks changing SELinux label to some
>> unknown label and requires CAP_MAC_ADMIN even in permissive mode?
>>
>> Reproducer:
>>
>> $ id -u
>> 1000
>>
>> $ getenforce
>> Permissive
>>
>> $ chcon -t bin_t /var/lib/mock/fedora-rawhide-x86_64/root/usr/lib/systemd/system-generators/systemd-ssh-generator
>>
>> $ chcon -t selinux_unknown_type_t /var/lib/mock/fedora-rawhide-x86_64/root/usr/lib/systemd/system-generators/systemd-ssh-generator
>> chcon: failed to change context of
>> '/var/lib/mock/fedora-rawhide-x86_64/root/usr/lib/systemd/system-generators/systemd-ssh-generator'
>> to ‘system_u:object_r:selinux_unknown_type_t:s0’: Invalid argument
>>
>>
>> Quotes from the issue:
>>
>> This is happening on a system with SELinux in permissive mode. Applying
>> your suggestion does not change the result. I assume this is gated
>> behind CAP_MAC_ADMIN for unprivileged users. Is there any way to make
>> this work without needing root privileges?
>>
>> Hmm so the kernel blocks unknown labels unless the user has
>> CAP_MAC_ADMIN in the initial user namespace. I'm assuming this is for a
>> good reason and it would be unsafe to allow any user to do this so I
>> don't think there's anything that can be done here
>>
>> One thing that's not clear to me, why is an unprivileged user allowed to
>> write labels known by the host but not labels that are not known to the
>> host? What specifically is unsafe about unknown labels that's not an
>> issue with known labels?
>
> With SELinux disabled, setting of security.* xattrs at all is gated by
> CAP_SYS_ADMIN.
> With SELinux enabled, the security.selinux xattrs can be set to valid
> security contexts without any capability if allowed by policy.
> Support for setting unknown security contexts was a later addition to
> SELinux for a specific use case (original motivation provided by Red
> Hat was to permit rpm to set contexts on files unpacked from a package
> before it inserted the corresponding policy module from %post), and
> was not expected to be used by unprivileged users.
> Smack had already introduced CAP_MAC_ADMIN at that point, and it
> seemed reasonable to use it for this purpose, since setting labels
> unknown to the policy is effectively like being the admin of the MAC
> policy.
> The policy can't make useful determinations about what to do with
> unknown labels so it can't provide any information flow guarantees.
> There may also have been a concern about the facility being abused to
> push arbitrary data into a security.selinux xattr to be fetched by
> some other privileged process later in a manner that would ultimately
> lead to a vulnerability.
> Not saying that we can't change things here, but would require a
> graceful and compatible transition path.
>

The use-case for this is livecd/usb creation. For example creating an
MLS livecd/usb on a non-MLS host.

I also hit this issue on policy-developement as I am also a user of the
mkosi tool that is referenced in the issue.

mkosi is a tool that can build a source and boot an image using that
source. If I add some module to my policy source tree and I want to test
that in a virtual machine then I would run mkosi on the source.

mkosi is not allowed to use the label that is unknown on the host on the
filesystem. So the file ends up unlabeled in the virtual machine. So
using mkosi for testing policy is not useful unless you run mkosi as
root. Which is fair to be honest. There is quite a bit of functionality
in mkosi that only works if you run it as root.



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

Re: In permissive setting labels that are not in host policy when running unprivileged fails with EINVAL

[Stephen Smalley]

On Wed, Jul 10, 2024 at 1:40 PM Dominick Grift
<dominick.grift@defensec.nl> wrote:
>
> Stephen Smalley <stephen.smalley.work@gmail.com> writes:
>
> > On Wed, Jul 10, 2024 at 9:32 AM Petr Lautrbach <lautrbach@redhat.com> wrote:
> >>
> >> Hello,
> >>
> >> this is originally reported at
> >> https://github.com/SELinuxProject/selinux/issues/437
> >>
> >> There a question why kernel blocks changing SELinux label to some
> >> unknown label and requires CAP_MAC_ADMIN even in permissive mode?
> >>
> >> Reproducer:
> >>
> >> $ id -u
> >> 1000
> >>
> >> $ getenforce
> >> Permissive
> >>
> >> $ chcon -t bin_t /var/lib/mock/fedora-rawhide-x86_64/root/usr/lib/systemd/system-generators/systemd-ssh-generator
> >>
> >> $ chcon -t selinux_unknown_type_t /var/lib/mock/fedora-rawhide-x86_64/root/usr/lib/systemd/system-generators/systemd-ssh-generator
> >> chcon: failed to change context of
> >> '/var/lib/mock/fedora-rawhide-x86_64/root/usr/lib/systemd/system-generators/systemd-ssh-generator'
> >> to ‘system_u:object_r:selinux_unknown_type_t:s0’: Invalid argument
> >>
> >>
> >> Quotes from the issue:
> >>
> >> This is happening on a system with SELinux in permissive mode. Applying
> >> your suggestion does not change the result. I assume this is gated
> >> behind CAP_MAC_ADMIN for unprivileged users. Is there any way to make
> >> this work without needing root privileges?
> >>
> >> Hmm so the kernel blocks unknown labels unless the user has
> >> CAP_MAC_ADMIN in the initial user namespace. I'm assuming this is for a
> >> good reason and it would be unsafe to allow any user to do this so I
> >> don't think there's anything that can be done here
> >>
> >> One thing that's not clear to me, why is an unprivileged user allowed to
> >> write labels known by the host but not labels that are not known to the
> >> host? What specifically is unsafe about unknown labels that's not an
> >> issue with known labels?
> >
> > With SELinux disabled, setting of security.* xattrs at all is gated by
> > CAP_SYS_ADMIN.
> > With SELinux enabled, the security.selinux xattrs can be set to valid
> > security contexts without any capability if allowed by policy.
> > Support for setting unknown security contexts was a later addition to
> > SELinux for a specific use case (original motivation provided by Red
> > Hat was to permit rpm to set contexts on files unpacked from a package
> > before it inserted the corresponding policy module from %post), and
> > was not expected to be used by unprivileged users.
> > Smack had already introduced CAP_MAC_ADMIN at that point, and it
> > seemed reasonable to use it for this purpose, since setting labels
> > unknown to the policy is effectively like being the admin of the MAC
> > policy.
> > The policy can't make useful determinations about what to do with
> > unknown labels so it can't provide any information flow guarantees.
> > There may also have been a concern about the facility being abused to
> > push arbitrary data into a security.selinux xattr to be fetched by
> > some other privileged process later in a manner that would ultimately
> > lead to a vulnerability.
> > Not saying that we can't change things here, but would require a
> > graceful and compatible transition path.
> >
>
> The use-case for this is livecd/usb creation. For example creating an
> MLS livecd/usb on a non-MLS host.

I'm fairly sure that people have been using the unknown label support
for livecd creation successfully for quite some time. Have they just
been doing it with CAP_MAC_ADMIN enabled or otherwise as root?

> I also hit this issue on policy-developement as I am also a user of the
> mkosi tool that is referenced in the issue.
>
> mkosi is a tool that can build a source and boot an image using that
> source. If I add some module to my policy source tree and I want to test
> that in a virtual machine then I would run mkosi on the source.
>
> mkosi is not allowed to use the label that is unknown on the host on the
> filesystem. So the file ends up unlabeled in the virtual machine. So
> using mkosi for testing policy is not useful unless you run mkosi as
> root. Which is fair to be honest. There is quite a bit of functionality
> in mkosi that only works if you run it as root.

Yes, I'm not sure if this is a compelling example. For Android I just
built the support for labeling files into the filesystem image
generation tools themselves so that it could produce a fully labeled
filesystem without ever needing to mount it on the host. I think the
Yocto meta-selinux tooling also migrated toward that kind of an
approach, although I could be wrong.

Re: In permissive setting labels that are not in host policy when running unprivileged fails with EINVAL

[Dominick Grift]

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

> On Wed, Jul 10, 2024 at 1:40 PM Dominick Grift
> <dominick.grift@defensec.nl> wrote:
>>
>> Stephen Smalley <stephen.smalley.work@gmail.com> writes:
>>
>> > On Wed, Jul 10, 2024 at 9:32 AM Petr Lautrbach <lautrbach@redhat.com> wrote:
>> >>
>> >> Hello,
>> >>
>> >> this is originally reported at
>> >> https://github.com/SELinuxProject/selinux/issues/437
>> >>
>> >> There a question why kernel blocks changing SELinux label to some
>> >> unknown label and requires CAP_MAC_ADMIN even in permissive mode?
>> >>
>> >> Reproducer:
>> >>
>> >> $ id -u
>> >> 1000
>> >>
>> >> $ getenforce
>> >> Permissive
>> >>
>> >> $ chcon -t bin_t /var/lib/mock/fedora-rawhide-x86_64/root/usr/lib/systemd/system-generators/systemd-ssh-generator
>> >>
>> >> $ chcon -t selinux_unknown_type_t
>> >> /var/lib/mock/fedora-rawhide-x86_64/root/usr/lib/systemd/system-generators/systemd-ssh-generator
>> >> chcon: failed to change context of
>> >> '/var/lib/mock/fedora-rawhide-x86_64/root/usr/lib/systemd/system-generators/systemd-ssh-generator'
>> >> to ‘system_u:object_r:selinux_unknown_type_t:s0’: Invalid argument
>> >>
>> >>
>> >> Quotes from the issue:
>> >>
>> >> This is happening on a system with SELinux in permissive mode. Applying
>> >> your suggestion does not change the result. I assume this is gated
>> >> behind CAP_MAC_ADMIN for unprivileged users. Is there any way to make
>> >> this work without needing root privileges?
>> >>
>> >> Hmm so the kernel blocks unknown labels unless the user has
>> >> CAP_MAC_ADMIN in the initial user namespace. I'm assuming this is for a
>> >> good reason and it would be unsafe to allow any user to do this so I
>> >> don't think there's anything that can be done here
>> >>
>> >> One thing that's not clear to me, why is an unprivileged user allowed to
>> >> write labels known by the host but not labels that are not known to the
>> >> host? What specifically is unsafe about unknown labels that's not an
>> >> issue with known labels?
>> >
>> > With SELinux disabled, setting of security.* xattrs at all is gated by
>> > CAP_SYS_ADMIN.
>> > With SELinux enabled, the security.selinux xattrs can be set to valid
>> > security contexts without any capability if allowed by policy.
>> > Support for setting unknown security contexts was a later addition to
>> > SELinux for a specific use case (original motivation provided by Red
>> > Hat was to permit rpm to set contexts on files unpacked from a package
>> > before it inserted the corresponding policy module from %post), and
>> > was not expected to be used by unprivileged users.
>> > Smack had already introduced CAP_MAC_ADMIN at that point, and it
>> > seemed reasonable to use it for this purpose, since setting labels
>> > unknown to the policy is effectively like being the admin of the MAC
>> > policy.
>> > The policy can't make useful determinations about what to do with
>> > unknown labels so it can't provide any information flow guarantees.
>> > There may also have been a concern about the facility being abused to
>> > push arbitrary data into a security.selinux xattr to be fetched by
>> > some other privileged process later in a manner that would ultimately
>> > lead to a vulnerability.
>> > Not saying that we can't change things here, but would require a
>> > graceful and compatible transition path.
>> >
>>
>> The use-case for this is livecd/usb creation. For example creating an
>> MLS livecd/usb on a non-MLS host.
>
> I'm fairly sure that people have been using the unknown label support
> for livecd creation successfully for quite some time. Have they just
> been doing it with CAP_MAC_ADMIN enabled or otherwise as root?

AFAIK (and from experience) yes, CAP_MAC_ADMIN and root. Theres also
setfiles_mac_t for this.

>
>> I also hit this issue on policy-developement as I am also a user of the
>> mkosi tool that is referenced in the issue.
>>
>> mkosi is a tool that can build a source and boot an image using that
>> source. If I add some module to my policy source tree and I want to test
>> that in a virtual machine then I would run mkosi on the source.
>>
>> mkosi is not allowed to use the label that is unknown on the host on the
>> filesystem. So the file ends up unlabeled in the virtual machine. So
>> using mkosi for testing policy is not useful unless you run mkosi as
>> root. Which is fair to be honest. There is quite a bit of functionality
>> in mkosi that only works if you run it as root.
>
> Yes, I'm not sure if this is a compelling example. For Android I just
> built the support for labeling files into the filesystem image
> generation tools themselves so that it could produce a fully labeled
> filesystem without ever needing to mount it on the host. I think the
> Yocto meta-selinux tooling also migrated toward that kind of an
> approach, although I could be wrong.
>

I agree but its not mounted on the host. It just installs a tree on the
host, labels that a then uses systemd-repart with --offline [1] option to
copy the tree to a disk image (no root needed and no mounting needed)

You'd still need to be able to associate an invalid label with the file.

[1] "--offline=BOOL

    Instructs systemd-repart to build the image offline. Takes a boolean or "auto". Defaults to "auto". If enabled, the image is built without using loop devices. This is useful to build images unprivileged or when loop devices are not available. If disabled, the image is always built using loop devices. If "auto", systemd-repart will build the image online if possible and fall back to building the image offline if loop devices are not available or cannot be accessed due to missing permissions.

    Added in version 254.
    "

https://github.com/systemd/mkosi/blob/main/mkosi/__init__.py#L3210
https://github.com/systemd/mkosi/blob/main/mkosi/__init__.py#L3334

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