how to influence the label of files generated by an appliaction

[Zdenek Pytela]

Dear Members,
I am maintaining a SELinux policy module for an application (A) and one of
its submodules (B).
By now I have reached a point where all the rules seem to be in place, and
both A and B processes transition to their respective process labels, and
have their associated file types, the related permissions and file paths
set up.
My problem is that even though a process of B is running with the B
process label, it is supposed to create some files and directories of its
own under a directory that has a label related to A. The B process has the
necessary rights to create those directories and files underneath the
directory with the label belonging to A. The problem is that 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.

Hi,

If I understand correctly, you need to have files with different context
coexist in one directory.
New filesystem objects inherit the context from their directory by default,
but a different context can be set in the policy, too, using file
transitions. You have 2 options, change the context depending on the
creating process, or based on the filename.

Refer e. g. to
https://danwalsh.livejournal.com/43170.html
for more information or to existing examples in the policy and let me know
if you have any further questions.

Thanks in advance for any help!
Best Regards,
János Szigetvári
--
Janos SZIGETVARI
RHCE, License no. 150-053-692
<https://www.redhat.com/rhtapps/verify/?certId=150-053-692>
LinkedIn: linkedin.com/in/janosszigetvari
Web: janos.szigetvari.com
- windows -> Linux, iexplore -> Firefox, msoffice -> LibreOffice
- msn -> jabber protocol (Pidgin, Google Talk)
- mp3 -> ogg, wmv -> ogg, jpg -> png, doc/xls/ppt -> odt/ods/odp
_______________________________________________
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
https://pagure.io/fedora-infrastructure

[James Ralston]

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 -- ***@lists.fedoraproject.org
To unsubscribe send an email to selinux-***@lists.fedoraproject.org
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/***@lists.fedoraproject.org
Do not reply to spam on the list, report it: https://pagure.io/fedora-