Re: userspace object manager confused

[James Carter <jwcart2@tycho.nsa.gov>]

On 03/31/2017 10:17 AM, Dominick Grift wrote:
> On Fri, Mar 31, 2017 at 10:12:50AM -0400, James Carter wrote:
>> On 03/31/2017 10:10 AM, Stephen Smalley wrote:
>>> On Fri, 2017-03-31 at 15:59 +0200, Dominick Grift wrote:
>>>> On Fri, Mar 31, 2017 at 09:53:26AM -0400, Stephen Smalley wrote:
>>>>> On Fri, 2017-03-31 at 15:36 +0200, Dominick Grift wrote:
>>>>>> On Fri, Mar 31, 2017 at 09:30:56AM -0400, Stephen Smalley wrote:
>>>>>>> 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=92
>>>>>>>> 831#
>>>>>>>> c4
>>>>>>
>>>>>> Thank you, I suppose i should take this to them then.
>>>>>
>>>>> No, someone who uses SELinux will need to develop a patch and test
>>>>> it
>>>>> for them; dbusd maintainer doesn't use SELinux himself.
>>>>>
>>>>> Looks like I'm also wrong about being able to call
>>>>> selinux_set_mapping() from an AVC callback, since
>>>>> selinux_set_mapping()
>>>>> itself calls avc_reset() to flush any cache entries before
>>>>> reloading
>>>>> the mapping, so that would produce infinite
>>>>> recursion.  Sigh.  Could
>>>>> change selinux_set_mapping() to not do that in libselinux, but that
>>>>> won't help on existing releases.  Maybe we should just convert it
>>>>> over
>>>>> to using selinux_check_access() and drop all direct usage of the
>>>>> AVC.
>>>>>
>>>>>>>>
>>>>>>>> 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
>>>>>>
>>>>>> So i suppose its an unordered class? or do i have to order this
>>>>>> one
>>>>>> to avoid future issues?
>>>>>>
>>>>>>>
>>>>>>> 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:
>>>>>>
>>>>>> Well i just added this commit (ignore the typo in the name) which
>>>>>> adds the new class to the unordered socket list
>>>>>>
>>>>>> https://github.com/DefenSec/dssp2-base/commit/5e3ada7d12525c8c659
>>>>>> f347
>>>>>> 863f09ec9caeceb56
>>>>>>
>>>>>> then i built rpms using this script:
>>>>>>
>>>>>> https://github.com/DefenSec/dssp2-standard/blob/master/support/rp
>>>>>> m/ds
>>>>>> sp2-standard.sh
>>>>>>
>>>>>> and just rpm -Uvh the new rpm
>>>>>>
>>>>>>>
>>>>>>> (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.
>>>>>>>
>>>>>
>>>>> Looks like you failed to include a classorder statement for it as I
>>>>> did
>>>>> above.  That's still required to avoid breaking legacy userspace
>>>>> object
>>>>> managers.
>>>>>
>>>>>
>>>>
>>>> No I added "scm_socket" (i renamed it later to smc_socket) to my list
>>>> or unordered classorder:
>>>>
>>>> ;
>>>> ; Class order of unordered Linux access vectors
>>>> ;
>>>>
>>>> (classorder
>>>>     (unordered
>>>>         alg_socket
>>>>         atmpvc_socket
>>>>         atmsvc_socket
>>>>         ax25_socket
>>>>         bluetooth_socket
>>>>         caif_socket
>>>>         can_socket
>>>>         decnet_socket
>>>>         icmp_socket
>>>>         ieee802154_socket
>>>>         ipx_socket
>>>>         irda_socket
>>>>         isdn_socket
>>>>         iucv_socket
>>>>         kcm_socket
>>>>         llc_socket
>>>>         netrom_socket
>>>>         nfc_socket
>>>>         phonet_socket
>>>>         pppox_socket
>>>>         qipcrtr_socket
>>>>         rds_socket
>>>>         rose_socket
>>>>         rxrpc_socket
>>>>         scm_socket
>>>>         sctp_socket
>>>>         tipc_socket
>>>>         vsock_socket
>>>>         x25_socket
>>>>     )
>>>> )
>>>

You are reordering classes here since you didn't put scm_socket at the end of 
the list. CIL just adds all of the unordered classes in the order that it parses 
them to the end of the ordered list. So could it be that sctp_socket, 
tipc_socket, vsock_socket, x25_socket changing caused the problem?

Jim

>>> Then I'm confused as to why you encountered breakage.  Doesn't CIL
>>> ensure that all of those classes are appended to the existing class
>>> list?  In which case it won't disturb the dbus class definitions.
>>>
>
> If I would have left out the classorder entry , then a reboot would - i suppose - not have fixed the issue
>
>>
>> CIL appends unordered classes to the existing class list, so I am not sure
>> what is going on.
>>
>> Jim
>>
>>
>>
>> --
>> James Carter <jwcart2@tycho.nsa.gov>
>> National Security Agency
>
>
>
> _______________________________________________
> Selinux mailing list
> Selinux@tycho.nsa.gov
> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
> To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov.
>


-- 
James Carter <jwcart2@tycho.nsa.gov>
National Security Agency