On Tue, Jul 14, 2020 at 6:42 PM Mike Palmiotto <mike.palmiotto@xxxxxxxxxxxxxxx> wrote: > > On Tue, Jul 14, 2020 at 5:35 PM Stephen Smalley > <stephen.smalley.work@xxxxxxxxx> wrote: > > > > On Tue, Jul 14, 2020 at 5:20 PM Mike Palmiotto > > <mike.palmiotto@xxxxxxxxxxxxxxx> wrote: <snip> > > > Do you think we should go ahead and completely swap in sestatus? I was > > > just worried about breaking userspace object managers that are > > > currently using netlink threads by default, for instance > > > systemd-dbusd. I can spend some more time getting those to work with > > > the status page if you think that's worthwhile. > > > > I'd be interested in understanding the impact of such a change on > > existing userspace object managers. If we can switch the default > > behavior for applications that are not explicitly using > > avc_netlink_*() interfaces themselves (e.g. they are only using > > selinux_check_access or avc_has_perm), then that would be beneficial > > since I think it fully removes the need for a system call on the AVC > > cache-hit code path. > > I'll have to do a bit of digging to see how this will affect dbus, et > al. On first blush, it looks like they're just doing > avc_netlink_check_nb() in their watch thread. Presumably other object > managers are doing something similar so we would just need to make > sure there is a netlink fd available. So it looks like dbus (at least) is directly checking for a netlink socket[1], so just doing away with the avc_netlink_open call wouldn't work out. My thinking is we have two options: 1) Add a new seopt to use sestatus and let userspace object managers opt-in 2) Call both selinux_status_open and avc_netlink_open in avc_init_internal. This would satisfy the hard requirement for a netlink socket. Then we can default to using sestatus in all of the netlink processing paths, as you suggested in your last reply. We could Option 2 seems better from the standpoint of using sestatus by default, but it looks like recvfrom will never be called and the messages will just sit in kernel memory. I'm inclined to go with option 1 at this point. [1] https://gitlab.freedesktop.org/dbus/dbus/-/blob/master/bus/selinux.c#L269 -- Mike Palmiotto https://crunchydata.com
