Russell Coker <russell@xxxxxxxxxxxx> writes: > On Sunday, 13 January 2019 6:28:35 AM AEDT Chris PeBenito wrote: >> > Index: refpolicy-2.20180701/policy/modules/system/systemd.te >> > =================================================================== >> > --- refpolicy-2.20180701.orig/policy/modules/system/systemd.te >> > +++ refpolicy-2.20180701/policy/modules/system/systemd.te >> > @@ -337,6 +337,10 @@ optional_policy(` >> > networkmanager_dbus_chat(systemd_hostnamed_t) >> > ') >> > >> > +optional_policy(` >> > + unconfined_dbus_send(systemd_hostnamed_t) >> > +') >> >> This comment: >> >> https://github.com/SELinuxProject/refpolicy/issues/18#issuecomment-452316615 >> >> makes me rethink all dbus sends to unconfined domains, especially >> unconfined_t. This here isn't all confined domains, but I want more >> consideration for the perm. > > That comment is about allowing all domains to send to unconfined_t. Allowing > specific domains like systemd_hostnamed_t to send to unconfined_t doesn't seem > like a problem. It doesn't seem likely that an attack via dbus would start > with a systemd domain, especially not one like systemd_hostnamed_t. Not completely accurate. The comment is not about "all" domains, its about "all" domains that already have access to dbus. However I kind of agree here that it's probably not worth it to go down this rabbit hole. Even the normal dbus_chat interfaces are too broad (and that is inevitable), and potentially allow for atleast some form of priv escalation more often then not. It just a dbus design issue IMHO. This is also why i added that commit in the first place. I knew that it was a (big) compromise but i just chose to add it anyway (without any discussion, which was wrong). I still allow this access in DSSP2, I just made a note about it in the README. There are just weak spots in the policy such as DBUS and unconfined. As long as you are aware of them you can to some extent anticipate that. -- Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02 Dominick Grift
