Hi All,
I'll try to answer inline. :)
On 2/18/20 1:18 AM, Paul Moore wrote:
I'm sure Lukas has seen this by now, but explicitly adding him just in case :)
Yes, Paul is right I saw it, sorry for late reply, these months are quite busy for me.
The truth is, I'm no longer selinux-policy maintainer for Fedora and Red Hat Enterprise Linux, however I'm still part of the team. :)
Zdenek Pytela, took maintenance responsibilities for selinux-policy component. (adding him to CC)
Fedora SELinux folks, Fedora has long held a special place at the forefront of SELinux development and it is a bit of a shame that the default SELinux policy on Fedora is missing so many of the classes/permissions.
Understand this point and agree with you that we're missing new classes and permissions. However, we need to start adding new classes/permissions wisely, to avoid introducing new SELinux policy bugs on Stable or future Fedoras and that is the main reason why we're not proactively accepting these patches from the refpolicy.
I understand that stable Fedora releases will grow out of sync over time, but is there some way we can keep Rawhide current with upstream?
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?
Thanks, Lukas.
On Thu, Feb 13, 2020 at 10:09 AM Stephen Smalley sds@tycho.nsa.gov wrote:
Hi,
Fedora policy has a number of differences in its security_classes and access_vectors from current refpolicy, and neither are fully up to date with the kernel (but refpolicy is closer). One consequence of this is that parts of the selinux-testsuite do not run by default on Fedora (including rawhide) at present and still require manual patching by testers if they want to exercise all the tests.
Differences that I see include:
- refpolicy has added the watch* permissions exercised by the
selinux-testsuite/tests/{notify,filesystem,fs_filesystem} tests. These were first defined in refpolicy by https://github.com/SELinuxProject/refpolicy/commit/c656b97a289ce6c2da2871700... but there have been a series of subsequent commits (one to fix an ordering problem to better align with the kernel) and then allowing these new watch permissions as needed.
- refpolicy has added the perf_event class exercised by the
selinux-testsuite/tests/perf_event tests. These were first defined in refpolicy by https://github.com/SELinuxProject/refpolicy/commit/624a63704c19a653486f37d11....
- Neither refpolicy nor fedora have yet added the lockdown class
exercised by selinux-testsuite/tests/lockdown. The kernel commit introducing this class is https://github.com/SELinuxProject/selinux-kernel/commit/59438b46471ae6cdfb76....
Other differences that don't directly affect the testsuite execution:
- Drop unused socket security classes,
https://github.com/SELinuxProject/refpolicy/commit/4637cd6f898e95ffa95b2d089...
- Remove unused permissions,
https://github.com/SELinuxProject/refpolicy/commit/161bda392e61056ea22fe9862...
- Remove entrypoint and execute_no_trans from chr_file,
https://github.com/SELinuxProject/refpolicy/commit/8486b8aa83afa7abd94c9338e...
- remove flow_in and flow_out permissions from packet class,
https://github.com/SELinuxProject/refpolicy/commit/f4459adf3242ed2dbc35e2125...
- Rename obsolete netlink_firewall_socket and netlink_ip6fw_socket
classes, https://github.com/SELinuxProject/refpolicy/commit/5fd175fa453e995d8b7357b87...
- Remove unused translate permission in context userspace class,
https://github.com/SELinuxProject/refpolicy/commit/65da822c1b5c70bd1ff7eca64...
- Fedora policy has an "undefined" permission in its class system access
vector, not present in refpolicy (some kind of compatibility hack?).
- Fedora policy has an "epolwakeup" permission in its class capability2
access vector, not present in refpolicy (old name for block_suspend, never included in an official kernel release, also not even correct originally - should have been epollwakeup).
- Fedora policy has "getnetgrp" and "shmemnetgrp" permissions in its
class nscd access vector, not sure if those are used by glibc/ncsd code but if so should get added to refpolicy too.
- Fedora policy has a "proxy" class and access vector for "gssd", not
present in refpolicy. If that's something that isn't Fedora-specific, it should probably get upstreamed to refpolicy although the class name isn't very descriptive.
- refpolicy has "db_exception" and "db_datatype" classes and access
vectors for "Interbase/Firebird/Red Database", not present in Fedora. Don't know if that matters to Fedora.
Various whitespace/comment cleanups in refpolicy not in Fedora.
process2 is declared at a different place in security_classes in
refpolicy versus Fedora. Doesn't really matter since kernel uses dynamic class/perm support and no fixed definition ever defined in libselinux/libsepol headers but might be good to align them for consistency.
NB The removals and renames may have some compatibility implications, e.g. a local or third party policy module built against the existing Fedora policy headers may have picked up dependencies on these classes/permissions and therefore may need to be rebuilt against the updated headers in order to still link successfully. This could break upon an update if those local or third party modules were installed at the time of the update since we'd fail on the semodule -B during %post, leaving the system with the old policy. rpm selinux support was supposed to fix that kind of thing by handling it via plugin and not from %post and rolling the package update back but never got adopted/used ;(
On Tue, Feb 18, 2020 at 10:34 PM Lukas Vrabec lvrabec@redhat.com wrote:
Hi All,
I'll try to answer inline. :)
On 2/18/20 1:18 AM, Paul Moore wrote:
I'm sure Lukas has seen this by now, but explicitly adding him just in case :)
Yes, Paul is right I saw it, sorry for late reply, these months are quite busy for me.
The truth is, I'm no longer selinux-policy maintainer for Fedora and Red Hat Enterprise Linux, however I'm still part of the team. :)
Zdenek Pytela, took maintenance responsibilities for selinux-policy component. (adding him to CC)
Fedora SELinux folks, Fedora has long held a special place at the forefront of SELinux development and it is a bit of a shame that the default SELinux policy on Fedora is missing so many of the classes/permissions.
Understand this point and agree with you that we're missing new classes and permissions. However, we need to start adding new classes/permissions wisely, to avoid introducing new SELinux policy bugs on Stable or future Fedoras and that is the main reason why we're not proactively accepting these patches from the refpolicy.
I understand that stable Fedora releases will grow out of sync over time, but is there some way we can keep Rawhide current with upstream?
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?
No, I didn't :) I only made a PR adding the watch permissions, which doesn't seem to be moving anywhere... But most of the Stephen's suggestions can be accomplished by simply cherry-picking the relevant commits from refpolicy so I encourage the new maintainer (on PTO this week, BTW) or anyone to just go ahead and do it. Also the perf_event class shouldn't cause many denials, I think we should just add it and add missing permissions as they appear.
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.
For testsuite purposes, it is more crucial to add the new classes/permissions so that the tests actually run than removing the dead ones.
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.
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.
selinux@lists.fedoraproject.org
-
Lukas Vrabec -
Ondrej Mosnacek -
Stephen Smalley