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.