On Wed, Aug 21, 2024 at 5:54 AM Paul Moore <paul@xxxxxxxxxxxxxx> wrote:
>
> On Tue, Aug 20, 2024 at 2:02 PM Stephen Smalley
> <stephen.smalley.work@xxxxxxxxx> wrote:
>
> Thank you for reviving this patch.
> Do you have a corresponding userspace patch? And for extra credit, a
> selinux-testsuite patch?
>
Thank you for the quick response and initial feedback. I've just sent
the libsepol patches for userland on this mailing list.
For selinux-testsuite, an issue I came across while testing is that
the policy capabilities cannot be updated (that is, only the
capabilities from the original host policy are active). I am not sure
if I got that right or if there is any obvious solution (except
toggling on the new capability in Fedora).
I'm still hoping to get the extra credits by: updating the selinux
notebook documentation as well as updating setools (for sesearch
support). :) I will send pull requests if these patches get accepted.
> > On Mon, Aug 19, 2024 at 8:27 PM Thiébaud Weksteen <tweek@xxxxxxxxxx> wrote:
> > > ---
> > > diff --git a/security/selinux/include/classmap.h b/security/selinux/include/classmap.h
> > > index 7229c9bf6c27..c95bf89c9ce5 100644
> > > --- a/security/selinux/include/classmap.h
> > > +++ b/security/selinux/include/classmap.h
> > > @@ -96,17 +96,17 @@ const struct security_class_mapping secclass_map[] = {
> > > { "shm", { COMMON_IPC_PERMS, "lock", NULL } },
> > > { "ipc", { COMMON_IPC_PERMS, NULL } },
> > > { "netlink_route_socket",
> > > - { COMMON_SOCK_PERMS, "nlmsg_read", "nlmsg_write", NULL } },
> > > + { COMMON_SOCK_PERMS, "nlmsg", "nlmsg_read", "nlmsg_write", NULL } },
> >
> > I would just add the "nlmsg" permission to the end of the list before
> > the NULL for each class.
> > Doesn't matter as much anymore since the dynamic class/perm mapping
> > support was added but generally we avoid perturbing the
> > class/permission bit assignments unless there is a good reason to do
> > so. Feel free to wait to see if Paul agrees since your code will work
> > as is.
>
> I haven't had a chance to look at the rest of the patch yet, but I
> agree with Stephen. Generally speaking we should strive to only add
> new perms to the end of the list, I'd hate to hit some odd corner case
> on someone's system simply because we thought we'd tempt fate and
> something to the front of the list ;)
>
Ack, I'll fix that in the next version. I'll wait for a bit in case
you or someone else has more feedback.
Thanks
