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.
----- Original Message -----
From: "Gionatan Danti" g.danti@assyoma.it To: selinux@lists.fedoraproject.org Sent: Wednesday, March 14, 2018 4:46:17 PM Subject: Two questions about selinux
Hi all, I have two questions about selinux.
- 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
- 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 email: g.danti@assyoma.it - info@assyoma.it GPG public key ID: FF5F32A8 _______________________________________________ selinux mailing list -- selinux@lists.fedoraproject.org To unsubscribe send an email to selinux-leave@lists.fedoraproject.org
On 14/03/2018 22:32, Simon Sekidde wrote:
Create policy to grant access to both process types
Ok, as I am doing right now :) Thanks for confirmation.
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.
On Thu, Mar 15, 2018 at 09:10:15AM +0100, Gionatan Danti wrote:
On 14/03/2018 22:32, Simon Sekidde wrote:
Create policy to grant access to both process types
Ok, as I am doing right now :) Thanks for confirmation.
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.
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.
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: g.danti@assyoma.it - info@assyoma.it GPG public key ID: FF5F32A8 _______________________________________________ selinux mailing list -- selinux@lists.fedoraproject.org To unsubscribe send an email to selinux-leave@lists.fedoraproject.org
selinux@lists.fedoraproject.org