On Tue, May 19, 2020 at 6:26 PM Lukas Vrabec <lvrabec@xxxxxxxxxx> wrote: > On 5/15/20 10:25 PM, Zdenek Pytela wrote: > > Stephen, > > > > Thank you for bringing this topic and to everybody else for their > > contribution. I am sorry for the delay. I will respond inline and to > > subsequent e-mails. > > > > > > On Thu, Feb 13, 2020 at 4:09 PM Stephen Smalley <sds@xxxxxxxxxxxxx > > <mailto:sds@xxxxxxxxxxxxx>> 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/c656b97a289ce6c2da2871700384f0f9d831be18 > > > > 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. This one won't be easy, since a lot of new rules will be needed. I actually tried booting Fedora with repolicy some time ago as an experiment and there were still a handful of watch denials, so even if we just backport all the related refpolicy commits, there will certainly still be a big gap (booting the machine is just scratching the surface). We could of course add the permissions and just allow them globally, but that won't really help the testsuite either, since it would somehow need to opt-out from the global allow (turning off the global allow via boolean could break the rest of the system)... Then there is my proposal in https://github.com/fedora-selinux/selinux-policy/pull/288, which tries to provide at least some framework for gradual transition, but that didn't receive support either... I'm really unhappy about this whole situation, but I just don't see any way to both feed the wolf and keep the sheep alive... > > > > - 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/624a63704c19a653486f37d11dc04bbe7d221f38. > > > > - 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/59438b46471ae6cdfb761afc8c9beaf1e428a331. These two permission sets AFAIK should be only rarely hit by confined domains. I bet if we just added them right away it would generate at most a few bug reports (if any). > > > > > > I generally agree we need the changes to have the features in Fedora and > > support the testsuite. > > > > Supposedly all new features will go to rawhide first and after some time > > to F32, too. I can also prepare testbuilds for anyone who wants to test > > various scenarios. > > > > I would start with scratch builds and some basic testing for Rawhide. We > need to understand how costly will these new classes will be in Fedora > and RHEL. > > Recent backporting of "map" permission causes lot of troubles, we need > to avoid similar situation. > > > > > Other differences that don't directly affect the testsuite execution: > > > > - Drop unused socket security classes, > > https://github.com/SELinuxProject/refpolicy/commit/4637cd6f898e95ffa95b2d089916d3987bc7d55f > > > > - Remove unused permissions, > > https://github.com/SELinuxProject/refpolicy/commit/161bda392e61056ea22fe9862ad76c36ca8f35ca > > > > - Remove entrypoint and execute_no_trans from chr_file, > > https://github.com/SELinuxProject/refpolicy/commit/8486b8aa83afa7abd94c9338e8845c2cbeb67f31 > > > > - remove flow_in and flow_out permissions from packet class, > > https://github.com/SELinuxProject/refpolicy/commit/f4459adf3242ed2dbc35e2125f55ec299378c04c > > > > - Rename obsolete netlink_firewall_socket and netlink_ip6fw_socket > > classes, > > https://github.com/SELinuxProject/refpolicy/commit/5fd175fa453e995d8b7357b87403fbbeb4e54ea8 > > > > - Remove unused translate permission in context userspace class, > > https://github.com/SELinuxProject/refpolicy/commit/65da822c1b5c70bd1ff7eca645f5f9fd74fa949e > > > > - Fedora policy has an "undefined" permission in its class system > > access > > vector, not present in refpolicy (some kind of compatibility hack?). > > > > I don't know much from the policy ancient history - Lukas, does a bell > > ring? > > > > This would be some hack to fallback to undefined in system class. We > need to contact systemd folks how it looks like in systemd code and when > undefined is used. > > > > > - 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). > > > > Ondrej, can you respond? I only know as much as I can infer from the git history: git log -p --no-walk 6a08305a4f758850a82ba73ca66ba41e0cd11f46 7c66a77486c868cf78ddb33f9d4b0325c3491554 cf9b7aeaee902c653daba4bd7b7a75edb1a05423 It seems it was kept only to maintain the ordering/numbering of permissions to avoid breakage. > > > > > > - 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. > > > > I will investigate on these two. > > > > > > - 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. > > > > I've never seen these classes mentioned anywhere. > > > > > > - Various whitespace/comment cleanups in refpolicy not in Fedora. > > > > There are many whitespace/comments/typos etc. issues which are annoying, > > however correcting them spoils git history and makes git blame less > > useful, so I am not for every single change like this. I agree that doing a large-scale cleanup would cause trouble when backporting or git-blaming. We should, however, encourage local cleanups done along with other changes, but ideally as a separate commit. Then one can simply cherry-pick the cleanup commit if something depends on it, otherwise let it be. > > > > > > - 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. > > > > Similar case; maybe this time keeping the file history is not that > > important though. This is in a place that is rarely changed (I mean, this thread is a proof of that :) so the history/backport argument doesn't really apply. Just do it. > > > > > > 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 ;( > > > > Removing/renaming I expect go to rawhide only. Yes, and to make it extra safe we could temporarily add a %pre scriptlet that would scan all installed modules for references to the removed/renamed classes/permissions (should be easy to just decompress and grep the CIL module files) and somehow react to it. Just aborting the transaction with an explanation ("please rebuild your policy modules and try upgrading again") would probably be the safest approach. -- Ondrej Mosnacek <omosnace at redhat dot com> Software Engineer, Security Technologies Red Hat, Inc. _______________________________________________ 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
