On 2/19/20 3:01 PM, Stephen Smalley wrote:
> On 2/19/20 8:47 AM, Stephen Smalley wrote:
>> On 2/18/20 4:33 PM, Lukas Vrabec wrote:
>>> I fully agree that we should merge commits from the refpolicy, which
>>> removing unused permissions and classes. This should *NOT* break
>>> anything.
>>>
>>> Related to new permissions, we need to understand what are security
>>> benefits of adding it to Fedora (and RHEL). The main goal is keep "good"
>>> balance between usability and security (We cannot introduce any
>>> regressions by adding policy features)
>>>
>>> My suggestion is start with removing obsolete and unused
>>> permissions/classes and after discussion (e.g here) we can start picking
>>> some good candidate RFEs.
>>>
>>> @Ondrej,
>>> AFAIK, you prepared PR to remove unused classes and permissions, could
>>> we merge it?
>>
>> Caveat: Removing unused classes and permissions can break policy
>> updates when there are local or third party policy modules installed
>> that were built against the older refpolicy headers that still
>> declared them and potentially even allowed them. On the policy
>> package update, any references to the removed classes or permissions
>> in the local or third party policy module will fail to resolve, and
>> semodule -B will fail. Unfortunately since this is run from %post and
>> not integrated via rpm selinux plugin, the failure won't rollback the
>> rpm transaction, so from rpm's point of view, the updated policy
>> package will be installed but libsemanage will have rolled back to the
>> old policy since it couldn't resolve the classes/permissions. Only
>> way to fix is to remove the offending policy modules, update,
>> recompile the offending policy modules against the new headers, and
>> then re-install them.
>
> NB For a while, CIL treated unknown permissions as a non-fatal error to
> avoid breakage in this kind of situation; this was changed in selinux
> userspace commit dc4e54126bf25dea4d51820922ccd1959be68fbc (" libsepol:
> Make an unknown permission an error in CIL") because otherwise typos or
> other errors in policy could go undetected. I suppose Fedora could
> introduce some kind of compatibility hack to try to avoid breakage in
> these scenarios, but that would need to apply to both unknown classes
> and permissions and in a manner that still detects real errors (maybe a
> whitelist of known removed classes/permissions?).
>
>>
>> For testsuite purposes, it is more crucial to add the new
>> classes/permissions so that the tests actually run than removing the
>> dead ones.
>
Thank you for discussion, we need to wait for SELinux policy maintainer
and then we could follow up.
Thanks,
Lukas.
--
Lukas Vrabec
SELinux Evangelist,
Senior Software Engineer, Security Technologies
Red Hat, Inc.
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ selinux mailing list -- selinux@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to selinux-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/selinux@xxxxxxxxxxxxxxxxxxxxxxx
