On Sat, Mar 13, 2021 at 1:20 PM SZIGETVÁRI János <jszigetvari@xxxxxxxxx> wrote: > the files created by the process B will not be created with the file > label belonging to B, but seem to inherit the label from the parent > directory, that has a label belonging to A. This happens in spite of > having the file contexts and paths set up correctly in the module's > fc rules. > > So if I run restorecon on the files that were just created (by B, > but have a label belonging to A), it will (re)set them to the file > labels I intended them to have originally. > > How can I overcome this problem? This behavior causes an ugly > logical flaw in the logical design of my SELinux modules. Zdenek provided the answer (file transitions), but it might be helpful to understand why this behavior exists. File transitions wouldn’t be needed if the kernel simply looked up the correct file context for any filesystem object creation and created the object with the correct context. But the kernel does not do this, because calculating the correct file context for an arbitrary path can be nontrivial (e.g., requiring parsing regular expressions). If the kernel did this by default for every object created in the filesystem, performance would be terrible. To avoid this performance penalty, by default, new objects in the filesystem inherit the context of the parent directory. This is very fast for the kernel to look up, so it avoids the performance penalty. But as you discovered, there are situations in which a newly-created object should have a different file context than its parent directory. One way to avoid that problem would be to make the application SELinux-aware, so that it knows how to ask the kernel for the correct context, and then asks the kernel to create the object with that context. But not all applications can be made SELinux-aware, and this incurs the same performance penalty of having the kernel do it, anyway. So, file transition rules were created as a kind of kluge/compromise: by restricting file transition rules to be extremely specific (exact source context, exact target context, exact default context, exact object filename), the kernel can test whether there is a matching transition for a specific object creation quickly enough to avoid a significant performance penalty, and can therefore do this for every new object creation. Alas, this means that you, as an SELinux policy author, must examine your file context policy, find all cases in which a new object should have a file context other than the one its parent directory has, and add appropriate file transition rules to your policy to ensure that occurs. And there can be a lot of them. NetworkManager_t has 266 file transition rules just by itself: $ sesearch --type_trans --source NetworkManager_t | wc -l 266 Overall: $ sesearch --type_trans | wc -l 254622 No, that’s not a tyop: Fedora 33’s SElinux targeted policy has more than a quarter of a million file transition rules. But it’s not about the total number of transition rules; it’s about how quickly the kernel can check whether a new filesystem object creation matches a rule. So, in summary, in an ideal world, file transition rules wouldn’t be needed; the kernel would always look up the correct file context for every new filesystem object creation. But because it is far too expensive for the kernel to do that by default, file transition rules were created to give SELinux policy authors a mechanism to override the kernel’s “just give the new object the same context as the parent directory” rule, without having to make every single application SELinux-aware. Hopefully that is at least some consolation while you are crafting your file transition rules… _______________________________________________ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
