Two questions about selinux

[Gionatan Danti]

Hi all,
I have two questions about selinux.

1) Suppose I have a file which should be shared by two processes with
two different security context (ie: proc_a_t and proc_b_t). I am right
saying that I *must* create a policy to grant access to both processes
for both contexts? Or is it possible to assign *two* labels/contexts to
a file/directory?

2) Suppose that, by using audit2allow, I created a custom policy module.
Time passed, and I lost the original template file, leaving only the
binary policy module. If I then need to add some other customization, do
I need to create a new policy or can I modify the original, binary-only
policy?

Thanks.

--
Danti Gionatan
Supporto Tecnico
Assyoma S.r.l. - www.assyoma.it
email: ***@assyoma.it - ***@assyoma.it
GPG public key ID: FF5F32A8
_______________________________________________
selinux mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to selinux-l

[Simon Sekidde]

----- Original Message -----

Sent: Wednesday, March 14, 2018 4:46:17 PM
Subject: Two questions about selinux
Hi all,
I have two questions about selinux.
1) Suppose I have a file which should be shared by two processes with
two different security context (ie: proc_a_t and proc_b_t). I am right
saying that I *must* create a policy to grant access to both processes
for both contexts? Or is it possible to assign *two* labels/contexts to
a file/directory?

Create policy to grant access to both process types

2) Suppose that, by using audit2allow, I created a custom policy module.
Time passed, and I lost the original template file, leaving only the
binary policy module. If I then need to add some other customization, do
I need to create a new policy or can I modify the original, binary-only
policy?

If the policy was compiled as *.pp policy modules then these can be converted to CIL code using the /usr/libexec/selinux/hll/pp binary (assuming you are running an updated binary policy version)

Thanks.
--
Danti Gionatan
Supporto Tecnico
Assyoma S.r.l. - www.assyoma.it
GPG public key ID: FF5F32A8
_______________________________________________

--
Simon Sekidde
gpg: 5848 958E 73BA 04D3 7C06 F096 1BA1 2DBF 94BC 377E

_______________________________________________
selinux mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to selinux-***@lists.fedoraproject.

[Gionatan Danti]

Post by Simon Sekidde
Create policy to grant access to both process types

Ok, as I am doing right now :)
Thanks for confirmation.

Post by Simon Sekidde
If the policy was compiled as *.pp policy modules then these can be converted to CIL code using the /usr/libexec/selinux/hll/pp binary (assuming you are running an updated binary policy version)

So the process would be:
- use pp to regenerate the template file;
- edit the newly generated template file adding the required entries;
- re-compile it to generate the new binary policy.

This means that direct binary patching (without regenerating the
text-based template file) is not possible, right? Am I missing something
else?

Regards.

--
Danti Gionatan
Supporto Tecnico
Assyoma S.r.l. - www.assyoma.it
email: ***@assyoma.it - ***@assyoma.it
GPG public key ID: FF5F32A8
_______________________________________________
selinux mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to selinux-***@lists.fedorapr

[Gary Tierney]

Post by Gionatan Danti

Post by Simon Sekidde
Create policy to grant access to both process types

Ok, as I am doing right now :)
Thanks for confirmation.

Post by Simon Sekidde
If the policy was compiled as *.pp policy modules then these can be converted to CIL code using the /usr/libexec/selinux/hll/pp binary (assuming you are running an updated binary policy version)

- use pp to regenerate the template file;
- edit the newly generated template file adding the required entries;
- re-compile it to generate the new binary policy.

Working on exported policy isn't optimal. If you're using M4 macros
(i.e. interfaces, templates, etc.) in your policy they'll be lost when
you build a .pp file.

If you intend on maintaining a policy module you should instead keep the
sources and re-build from those. What you might find useful, however,
is the fact that CIL is a source based policy language. You can import
a CIL policy module with `semodule -i my_module.cil` and re-export it
again with `semodule --cil -E my_module` to get the same code.

The drawback though is that macros from the base policy aren't
accessible since they're simple build-time string substitutions.

Post by Gionatan Danti
This means that direct binary patching (without regenerating the
text-based template file) is not possible, right? Am I missing
something else?
Regards.
--
Danti Gionatan
Supporto Tecnico
Assyoma S.r.l. - www.assyoma.it
GPG public key ID: FF5F32A8
_______________________________________________

_______________________________________________
selinux mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to selinux-