Re: how to influence the label of files generated by an appliaction
On Sat, Mar 13, 2021 at 1:20 PM SZIGETVÁRI János <jszigetvari(a)gmail.com> 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…