[RFC] selinux: Keep genfscon prefix match semantics in userspace for wildcard

[RFC] selinux: Keep genfscon prefix match semantics in userspace for wildcard

[Takaya Saeki]

Hello Stephen, Paul, and all libselinux maintainers.

I'd like to ask your opinions about an idea to keep the semantics of genfs in
the userspace, before sending a patch to expose the new genfs_seclabel_wildcard
kernel capability to libselinux users in polcaps.h as
POLICYDB_CAP_GENFS_SECLABEL_WILDCARD.

As a background, we introduced the genfs wildcard feature to the kernel selinux
in https://lore.kernel.org/selinux/20250318083139.1515253-1-takayas@chromium.org/
(Thank you for your help and reviews!)
That enabled libselinux to use wildcards in genfs rules. There we changed the
semantics of genfs with the capability enabled in the kernel space from prefix
match to exact match with wildcards for kernel implementation simplicity.

I'm wondering whether we can keep the user-facing semantics of (genfscon ...)
statements in CIL files in the following way.

When secilc compiles a (genfscon ...) statement to the kernel binary format, it
adds a following `*` to the compiled kernel genfscon statement if the input has
(policycap genfs_seclabel_wildcard). If the input doesn't have one, secilc does
not add any following `*`. That keeps the behavior of (genfscon ...) in CIL
from the user perspective with and without the new wildcard capability. This is
similar to what our first kernel patch did, but done in the userspace by secilc
this time. So, the (genfscon ...) keeps the backward compatibility of prefix
match for libselinux users, while keeping the kernel implementation simple.
That would allow users to keep existing rules without modification.

I'd like to hear your opinions.

Re: [RFC] selinux: Keep genfscon prefix match semantics in userspace for wildcard

[Stephen Smalley]

On Thu, May 8, 2025 at 10:50 PM Takaya Saeki <takayas@chromium.org> wrote:
>
> Hello Stephen, Paul, and all libselinux maintainers.
>
> I'd like to ask your opinions about an idea to keep the semantics of genfs in
> the userspace, before sending a patch to expose the new genfs_seclabel_wildcard
> kernel capability to libselinux users in polcaps.h as
> POLICYDB_CAP_GENFS_SECLABEL_WILDCARD.
>
> As a background, we introduced the genfs wildcard feature to the kernel selinux
> in https://lore.kernel.org/selinux/20250318083139.1515253-1-takayas@chromium.org/
> (Thank you for your help and reviews!)
> That enabled libselinux to use wildcards in genfs rules. There we changed the
> semantics of genfs with the capability enabled in the kernel space from prefix
> match to exact match with wildcards for kernel implementation simplicity.
>
> I'm wondering whether we can keep the user-facing semantics of (genfscon ...)
> statements in CIL files in the following way.
>
> When secilc compiles a (genfscon ...) statement to the kernel binary format, it
> adds a following `*` to the compiled kernel genfscon statement if the input has
> (policycap genfs_seclabel_wildcard). If the input doesn't have one, secilc does
> not add any following `*`. That keeps the behavior of (genfscon ...) in CIL
> from the user perspective with and without the new wildcard capability. This is
> similar to what our first kernel patch did, but done in the userspace by secilc
> this time. So, the (genfscon ...) keeps the backward compatibility of prefix
> match for libselinux users, while keeping the kernel implementation simple.
> That would allow users to keep existing rules without modification.
>
> I'd like to hear your opinions.

(added James to cc for the secilc question)

I'm assuming you mean libsepol rather than libselinux. I could be
wrong, but I believe that in general policy capabilities are only
declared once in the policy and typically in the base module, and
those settings are then applied globally to all policy modules. While
you can put one in a non-base module, it still has a global effect on
the final policy. Putting a policycap statement into every CIL module
that wants this behavior would possibly trigger an error (not sure
how/if libsepol/secilc handles duplicate policycap statements) and
regardless would enable it for the entire policy.

Re: [RFC] selinux: Keep genfscon prefix match semantics in userspace for wildcard

[James Carter]

On Fri, May 9, 2025 at 2:23 PM Stephen Smalley
<stephen.smalley.work@gmail.com> wrote:
>
> On Thu, May 8, 2025 at 10:50 PM Takaya Saeki <takayas@chromium.org> wrote:
> >
> > Hello Stephen, Paul, and all libselinux maintainers.
> >
> > I'd like to ask your opinions about an idea to keep the semantics of genfs in
> > the userspace, before sending a patch to expose the new genfs_seclabel_wildcard
> > kernel capability to libselinux users in polcaps.h as
> > POLICYDB_CAP_GENFS_SECLABEL_WILDCARD.
> >
> > As a background, we introduced the genfs wildcard feature to the kernel selinux
> > in https://lore.kernel.org/selinux/20250318083139.1515253-1-takayas@chromium.org/
> > (Thank you for your help and reviews!)
> > That enabled libselinux to use wildcards in genfs rules. There we changed the
> > semantics of genfs with the capability enabled in the kernel space from prefix
> > match to exact match with wildcards for kernel implementation simplicity.
> >
> > I'm wondering whether we can keep the user-facing semantics of (genfscon ...)
> > statements in CIL files in the following way.
> >
> > When secilc compiles a (genfscon ...) statement to the kernel binary format, it
> > adds a following `*` to the compiled kernel genfscon statement if the input has
> > (policycap genfs_seclabel_wildcard). If the input doesn't have one, secilc does
> > not add any following `*`. That keeps the behavior of (genfscon ...) in CIL
> > from the user perspective with and without the new wildcard capability. This is
> > similar to what our first kernel patch did, but done in the userspace by secilc
> > this time. So, the (genfscon ...) keeps the backward compatibility of prefix
> > match for libselinux users, while keeping the kernel implementation simple.
> > That would allow users to keep existing rules without modification.
> >
> > I'd like to hear your opinions.
>

I agree with this approach. It should only be adding it when writing
the kernel binary policy.

> (added James to cc for the secilc question)
>
> I'm assuming you mean libsepol rather than libselinux. I could be
> wrong, but I believe that in general policy capabilities are only
> declared once in the policy and typically in the base module, and
> those settings are then applied globally to all policy modules. While
> you can put one in a non-base module, it still has a global effect on
> the final policy. Putting a policycap statement into every CIL module
> that wants this behavior would possibly trigger an error (not sure
> how/if libsepol/secilc handles duplicate policycap statements) and
> regardless would enable it for the entire policy.

The policy capability can only be declared once. It will give an error
if there is a duplicate.

But since the CIL modules are not compiled individually, it doesn't
matter where the policy capability is declared. CIL doesn't have the
concept of a base module, all modules are equal. Since Refpolicy
modules are converted to CIL in the policy infrastructure, there is a
base module, but that is because Refpolicy has the concept of a base
module, not because CIL does.

Jim

Re: [RFC] selinux: Keep genfscon prefix match semantics in userspace for wildcard

[Stephen Smalley]

On Mon, May 12, 2025 at 10:31 AM James Carter <jwcart2@gmail.com> wrote:
>
> On Fri, May 9, 2025 at 2:23 PM Stephen Smalley
> <stephen.smalley.work@gmail.com> wrote:
> >
> > On Thu, May 8, 2025 at 10:50 PM Takaya Saeki <takayas@chromium.org> wrote:
> > >
> > > Hello Stephen, Paul, and all libselinux maintainers.
> > >
> > > I'd like to ask your opinions about an idea to keep the semantics of genfs in
> > > the userspace, before sending a patch to expose the new genfs_seclabel_wildcard
> > > kernel capability to libselinux users in polcaps.h as
> > > POLICYDB_CAP_GENFS_SECLABEL_WILDCARD.
> > >
> > > As a background, we introduced the genfs wildcard feature to the kernel selinux
> > > in https://lore.kernel.org/selinux/20250318083139.1515253-1-takayas@chromium.org/
> > > (Thank you for your help and reviews!)
> > > That enabled libselinux to use wildcards in genfs rules. There we changed the
> > > semantics of genfs with the capability enabled in the kernel space from prefix
> > > match to exact match with wildcards for kernel implementation simplicity.
> > >
> > > I'm wondering whether we can keep the user-facing semantics of (genfscon ...)
> > > statements in CIL files in the following way.
> > >
> > > When secilc compiles a (genfscon ...) statement to the kernel binary format, it
> > > adds a following `*` to the compiled kernel genfscon statement if the input has
> > > (policycap genfs_seclabel_wildcard). If the input doesn't have one, secilc does
> > > not add any following `*`. That keeps the behavior of (genfscon ...) in CIL
> > > from the user perspective with and without the new wildcard capability. This is
> > > similar to what our first kernel patch did, but done in the userspace by secilc
> > > this time. So, the (genfscon ...) keeps the backward compatibility of prefix
> > > match for libselinux users, while keeping the kernel implementation simple.
> > > That would allow users to keep existing rules without modification.
> > >
> > > I'd like to hear your opinions.
> >
>
> I agree with this approach. It should only be adding it when writing
> the kernel binary policy.
>
> > (added James to cc for the secilc question)
> >
> > I'm assuming you mean libsepol rather than libselinux. I could be
> > wrong, but I believe that in general policy capabilities are only
> > declared once in the policy and typically in the base module, and
> > those settings are then applied globally to all policy modules. While
> > you can put one in a non-base module, it still has a global effect on
> > the final policy. Putting a policycap statement into every CIL module
> > that wants this behavior would possibly trigger an error (not sure
> > how/if libsepol/secilc handles duplicate policycap statements) and
> > regardless would enable it for the entire policy.
>
> The policy capability can only be declared once. It will give an error
> if there is a duplicate.
>
> But since the CIL modules are not compiled individually, it doesn't
> matter where the policy capability is declared. CIL doesn't have the
> concept of a base module, all modules are equal. Since Refpolicy
> modules are converted to CIL in the policy infrastructure, there is a
> base module, but that is because Refpolicy has the concept of a base
> module, not because CIL does.

I think the problem is that there are multiple CIL modules shipped in
Android (e.g. vendor, platform, oem, ...) and more than one of them
might contain this policycap statement to indicate that its genfscon
statements should be interpreted in this manner. So the final combined
policy that is fed to secilc could end up with duplicates unless they
filter them out, or secilc is modified to ignore dups.

Re: [RFC] selinux: Keep genfscon prefix match semantics in userspace for wildcard

[James Carter]

On Mon, May 12, 2025 at 10:47 AM Stephen Smalley
<stephen.smalley.work@gmail.com> wrote:
>
> On Mon, May 12, 2025 at 10:31 AM James Carter <jwcart2@gmail.com> wrote:
> >
> > On Fri, May 9, 2025 at 2:23 PM Stephen Smalley
> > <stephen.smalley.work@gmail.com> wrote:
> > >
> > > On Thu, May 8, 2025 at 10:50 PM Takaya Saeki <takayas@chromium.org> wrote:
> > > >
> > > > Hello Stephen, Paul, and all libselinux maintainers.
> > > >
> > > > I'd like to ask your opinions about an idea to keep the semantics of genfs in
> > > > the userspace, before sending a patch to expose the new genfs_seclabel_wildcard
> > > > kernel capability to libselinux users in polcaps.h as
> > > > POLICYDB_CAP_GENFS_SECLABEL_WILDCARD.
> > > >
> > > > As a background, we introduced the genfs wildcard feature to the kernel selinux
> > > > in https://lore.kernel.org/selinux/20250318083139.1515253-1-takayas@chromium.org/
> > > > (Thank you for your help and reviews!)
> > > > That enabled libselinux to use wildcards in genfs rules. There we changed the
> > > > semantics of genfs with the capability enabled in the kernel space from prefix
> > > > match to exact match with wildcards for kernel implementation simplicity.
> > > >
> > > > I'm wondering whether we can keep the user-facing semantics of (genfscon ...)
> > > > statements in CIL files in the following way.
> > > >
> > > > When secilc compiles a (genfscon ...) statement to the kernel binary format, it
> > > > adds a following `*` to the compiled kernel genfscon statement if the input has
> > > > (policycap genfs_seclabel_wildcard). If the input doesn't have one, secilc does
> > > > not add any following `*`. That keeps the behavior of (genfscon ...) in CIL
> > > > from the user perspective with and without the new wildcard capability. This is
> > > > similar to what our first kernel patch did, but done in the userspace by secilc
> > > > this time. So, the (genfscon ...) keeps the backward compatibility of prefix
> > > > match for libselinux users, while keeping the kernel implementation simple.
> > > > That would allow users to keep existing rules without modification.
> > > >
> > > > I'd like to hear your opinions.
> > >
> >
> > I agree with this approach. It should only be adding it when writing
> > the kernel binary policy.
> >
> > > (added James to cc for the secilc question)
> > >
> > > I'm assuming you mean libsepol rather than libselinux. I could be
> > > wrong, but I believe that in general policy capabilities are only
> > > declared once in the policy and typically in the base module, and
> > > those settings are then applied globally to all policy modules. While
> > > you can put one in a non-base module, it still has a global effect on
> > > the final policy. Putting a policycap statement into every CIL module
> > > that wants this behavior would possibly trigger an error (not sure
> > > how/if libsepol/secilc handles duplicate policycap statements) and
> > > regardless would enable it for the entire policy.
> >
> > The policy capability can only be declared once. It will give an error
> > if there is a duplicate.
> >
> > But since the CIL modules are not compiled individually, it doesn't
> > matter where the policy capability is declared. CIL doesn't have the
> > concept of a base module, all modules are equal. Since Refpolicy
> > modules are converted to CIL in the policy infrastructure, there is a
> > base module, but that is because Refpolicy has the concept of a base
> > module, not because CIL does.
>
> I think the problem is that there are multiple CIL modules shipped in
> Android (e.g. vendor, platform, oem, ...) and more than one of them
> might contain this policycap statement to indicate that its genfscon
> statements should be interpreted in this manner. So the final combined
> policy that is fed to secilc could end up with duplicates unless they
> filter them out, or secilc is modified to ignore dups.

I don't think it would be a problem to ignore duplicate policycap
statements. It should be a fairly small patch.
Jim

Re: [RFC] selinux: Keep genfscon prefix match semantics in userspace for wildcard

[Inseob Kim]

On Tue, May 13, 2025 at 1:57 AM James Carter <jwcart2@gmail.com> wrote:
>
> On Mon, May 12, 2025 at 10:47 AM Stephen Smalley
> <stephen.smalley.work@gmail.com> wrote:
> >
> > On Mon, May 12, 2025 at 10:31 AM James Carter <jwcart2@gmail.com> wrote:
> > >
> > > On Fri, May 9, 2025 at 2:23 PM Stephen Smalley
> > > <stephen.smalley.work@gmail.com> wrote:
> > > >
> > > > On Thu, May 8, 2025 at 10:50 PM Takaya Saeki <takayas@chromium.org> wrote:
> > > > >
> > > > > Hello Stephen, Paul, and all libselinux maintainers.
> > > > >
> > > > > I'd like to ask your opinions about an idea to keep the semantics of genfs in
> > > > > the userspace, before sending a patch to expose the new genfs_seclabel_wildcard
> > > > > kernel capability to libselinux users in polcaps.h as
> > > > > POLICYDB_CAP_GENFS_SECLABEL_WILDCARD.
> > > > >
> > > > > As a background, we introduced the genfs wildcard feature to the kernel selinux
> > > > > in https://lore.kernel.org/selinux/20250318083139.1515253-1-takayas@chromium.org/
> > > > > (Thank you for your help and reviews!)
> > > > > That enabled libselinux to use wildcards in genfs rules. There we changed the
> > > > > semantics of genfs with the capability enabled in the kernel space from prefix
> > > > > match to exact match with wildcards for kernel implementation simplicity.
> > > > >
> > > > > I'm wondering whether we can keep the user-facing semantics of (genfscon ...)
> > > > > statements in CIL files in the following way.
> > > > >
> > > > > When secilc compiles a (genfscon ...) statement to the kernel binary format, it
> > > > > adds a following `*` to the compiled kernel genfscon statement if the input has
> > > > > (policycap genfs_seclabel_wildcard). If the input doesn't have one, secilc does
> > > > > not add any following `*`. That keeps the behavior of (genfscon ...) in CIL
> > > > > from the user perspective with and without the new wildcard capability. This is
> > > > > similar to what our first kernel patch did, but done in the userspace by secilc
> > > > > this time. So, the (genfscon ...) keeps the backward compatibility of prefix
> > > > > match for libselinux users, while keeping the kernel implementation simple.
> > > > > That would allow users to keep existing rules without modification.
> > > > >
> > > > > I'd like to hear your opinions.
> > > >
> > >
> > > I agree with this approach. It should only be adding it when writing
> > > the kernel binary policy.
> > >
> > > > (added James to cc for the secilc question)
> > > >
> > > > I'm assuming you mean libsepol rather than libselinux. I could be
> > > > wrong, but I believe that in general policy capabilities are only
> > > > declared once in the policy and typically in the base module, and
> > > > those settings are then applied globally to all policy modules. While
> > > > you can put one in a non-base module, it still has a global effect on
> > > > the final policy. Putting a policycap statement into every CIL module
> > > > that wants this behavior would possibly trigger an error (not sure
> > > > how/if libsepol/secilc handles duplicate policycap statements) and
> > > > regardless would enable it for the entire policy.

We keep backward compatibility of (genfscon ...) so they'll always be
prefix-matched. For example, (policycap genfs_seclabel_wildcard) in
./vendor/etc/selinux/vendor_sepolicy.cil won't affect how genfscon
statements in /system/etc/selinux/plat_sepolicy.cil work.

> > >
> > > The policy capability can only be declared once. It will give an error
> > > if there is a duplicate.
> > >
> > > But since the CIL modules are not compiled individually, it doesn't
> > > matter where the policy capability is declared. CIL doesn't have the
> > > concept of a base module, all modules are equal. Since Refpolicy
> > > modules are converted to CIL in the policy infrastructure, there is a
> > > base module, but that is because Refpolicy has the concept of a base
> > > module, not because CIL does.
> >
> > I think the problem is that there are multiple CIL modules shipped in
> > Android (e.g. vendor, platform, oem, ...) and more than one of them
> > might contain this policycap statement to indicate that its genfscon
> > statements should be interpreted in this manner. So the final combined
> > policy that is fed to secilc could end up with duplicates unless they
> > filter them out, or secilc is modified to ignore dups.
>
> I don't think it would be a problem to ignore duplicate policycap
> statements. It should be a fairly small patch.
> Jim

So, simply supporting this (allowing duplicated policycap statements)
will be enough even for the Android case.

-- 
Inseob Kim | Software Engineer | inseob@google.com

Re: [RFC] selinux: Keep genfscon prefix match semantics in userspace for wildcard

[Takaya Saeki]

On Tue, May 13, 2025 at 5:44 PM Inseob Kim <inseob@google.com> wrote:
>
> On Tue, May 13, 2025 at 1:57 AM James Carter <jwcart2@gmail.com> wrote:
> >
> > On Mon, May 12, 2025 at 10:47 AM Stephen Smalley
> > <stephen.smalley.work@gmail.com> wrote:
> > >
> > > On Mon, May 12, 2025 at 10:31 AM James Carter <jwcart2@gmail.com> wrote:
> > > >
> > > > On Fri, May 9, 2025 at 2:23 PM Stephen Smalley
> > > > <stephen.smalley.work@gmail.com> wrote:
> > > > >
> > > > > On Thu, May 8, 2025 at 10:50 PM Takaya Saeki <takayas@chromium.org> wrote:
> > > > > >
> > > > > > Hello Stephen, Paul, and all libselinux maintainers.
> > > > > >
> > > > > > I'd like to ask your opinions about an idea to keep the semantics of genfs in
> > > > > > the userspace, before sending a patch to expose the new genfs_seclabel_wildcard
> > > > > > kernel capability to libselinux users in polcaps.h as
> > > > > > POLICYDB_CAP_GENFS_SECLABEL_WILDCARD.
> > > > > >
> > > > > > As a background, we introduced the genfs wildcard feature to the kernel selinux
> > > > > > in https://lore.kernel.org/selinux/20250318083139.1515253-1-takayas@chromium.org/
> > > > > > (Thank you for your help and reviews!)
> > > > > > That enabled libselinux to use wildcards in genfs rules. There we changed the
> > > > > > semantics of genfs with the capability enabled in the kernel space from prefix
> > > > > > match to exact match with wildcards for kernel implementation simplicity.
> > > > > >
> > > > > > I'm wondering whether we can keep the user-facing semantics of (genfscon ...)
> > > > > > statements in CIL files in the following way.
> > > > > >
> > > > > > When secilc compiles a (genfscon ...) statement to the kernel binary format, it
> > > > > > adds a following `*` to the compiled kernel genfscon statement if the input has
> > > > > > (policycap genfs_seclabel_wildcard). If the input doesn't have one, secilc does
> > > > > > not add any following `*`. That keeps the behavior of (genfscon ...) in CIL
> > > > > > from the user perspective with and without the new wildcard capability. This is
> > > > > > similar to what our first kernel patch did, but done in the userspace by secilc
> > > > > > this time. So, the (genfscon ...) keeps the backward compatibility of prefix
> > > > > > match for libselinux users, while keeping the kernel implementation simple.
> > > > > > That would allow users to keep existing rules without modification.
> > > > > >
> > > > > > I'd like to hear your opinions.
> > > > >
> > > >
> > > > I agree with this approach. It should only be adding it when writing
> > > > the kernel binary policy.
> > > >
> > > > > (added James to cc for the secilc question)
> > > > >
> > > > > I'm assuming you mean libsepol rather than libselinux. I could be

Yes, thanks for the correction.

> > > > > wrong, but I believe that in general policy capabilities are only
> > > > > declared once in the policy and typically in the base module, and
> > > > > those settings are then applied globally to all policy modules. While
> > > > > you can put one in a non-base module, it still has a global effect on
> > > > > the final policy. Putting a policycap statement into every CIL module
> > > > > that wants this behavior would possibly trigger an error (not sure
> > > > > how/if libsepol/secilc handles duplicate policycap statements) and
> > > > > regardless would enable it for the entire policy.
>
> We keep backward compatibility of (genfscon ...) so they'll always be
> prefix-matched. For example, (policycap genfs_seclabel_wildcard) in
> ./vendor/etc/selinux/vendor_sepolicy.cil won't affect how genfscon
> statements in /system/etc/selinux/plat_sepolicy.cil work.
>
> > > >
> > > > The policy capability can only be declared once. It will give an error
> > > > if there is a duplicate.
> > > >
> > > > But since the CIL modules are not compiled individually, it doesn't
> > > > matter where the policy capability is declared. CIL doesn't have the
> > > > concept of a base module, all modules are equal. Since Refpolicy
> > > > modules are converted to CIL in the policy infrastructure, there is a
> > > > base module, but that is because Refpolicy has the concept of a base
> > > > module, not because CIL does.
> > >
> > > I think the problem is that there are multiple CIL modules shipped in
> > > Android (e.g. vendor, platform, oem, ...) and more than one of them
> > > might contain this policycap statement to indicate that its genfscon
> > > statements should be interpreted in this manner. So the final combined
> > > policy that is fed to secilc could end up with duplicates unless they
> > > filter them out, or secilc is modified to ignore dups.
> >
> > I don't think it would be a problem to ignore duplicate policycap
> > statements. It should be a fairly small patch.
> > Jim
>
> So, simply supporting this (allowing duplicated policycap statements)
> will be enough even for the Android case.
>
> --
> Inseob Kim | Software Engineer | inseob@google.com

Thank you all, so I think the idea seems acceptable from both perspectives of
Refpolicy and Android. I'd like to ask whether we have any path to generate a
kernel binary policy that does not involve .cil intermediates and secilc in
practical environments. Is patching secilc (libsepol, to be precise)
sufficient? We know it's enough for Android, but is also true for Refpolicy
environments? There are a lot of se.* tools and I'm not sure if secilc always
plays the role.

Re: [RFC] selinux: Keep genfscon prefix match semantics in userspace for wildcard

[James Carter]

On Tue, May 13, 2025 at 5:34 AM Takaya Saeki <takayas@chromium.org> wrote:
>
> On Tue, May 13, 2025 at 5:44 PM Inseob Kim <inseob@google.com> wrote:
> >
> > On Tue, May 13, 2025 at 1:57 AM James Carter <jwcart2@gmail.com> wrote:
> > >
> > > On Mon, May 12, 2025 at 10:47 AM Stephen Smalley
> > > <stephen.smalley.work@gmail.com> wrote:
> > > >
> > > > On Mon, May 12, 2025 at 10:31 AM James Carter <jwcart2@gmail.com> wrote:
> > > > >
> > > > > On Fri, May 9, 2025 at 2:23 PM Stephen Smalley
> > > > > <stephen.smalley.work@gmail.com> wrote:
> > > > > >
> > > > > > On Thu, May 8, 2025 at 10:50 PM Takaya Saeki <takayas@chromium.org> wrote:
> > > > > > >
> > > > > > > Hello Stephen, Paul, and all libselinux maintainers.
> > > > > > >
> > > > > > > I'd like to ask your opinions about an idea to keep the semantics of genfs in
> > > > > > > the userspace, before sending a patch to expose the new genfs_seclabel_wildcard
> > > > > > > kernel capability to libselinux users in polcaps.h as
> > > > > > > POLICYDB_CAP_GENFS_SECLABEL_WILDCARD.
> > > > > > >
> > > > > > > As a background, we introduced the genfs wildcard feature to the kernel selinux
> > > > > > > in https://lore.kernel.org/selinux/20250318083139.1515253-1-takayas@chromium.org/
> > > > > > > (Thank you for your help and reviews!)
> > > > > > > That enabled libselinux to use wildcards in genfs rules. There we changed the
> > > > > > > semantics of genfs with the capability enabled in the kernel space from prefix
> > > > > > > match to exact match with wildcards for kernel implementation simplicity.
> > > > > > >
> > > > > > > I'm wondering whether we can keep the user-facing semantics of (genfscon ...)
> > > > > > > statements in CIL files in the following way.
> > > > > > >
> > > > > > > When secilc compiles a (genfscon ...) statement to the kernel binary format, it
> > > > > > > adds a following `*` to the compiled kernel genfscon statement if the input has
> > > > > > > (policycap genfs_seclabel_wildcard). If the input doesn't have one, secilc does
> > > > > > > not add any following `*`. That keeps the behavior of (genfscon ...) in CIL
> > > > > > > from the user perspective with and without the new wildcard capability. This is
> > > > > > > similar to what our first kernel patch did, but done in the userspace by secilc
> > > > > > > this time. So, the (genfscon ...) keeps the backward compatibility of prefix
> > > > > > > match for libselinux users, while keeping the kernel implementation simple.
> > > > > > > That would allow users to keep existing rules without modification.
> > > > > > >
> > > > > > > I'd like to hear your opinions.
> > > > > >
> > > > >
> > > > > I agree with this approach. It should only be adding it when writing
> > > > > the kernel binary policy.
> > > > >
> > > > > > (added James to cc for the secilc question)
> > > > > >
> > > > > > I'm assuming you mean libsepol rather than libselinux. I could be
>
> Yes, thanks for the correction.
>
> > > > > > wrong, but I believe that in general policy capabilities are only
> > > > > > declared once in the policy and typically in the base module, and
> > > > > > those settings are then applied globally to all policy modules. While
> > > > > > you can put one in a non-base module, it still has a global effect on
> > > > > > the final policy. Putting a policycap statement into every CIL module
> > > > > > that wants this behavior would possibly trigger an error (not sure
> > > > > > how/if libsepol/secilc handles duplicate policycap statements) and
> > > > > > regardless would enable it for the entire policy.
> >
> > We keep backward compatibility of (genfscon ...) so they'll always be
> > prefix-matched. For example, (policycap genfs_seclabel_wildcard) in
> > ./vendor/etc/selinux/vendor_sepolicy.cil won't affect how genfscon
> > statements in /system/etc/selinux/plat_sepolicy.cil work.
> >
> > > > >
> > > > > The policy capability can only be declared once. It will give an error
> > > > > if there is a duplicate.
> > > > >
> > > > > But since the CIL modules are not compiled individually, it doesn't
> > > > > matter where the policy capability is declared. CIL doesn't have the
> > > > > concept of a base module, all modules are equal. Since Refpolicy
> > > > > modules are converted to CIL in the policy infrastructure, there is a
> > > > > base module, but that is because Refpolicy has the concept of a base
> > > > > module, not because CIL does.
> > > >
> > > > I think the problem is that there are multiple CIL modules shipped in
> > > > Android (e.g. vendor, platform, oem, ...) and more than one of them
> > > > might contain this policycap statement to indicate that its genfscon
> > > > statements should be interpreted in this manner. So the final combined
> > > > policy that is fed to secilc could end up with duplicates unless they
> > > > filter them out, or secilc is modified to ignore dups.
> > >
> > > I don't think it would be a problem to ignore duplicate policycap
> > > statements. It should be a fairly small patch.
> > > Jim
> >
> > So, simply supporting this (allowing duplicated policycap statements)
> > will be enough even for the Android case.
> >
> > --
> > Inseob Kim | Software Engineer | inseob@google.com
>
> Thank you all, so I think the idea seems acceptable from both perspectives of
> Refpolicy and Android. I'd like to ask whether we have any path to generate a
> kernel binary policy that does not involve .cil intermediates and secilc in
> practical environments. Is patching secilc (libsepol, to be precise)
> sufficient? We know it's enough for Android, but is also true for Refpolicy
> environments? There are a lot of se.* tools and I'm not sure if secilc always
> plays the role.

checkpolicy is the other way to generate a kernel binary policy, but
if you patch libsepol (specifically, genfs_write() in write.c) you'll
take care of both at the same time.
Jim

Re: [RFC] selinux: Keep genfscon prefix match semantics in userspace for wildcard

[Takaya Saeki]

On Tue, May 13, 2025 at 10:08 PM James Carter <jwcart2@gmail.com> wrote:
>
> On Tue, May 13, 2025 at 5:34 AM Takaya Saeki <takayas@chromium.org> wrote:
> >
> > On Tue, May 13, 2025 at 5:44 PM Inseob Kim <inseob@google.com> wrote:
> > >
> > > On Tue, May 13, 2025 at 1:57 AM James Carter <jwcart2@gmail.com> wrote:
> > > >
> > > > On Mon, May 12, 2025 at 10:47 AM Stephen Smalley
> > > > <stephen.smalley.work@gmail.com> wrote:
> > > > >
> > > > > On Mon, May 12, 2025 at 10:31 AM James Carter <jwcart2@gmail.com> wrote:
> > > > > >
> > > > > > On Fri, May 9, 2025 at 2:23 PM Stephen Smalley
> > > > > > <stephen.smalley.work@gmail.com> wrote:
> > > > > > >
> > > > > > > On Thu, May 8, 2025 at 10:50 PM Takaya Saeki <takayas@chromium.org> wrote:
> > > > > > > >
> > > > > > > > Hello Stephen, Paul, and all libselinux maintainers.
> > > > > > > >
> > > > > > > > I'd like to ask your opinions about an idea to keep the semantics of genfs in
> > > > > > > > the userspace, before sending a patch to expose the new genfs_seclabel_wildcard
> > > > > > > > kernel capability to libselinux users in polcaps.h as
> > > > > > > > POLICYDB_CAP_GENFS_SECLABEL_WILDCARD.
> > > > > > > >
> > > > > > > > As a background, we introduced the genfs wildcard feature to the kernel selinux
> > > > > > > > in https://lore.kernel.org/selinux/20250318083139.1515253-1-takayas@chromium.org/
> > > > > > > > (Thank you for your help and reviews!)
> > > > > > > > That enabled libselinux to use wildcards in genfs rules. There we changed the
> > > > > > > > semantics of genfs with the capability enabled in the kernel space from prefix
> > > > > > > > match to exact match with wildcards for kernel implementation simplicity.
> > > > > > > >
> > > > > > > > I'm wondering whether we can keep the user-facing semantics of (genfscon ...)
> > > > > > > > statements in CIL files in the following way.
> > > > > > > >
> > > > > > > > When secilc compiles a (genfscon ...) statement to the kernel binary format, it
> > > > > > > > adds a following `*` to the compiled kernel genfscon statement if the input has
> > > > > > > > (policycap genfs_seclabel_wildcard). If the input doesn't have one, secilc does
> > > > > > > > not add any following `*`. That keeps the behavior of (genfscon ...) in CIL
> > > > > > > > from the user perspective with and without the new wildcard capability. This is
> > > > > > > > similar to what our first kernel patch did, but done in the userspace by secilc
> > > > > > > > this time. So, the (genfscon ...) keeps the backward compatibility of prefix
> > > > > > > > match for libselinux users, while keeping the kernel implementation simple.
> > > > > > > > That would allow users to keep existing rules without modification.
> > > > > > > >
> > > > > > > > I'd like to hear your opinions.
> > > > > > >
> > > > > >
> > > > > > I agree with this approach. It should only be adding it when writing
> > > > > > the kernel binary policy.
> > > > > >
> > > > > > > (added James to cc for the secilc question)
> > > > > > >
> > > > > > > I'm assuming you mean libsepol rather than libselinux. I could be
> >
> > Yes, thanks for the correction.
> >
> > > > > > > wrong, but I believe that in general policy capabilities are only
> > > > > > > declared once in the policy and typically in the base module, and
> > > > > > > those settings are then applied globally to all policy modules. While
> > > > > > > you can put one in a non-base module, it still has a global effect on
> > > > > > > the final policy. Putting a policycap statement into every CIL module
> > > > > > > that wants this behavior would possibly trigger an error (not sure
> > > > > > > how/if libsepol/secilc handles duplicate policycap statements) and
> > > > > > > regardless would enable it for the entire policy.
> > >
> > > We keep backward compatibility of (genfscon ...) so they'll always be
> > > prefix-matched. For example, (policycap genfs_seclabel_wildcard) in
> > > ./vendor/etc/selinux/vendor_sepolicy.cil won't affect how genfscon
> > > statements in /system/etc/selinux/plat_sepolicy.cil work.
> > >
> > > > > >
> > > > > > The policy capability can only be declared once. It will give an error
> > > > > > if there is a duplicate.
> > > > > >
> > > > > > But since the CIL modules are not compiled individually, it doesn't
> > > > > > matter where the policy capability is declared. CIL doesn't have the
> > > > > > concept of a base module, all modules are equal. Since Refpolicy
> > > > > > modules are converted to CIL in the policy infrastructure, there is a
> > > > > > base module, but that is because Refpolicy has the concept of a base
> > > > > > module, not because CIL does.
> > > > >
> > > > > I think the problem is that there are multiple CIL modules shipped in
> > > > > Android (e.g. vendor, platform, oem, ...) and more than one of them
> > > > > might contain this policycap statement to indicate that its genfscon
> > > > > statements should be interpreted in this manner. So the final combined
> > > > > policy that is fed to secilc could end up with duplicates unless they
> > > > > filter them out, or secilc is modified to ignore dups.
> > > >
> > > > I don't think it would be a problem to ignore duplicate policycap
> > > > statements. It should be a fairly small patch.
> > > > Jim
> > >
> > > So, simply supporting this (allowing duplicated policycap statements)
> > > will be enough even for the Android case.
> > >
> > > --
> > > Inseob Kim | Software Engineer | inseob@google.com
> >
> > Thank you all, so I think the idea seems acceptable from both perspectives of
> > Refpolicy and Android. I'd like to ask whether we have any path to generate a
> > kernel binary policy that does not involve .cil intermediates and secilc in
> > practical environments. Is patching secilc (libsepol, to be precise)
> > sufficient? We know it's enough for Android, but is also true for Refpolicy
> > environments? There are a lot of se.* tools and I'm not sure if secilc always
> > plays the role.
>
> checkpolicy is the other way to generate a kernel binary policy, but
> if you patch libsepol (specifically, genfs_write() in write.c) you'll
> take care of both at the same time.
> Jim

Great, then we will send actual patches soon. Thank you all for your
valuable input!