On Fri, 2017-03-31 at 09:25 -0400, Stephen Smalley wrote: > On Fri, 2017-03-31 at 14:09 +0200, Dominick Grift wrote: > > I vaguely recall that we discussed this issue or at least that i > > mentioned it here but i can't recall the outcome if any: > > > > So today on my rawhide system i noticed that i somehow forgot to > > add > > support for the smc_socket class (i suspect that is part of the > > extended socket class patches) > > > > I added the class (which i suppose is unordered like the othe > > extended socket classes) but as soon as I loaded up the policy with > > the new unordered smc_socket class the system became unusable. > > > > This is because the dbus object manager became confused due to my > > adding a new (unordered) class at runtime, and that the dbus class > > was no longer working. > > > > Modern systems heavily rely on dbus at the heart and so it is > > undesire-able that this happens. > > > > A reboot clears this issue up but adding (unordered) classes at > > runtime should not cause these issues i suspect > > dbusd doesn't use selinux_check_access() and therefore does not yet > support reordering of their classes/permissions at runtime. The same > is true of all userspace object managers created before > selinux_check_access() was introduced - anything that directly calls > security_compute_av() or avc_has_perm(). dbusd does call > selinux_set_mapping() at startup, so it can correctly handle > reordering of classes/permissions across restarts, but not while it > is > running. Calling selinux_set_mapping() again upon policy reloads > (e.g. > from policy_reload_callback() if (event == AVC_CALLBACK_RESET) before > returning) may fix this problem, but requires proper locking. Even > better would be to rid the dbusd selinux implementation of threading > entirely, see https://bugs.freedesktop.org/show_bug.cgi?id=92831#c4 > > smc_socket was added by the kernel developers as part of the merge > with > net-next since we now trigger a build failure in the kernel if any > new > address families are introduced without adding a corresponding > security > class (so that SELinux always supports a separate class per network > address family going forward). So there have been no policy patches > submitted yet to define it in refpolicy even AFAIK. > > [1] https://github.com/SELinuxProject/selinux/issues/34 BTW, I'm not sure what you did to trigger the problem. When I tested the extended socket classes, I added them to my running policy via a CIL module like this: (policycap extended_socket_class) (classcommon sctp_socket socket) (class sctp_socket (node_bind)) <snip> (classcommon qipcrtr_socket socket) (class qipcrtr_socket ()) (classorder (unordered sctp_socket icmp_socket ax25_socket ipx_socket netrom_socket bridge_socket atmpvc_socket x25_socket rose_socket decnet_socket atmsvc_socket rds_socket irda_socket pppox_socket llc_socket ib_socket mpls_socket can_socket tipc_socket bluetooth_socket iucv_socket rxrpc_socket isdn_socket phonet_socket ieee802154_socket caif_socket alg_socket nfc_socket vsock_socket kcm_socket qipcrtr_socket)) The classorder statement at the end ensured that they were appended to the end of the class list and therefore did not break anything. _______________________________________________ Selinux mailing list Selinux@xxxxxxxxxxxxx To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx. To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.
