Hi,
I had an upstream SELinux pull-request merged in autumn 2020 [1]. But I still don't see this SELinux boolean flag (renamed [2] to "dbus_pass_tuntap_fd") present in Fedora 38. So I wonder how the SELinux refpolicy is consumed into Fedora's SELinux policies ... when can I expect to see this in Fedora and RHEL SELinux policies?
[1] https://github.com/SELinuxProject/refpolicy/commit/79c7859a4807236693c734421642d5aacff0a9e2 [2] https://github.com/SELinuxProject/refpolicy/commit/ba3818ebcc3a627bc331c61acf2df13d223452ea
-- kind regards,
David Sommerseth OpenVPN Inc
On Fri, Mar 31, 2023 at 9:58 AM David Sommerseth dazo@eurephia.org wrote:
Hi,
I had an upstream SELinux pull-request merged in autumn 2020 [1]. But I still don't see this SELinux boolean flag (renamed [2] to "dbus_pass_tuntap_fd") present in Fedora 38. So I wonder how the SELinux refpolicy is consumed into Fedora's SELinux policies ... when can I expect to see this in Fedora and RHEL SELinux policies?
[1] https://github.com/SELinuxProject/refpolicy/commit/79c7859a4807236693c734421642d5aacff0a9e2 [2] https://github.com/SELinuxProject/refpolicy/commit/ba3818ebcc3a627bc331c61acf2df13d223452ea
It's not consumed by Fedora or openSUSE at all. Fedora and openSUSE follow this instead: https://github.com/fedora-selinux/selinux-policy
As far as I know, there has been no reconciliation between the two happening anytime in the recent past and it's unlikely to happen anytime soon.
On 31/03/2023 16:36, Neal Gompa wrote:
On Fri, Mar 31, 2023 at 9:58 AM David Sommerseth dazo@eurephia.org wrote:
Hi,
I had an upstream SELinux pull-request merged in autumn 2020 [1]. But I still don't see this SELinux boolean flag (renamed [2] to "dbus_pass_tuntap_fd") present in Fedora 38. So I wonder how the SELinux refpolicy is consumed into Fedora's SELinux policies ... when can I expect to see this in Fedora and RHEL SELinux policies?
[1] https://github.com/SELinuxProject/refpolicy/commit/79c7859a4807236693c734421642d5aacff0a9e2 [2] https://github.com/SELinuxProject/refpolicy/commit/ba3818ebcc3a627bc331c61acf2df13d223452ea
It's not consumed by Fedora or openSUSE at all. Fedora and openSUSE follow this instead: https://github.com/fedora-selinux/selinux-policy
As far as I know, there has been no reconciliation between the two happening anytime in the recent past and it's unlikely to happen anytime soon.
Maybe not the right place to ask ... but what is the purpose and goal of the SELinux refpolicy project if several of the larger Linux distributions doesn't pay attention to it?
I kinda would expect that lots of the SELinux policy details in Fedora would be pretty much the same challenges in other distributions as well.
On Fri, Mar 31, 2023 at 10:49 AM David Sommerseth dazo@eurephia.org wrote:
On 31/03/2023 16:36, Neal Gompa wrote:
On Fri, Mar 31, 2023 at 9:58 AM David Sommerseth dazo@eurephia.org wrote:
Hi,
I had an upstream SELinux pull-request merged in autumn 2020 [1]. But I still don't see this SELinux boolean flag (renamed [2] to "dbus_pass_tuntap_fd") present in Fedora 38. So I wonder how the SELinux refpolicy is consumed into Fedora's SELinux policies ... when can I expect to see this in Fedora and RHEL SELinux policies?
[1] https://github.com/SELinuxProject/refpolicy/commit/79c7859a4807236693c734421642d5aacff0a9e2 [2] https://github.com/SELinuxProject/refpolicy/commit/ba3818ebcc3a627bc331c61acf2df13d223452ea
It's not consumed by Fedora or openSUSE at all. Fedora and openSUSE follow this instead: https://github.com/fedora-selinux/selinux-policy
As far as I know, there has been no reconciliation between the two happening anytime in the recent past and it's unlikely to happen anytime soon.
Maybe not the right place to ask ... but what is the purpose and goal of the SELinux refpolicy project if several of the larger Linux distributions doesn't pay attention to it?
I kinda would expect that lots of the SELinux policy details in Fedora would be pretty much the same challenges in other distributions as well.
They are. I had a conversation about SELinux vs AppArmor several years ago in Debian where the Debian folks didn't want to do anything with SELinux because it was so broken for them. I found out they were packaging the Tresys refpolicy instead of using our policy and advised them to change it. Unfortunately, that didn't happen, and I think they promote AppArmor these days because upstream AppArmor profiles can be used on any distribution pretty much without issues.
I don't know what caused the policy splinter for SELinux, but as far as I know, it can't be fixed.
David Sommerseth dazo@eurephia.org writes:
On 31/03/2023 16:36, Neal Gompa wrote:
On Fri, Mar 31, 2023 at 9:58 AM David Sommerseth dazo@eurephia.org wrote:
Hi,
I had an upstream SELinux pull-request merged in autumn 2020 [1]. But I still don't see this SELinux boolean flag (renamed [2] to "dbus_pass_tuntap_fd") present in Fedora 38. So I wonder how the SELinux refpolicy is consumed into Fedora's SELinux policies ... when can I expect to see this in Fedora and RHEL SELinux policies?
The best way is to create a bug with a request to backport a patch or create a PR on github.com/fedora-selinux/selinux-policy
[1] https://github.com/SELinuxProject/refpolicy/commit/79c7859a4807236693c734421642d5aacff0a9e2 [2] https://github.com/SELinuxProject/refpolicy/commit/ba3818ebcc3a627bc331c61acf2df13d223452ea
It's not consumed by Fedora or openSUSE at all. Fedora and openSUSE follow this instead: https://github.com/fedora-selinux/selinux-policy
As far as I know, there has been no reconciliation between the two happening anytime in the recent past and it's unlikely to happen anytime soon.
Maybe not the right place to ask ... but what is the purpose and goal of the SELinux refpolicy project if several of the larger Linux distributions doesn't pay attention to it?
I kinda would expect that lots of the SELinux policy details in Fedora would be pretty much the same challenges in other distributions as well.
AFAIK refpolicy was more conservative while fedora-selinux was more focused on usability on desktop. They're still somehow compatible, they use same build process and backports from or to fedora-selinux still happen from time to time, but fedora-selinux is not considered as fork anymore.
You can try refpolicy on your own and see whether it works for you
https://github.com/SELinuxProject/selinux-notebook/blob/main/src/reference_p...
Petr
selinux mailing list -- selinux@lists.fedoraproject.org To unsubscribe send an email to selinux-leave@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/selinux@lists.fedoraproject.or... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On 31/03/2023 17:08, Petr Lautrbach wrote:
David Sommerseth dazo@eurephia.org writes:
On 31/03/2023 16:36, Neal Gompa wrote:
On Fri, Mar 31, 2023 at 9:58 AM David Sommerseth dazo@eurephia.org wrote:
Hi,
I had an upstream SELinux pull-request merged in autumn 2020 [1]. But I still don't see this SELinux boolean flag (renamed [2] to "dbus_pass_tuntap_fd") present in Fedora 38. So I wonder how the SELinux refpolicy is consumed into Fedora's SELinux policies ... when can I expect to see this in Fedora and RHEL SELinux policies?
The best way is to create a bug with a request to backport a patch or create a PR on github.com/fedora-selinux/selinux-policy
Alright, I'll wrap up a patch and pull-req for fedora-selinux too.
But for OpenVPN 3 Linux I do have an additional policy for a few of the D-Bus services as well. Would it make sense to just keep them in the openvpn3-linux project, or should I try to get them to some more widespread SELinux reference policies?
Considering the discoveries of today, I'm kind a wondering if it's best to keep it how it is. That way I can ensure it's available on all distributions with SELinux support more easily. But I'm open to think differently.
[...snip...]
Maybe not the right place to ask ... but what is the purpose and goal of the SELinux refpolicy project if several of the larger Linux distributions doesn't pay attention to it?
I kinda would expect that lots of the SELinux policy details in Fedora would be pretty much the same challenges in other distributions as well.
AFAIK refpolicy was more conservative while fedora-selinux was more focused on usability on desktop. They're still somehow compatible, they use same build process and backports from or to fedora-selinux still happen from time to time, but fedora-selinux is not considered as fork anymore.
Okay, good to know. Is fedora-selinux specific to Fedora/RHEL only, or does other distributions also use this as their refpolicy?
On Fri, Mar 31, 2023 at 11:16 AM David Sommerseth dazo@eurephia.org wrote:
On 31/03/2023 17:08, Petr Lautrbach wrote:
David Sommerseth dazo@eurephia.org writes:
On 31/03/2023 16:36, Neal Gompa wrote:
On Fri, Mar 31, 2023 at 9:58 AM David Sommerseth dazo@eurephia.org wrote:
Hi,
I had an upstream SELinux pull-request merged in autumn 2020 [1]. But I still don't see this SELinux boolean flag (renamed [2] to "dbus_pass_tuntap_fd") present in Fedora 38. So I wonder how the SELinux refpolicy is consumed into Fedora's SELinux policies ... when can I expect to see this in Fedora and RHEL SELinux policies?
The best way is to create a bug with a request to backport a patch or create a PR on github.com/fedora-selinux/selinux-policy
Alright, I'll wrap up a patch and pull-req for fedora-selinux too.
But for OpenVPN 3 Linux I do have an additional policy for a few of the D-Bus services as well. Would it make sense to just keep them in the openvpn3-linux project, or should I try to get them to some more widespread SELinux reference policies?
Considering the discoveries of today, I'm kind a wondering if it's best to keep it how it is. That way I can ensure it's available on all distributions with SELinux support more easily. But I'm open to think differently.
[...snip...]
Maybe not the right place to ask ... but what is the purpose and goal of the SELinux refpolicy project if several of the larger Linux distributions doesn't pay attention to it?
I kinda would expect that lots of the SELinux policy details in Fedora would be pretty much the same challenges in other distributions as well.
AFAIK refpolicy was more conservative while fedora-selinux was more focused on usability on desktop. They're still somehow compatible, they use same build process and backports from or to fedora-selinux still happen from time to time, but fedora-selinux is not considered as fork anymore.
Okay, good to know. Is fedora-selinux specific to Fedora/RHEL only, or does other distributions also use this as their refpolicy?
SUSE Linux distributions use the fedora-selinux policy too. Arch and Gentoo have their own forks of refpolicy.
-- 真実はいつも一つ！/ Always, there's only one truth!
On 31/03/2023 17:27, Neal Gompa wrote:
On Fri, Mar 31, 2023 at 11:16 AM David Sommerseth dazo@eurephia.org wrote:
[...snip...]
Okay, good to know. Is fedora-selinux specific to Fedora/RHEL only, or does other distributions also use this as their refpolicy?
SUSE Linux distributions use the fedora-selinux policy too.
Thanks! Sounds good.
Arch and Gentoo have their own forks of refpolicy.
"lovely" .....
On Fri, Mar 31, 2023 at 12:11 PM David Sommerseth dazo@eurephia.org wrote:
On 31/03/2023 17:27, Neal Gompa wrote:
On Fri, Mar 31, 2023 at 11:16 AM David Sommerseth dazo@eurephia.org wrote:
[...snip...]
Okay, good to know. Is fedora-selinux specific to Fedora/RHEL only, or does other distributions also use this as their refpolicy?
SUSE Linux distributions use the fedora-selinux policy too.
Thanks! Sounds good.
Arch and Gentoo have their own forks of refpolicy.
"lovely" .....
Fixing that probably just requires a bit of outreach. I helped get SUSE Linux distributions to use the fedora-selinux policy a few years ago, so someone could do the same for Debian, Arch, and Gentoo.
The Tresys policy is basically unusable in my experience. :(
-- 真実はいつも一つ！/ Always, there's only one truth!
David Sommerseth dazo@eurephia.org writes:
On 31/03/2023 17:08, Petr Lautrbach wrote:
David Sommerseth dazo@eurephia.org writes:
On 31/03/2023 16:36, Neal Gompa wrote:
On Fri, Mar 31, 2023 at 9:58 AM David Sommerseth dazo@eurephia.org wrote:
Hi,
I had an upstream SELinux pull-request merged in autumn 2020 [1]. But I still don't see this SELinux boolean flag (renamed [2] to "dbus_pass_tuntap_fd") present in Fedora 38. So I wonder how the SELinux refpolicy is consumed into Fedora's SELinux policies ... when can I expect to see this in Fedora and RHEL SELinux policies?
The best way is to create a bug with a request to backport a patch or create a PR on github.com/fedora-selinux/selinux-policy
Alright, I'll wrap up a patch and pull-req for fedora-selinux too.
But for OpenVPN 3 Linux I do have an additional policy for a few of the D-Bus services as well. Would it make sense to just keep them in the openvpn3-linux project, or should I try to get them to some more widespread SELinux reference policies?
I'd suggest to keep them in the project and use
https://fedoraproject.org/wiki/SELinux/IndependentPolicy
I've added Vit who's expert in ^^
Considering the discoveries of today, I'm kind a wondering if it's best to keep it how it is. That way I can ensure it's available on all distributions with SELinux support more easily. But I'm open to think differently.
[...snip...]
Maybe not the right place to ask ... but what is the purpose and goal of the SELinux refpolicy project if several of the larger Linux distributions doesn't pay attention to it?
I kinda would expect that lots of the SELinux policy details in Fedora would be pretty much the same challenges in other distributions as well.
AFAIK refpolicy was more conservative while fedora-selinux was more focused on usability on desktop. They're still somehow compatible, they use same build process and backports from or to fedora-selinux still happen from time to time, but fedora-selinux is not considered as fork anymore.
Okay, good to know. Is fedora-selinux specific to Fedora/RHEL only, or does other distributions also use this as their refpolicy?
-- kind regards,
David Sommerseth OpenVPN Inc
On 31/03/2023 17:41, Petr Lautrbach wrote:
David Sommerseth dazo@eurephia.org writes:
[...snip...]
But for OpenVPN 3 Linux I do have an additional policy for a few of the D-Bus services as well. Would it make sense to just keep them in the openvpn3-linux project, or should I try to get them to some more widespread SELinux reference policies?
I'd suggest to keep them in the project and use
https://fedoraproject.org/wiki/SELinux/IndependentPolicy
I've added Vit who's expert in ^^
Thanks a lot!
I believe the policy we currently ship via Fedora Copr is in a reasonable state. It has also been somewhat reviewed by some of the SELinux/refpolicy maintainers and I've implemented proposed changes.
https://github.com/OpenVPN/openvpn3-linux/tree/master/src/selinux
The openvpn3.te policy is what I will suggest to fedora-selinux, as that may be useful for other projects as well.
The openvpn3_service.{fc,if,te} policy is OpenVPN 3 Linux specific.
-- kind regards,
David Sommerseth OpenVPN Inc
On 3/31/23 18:09, David Sommerseth wrote:
On 31/03/2023 17:41, Petr Lautrbach wrote:
David Sommerseth dazo@eurephia.org writes:
[...snip...]
But for OpenVPN 3 Linux I do have an additional policy for a few of the D-Bus services as well. Would it make sense to just keep them in the openvpn3-linux project, or should I try to get them to some more widespread SELinux reference policies?
I'd suggest to keep them in the project and use
https://fedoraproject.org/wiki/SELinux/IndependentPolicy
I've added Vit who's expert in ^^
Thanks a lot!
I believe the policy we currently ship via Fedora Copr is in a reasonable state. It has also been somewhat reviewed by some of the SELinux/refpolicy maintainers and I've implemented proposed changes.
https://github.com/OpenVPN/openvpn3-linux/tree/master/src/selinux
The openvpn3.te policy is what I will suggest to fedora-selinux, as that may be useful for other projects as well.
The openvpn3_service.{fc,if,te} policy is OpenVPN 3 Linux specific.
Hi, thank you for taking the time to write your own policy. It is great when the policy is written by someone who actually understands what access the product needs.
Looking at the policy I have a few suggestions.
Please try to avoid the "require" block and simple allow rules in favor of using interfaces where possible. The require block is already part of the interface and you don't have to keep it up-to-date. There is probably no harm in it when used with types defined in "kernel" or "system" ([1], [2]) since those would be hard to remove and seldom change, but can be important for other modules (especially "contrib" [3]). It is generally bad practice to use types defined in another module (that is what the interfaces are for) -- "audit2allow -R" can help you find you the proper interface if it exists.
e.g.
allow openvpn3_client_t kernel_t:unix_dgram_socket sendto; [4] can be replaced by "kernel_dgram_send(openvpn3_client_t)" (BTW "kernel_t" is not in the "require" block anyway)
openvpn3_allow_dbus_chat(openvpn3_client_t, systemd_hostnamed_t); openvpn3_allow_dbus_chat(systemd_hostnamed_t, openvpn3_client_t); as well as "type systemd_hostnamed_t;" in the require block can be replaced by a single interface "systemd_dbus_chat_hostnamed(openvpn3_client_t)"
Both interfaces are part of refpolicy, so should be available in other distributions as well.
"type syslogd_var_run_t;" in the require block seems to be left over from a rule that has been removed.
Also, all interfaces defined in modules other than "system" or "kernel" should be enclosed in "optional_policy" block (as seen e.g. in [5]). In your policy that applies for example to "dbus_system_bus_client(openvpn3_netcfg_t)" [6]. The "optional_policy" block makes all requirements inside it "soft" (i.e. when not met, the policy rules inside the block are not active, but the rest of the module still works). That enables your module to be installed on systems where the interfaced module ("dbus" in this case) is disabled or removed.
Vit
[1] - https://github.com/SELinuxProject/refpolicy/tree/master/policy/modules/kerne... [2] - https://github.com/SELinuxProject/refpolicy/tree/master/policy/modules/syste... [3] - https://github.com/fedora-selinux/selinux-policy/blob/rawhide/policy/modules... [4] - https://github.com/OpenVPN/openvpn3-linux/blob/master/src/selinux/openvpn3_s... [5] - https://github.com/fedora-selinux/selinux-policy/blob/rawhide/policy/modules... [6] - https://github.com/OpenVPN/openvpn3-linux/blob/b2d2eade5c7232ae55726cae7a449...
-- kind regards,
David Sommerseth OpenVPN Inc
On 03/04/2023 16:01, Vit Mojzis wrote:
On 3/31/23 18:09, David Sommerseth wrote:
On 31/03/2023 17:41, Petr Lautrbach wrote:
David Sommerseth dazo@eurephia.org writes:
[...snip...]
But for OpenVPN 3 Linux I do have an additional policy for a few of the D-Bus services as well. Would it make sense to just keep them in the openvpn3-linux project, or should I try to get them to some more widespread SELinux reference policies?
I'd suggest to keep them in the project and use
https://fedoraproject.org/wiki/SELinux/IndependentPolicy
I've added Vit who's expert in ^^
Thanks a lot!
I believe the policy we currently ship via Fedora Copr is in a reasonable state. It has also been somewhat reviewed by some of the SELinux/refpolicy maintainers and I've implemented proposed changes.
https://github.com/OpenVPN/openvpn3-linux/tree/master/src/selinux
The openvpn3.te policy is what I will suggest to fedora-selinux, as that may be useful for other projects as well.
The openvpn3_service.{fc,if,te} policy is OpenVPN 3 Linux specific.
Hi, thank you for taking the time to write your own policy. It is great when the policy is written by someone who actually understands what access the product needs.
Looking at the policy I have a few suggestions.
Thanks a lot for this review! I'll try to get everything in shape for our next release.
Just a short question ... This policy need to work on RHEL-7 to RHEL-9 and Fedora up to the latest releases. Are there anything I should beware of in that regards? Or will all your suggestions here work fine across all these releases?
On 4/4/23 14:22, David Sommerseth wrote:
On 03/04/2023 16:01, Vit Mojzis wrote:
On 3/31/23 18:09, David Sommerseth wrote:
On 31/03/2023 17:41, Petr Lautrbach wrote:
David Sommerseth dazo@eurephia.org writes:
[...snip...]
But for OpenVPN 3 Linux I do have an additional policy for a few of the D-Bus services as well. Would it make sense to just keep them in the openvpn3-linux project, or should I try to get them to some more widespread SELinux reference policies?
I'd suggest to keep them in the project and use
https://fedoraproject.org/wiki/SELinux/IndependentPolicy
I've added Vit who's expert in ^^
Thanks a lot!
I believe the policy we currently ship via Fedora Copr is in a reasonable state. It has also been somewhat reviewed by some of the SELinux/refpolicy maintainers and I've implemented proposed changes.
https://github.com/OpenVPN/openvpn3-linux/tree/master/src/selinux
The openvpn3.te policy is what I will suggest to fedora-selinux, as that may be useful for other projects as well.
The openvpn3_service.{fc,if,te} policy is OpenVPN 3 Linux specific.
Hi, thank you for taking the time to write your own policy. It is great when the policy is written by someone who actually understands what access the product needs.
Looking at the policy I have a few suggestions.
Thanks a lot for this review! I'll try to get everything in shape for our next release.
Just a short question ... This policy need to work on RHEL-7 to RHEL-9 and Fedora up to the latest releases. Are there anything I should beware of in that regards? Or will all your suggestions here work fine across all these releases?
That is a very good question. Most of the interfaces and what is in the "require" block should be stable (since it comes mostly if not completely from refpolicy) and you'll know if anything is missing once you build the package for each system (policy compilation would fail otherwise). But if you encounter any missing interface (that is most likely to occur in rhel-7) we have a workaround for that [1] which only takes effect when needed, so you can still use the same policy sources on all systems. One thing that does cause issues sometimes is compatibility of the compiled policy with selinux-policy-* packages (a binary policy compiled in rhel-8 will most likely not work in rhel-7 and even changes between minor releases can be enough to break compatibility). So please use the %{?selinux_requires} rpm macro [2] to require appropriate version of selinux-policy-* packages.
Feel free to to tag me in pull requests that have to do with the policy, or post them here.
Vit
[1] - https://fedoraproject.org/wiki/SELinux/IndependentPolicy#Backwards_compatibi... [2] - https://fedoraproject.org/wiki/SELinux/IndependentPolicy#Example_spec_file_c...
selinux@lists.fedoraproject.org
-
David Sommerseth -
Neal Gompa -
Petr Lautrbach -
Vit Mojzis