On Tue, Apr 6, 2021 at 10:30 PM Florian Weimer <fweimer@xxxxxxxxxx> wrote: > * Ondrej Mosnacek: > > > Kernel 5.12 added support to SELinux for controlling access to the > > userfaultfd interface [1][2] and we'd like to implement this in > > Fedora's selinux-policy. However, once we add the corresponding class > > to the policy, all SELinux domains for which we don't add the > > appropriate rules will have any usage of userfaultfd(2) denied. > > What's special about this system call that this is necessary? Our primary motivation is not so much to have this specific syscall covered, but rather to close the gap between what is supported by the kernel versus the policy. On the default "targeted" policy the security classes/permissions (think of this as individual kinds of operations that can be allowed or denied) that are unknown to the policy are allowed by default, but on the more strict "mls" variant they are denied. So once the kernel adds a new security class/permission, we are forced to implement it in some way so that the corresponding functionality is not blanket-denied on the MLS policy. It is of course possible to just allow the new operation globally if it's something not worth bothering with, but we rather try to follow the principle of least privilege and allow new things only where they are needed. That said, I heard that userfaultfd(2) has been used in some exploits, so there may be merit in trying to restrict its use (especially when the legitimate use seems to be limited to just a few applications). A quick Google search indeed reveals a few interesting examples: https://blog.lizzie.io/using-userfaultfd.html https://www.exploit-db.com/exploits/45983 https://a13xp0p0v.github.io/2020/02/15/CVE-2019-18683.html#heap-spraying -- Ondrej Mosnacek Software Engineer, Linux Security - SELinux kernel Red Hat, Inc. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-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/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
