Re: userspace object manager confused

[Stephen Smalley <sds@tycho.nsa.gov>]

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.