Re: [PATCH] selinux: support wildcard match in genfscon

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Dec 16, 2024 at 1:50 AM Takaya Saeki <takayas@xxxxxxxxxxxx> wrote:
>
> > > Currently, genfscon rules perform prefix matching (e.g., `/sys/dev` matches
> > > `/sys/devices`). Directly using `match_wildcard()` would not preserve this
> > > behavior, as it does full match. To maintain compatibility with this existing
> > > prefix-matching behavior, the trailing '*' is added.
> >
> > Yes, the existing genfscon handling does prefix matching, likely as an
> > easy workaround for the lack of wildcard matching, so if we move to
> > properly supporting wildcard matching, and the policy explicitly opts
> > into using this new capability, I'd rather just see the policy do the
> > right thing with wildcards.  It might mean more work to convert the
> > policy, but this should be easier to understand and more consistent
> > than silently adding a '*' wildcard at the end of every path when the
> > path matching supports explicit wildcards anywhere in the path.
>
> Thanks for clarification. Backward incompatibility will make it challenging to
> enable the new wildcard feature for Android or any systems that allow users to
> define genfscon rules in addition to the system policy, since enabling it
> breaks existing user-defined policies. It would be nice we can keep the
> existing rules working.

On Mon, Dec 16, 2024 at 9:06 AM Stephen Smalley
<stephen.smalley.work@xxxxxxxxx> wrote:
> I think the problem with that approach is that it assumes that the
> entire policy can be updated at one time.

A policy capability applies to the entire loaded policy, not just a
portion.  If one is going to enable a new policy capability, there is
a certain responsibility to ensure that the entirety of the policy has
been updated and is correct.  If all that is required to convert older
policies is to add a '*' at the end of genfscon pathnames, that can be
easily done in userspace (and should be done in userspace).

We really shouldn't have compatibility hacks when enabling policy
capabilities, policy capabilities *are* the compatibility hack by
allowing systems to continue to operate in the legacy mode until such
time as the policy has been converted.

-- 
paul-moore.com





[Index of Archives]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux