how to influence the label of files generated by an appliaction

[SZIGETVÁRI János]

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.

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
E-mail: janos(a)szigetvari.com, jszigetvari(a)gmail.com
Web: janos.szigetvari.com

__@__˚V˚
Make the switch to open (source) applications, protocols, formats now:
- windows -> Linux, iexplore -> Firefox, msoffice -> LibreOffice
- msn -> jabber protocol (Pidgin, Google Talk)
- mp3 -> ogg, wmv -> ogg, jpg -> png, doc/xls/ppt -> odt/ods/odp

[Zdenek Pytela]

On Sat, Mar 13, 2021 at 7:24 PM SZIGETVÁRI János <jszigetvari(a)gmail.com&gt;
wrote:

>  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
>  E-mail: janos(a)szigetvari.com, jszigetvari(a)gmail.com
>  Web: janos.szigetvari.com
>
>  __@__˚V˚
>  Make the switch to open (source) applications, protocols, formats now:
>  - windows -> Linux, iexplore -> Firefox, msoffice -> LibreOffice
>  - msn -> jabber protocol (Pidgin, Google Talk)
>  - mp3 -> ogg, wmv -> ogg, jpg -> png, doc/xls/ppt -> odt/ods/odp
>  _______________________________________________
>  selinux mailing list -- selinux(a)lists.fedoraproject.org
>  To unsubscribe send an email to selinux-leave(a)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/[e-mail]...
>  Do not reply to spam on the list, report it:
>  https://pagure.io/fedora-infrastructure
>  

-- 

Zdenek Pytela
Security SELinux team

[James Ralston]

On Sat, Mar 13, 2021 at 1:20 PM SZIGETVÁRI János <jszigetvari(a)gmail.com&gt; 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…