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@xxxxxxxxxxxx> 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?
-- kind regards, David Sommerseth OpenVPN Inc
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/kernel [2] - https://github.com/SELinuxProject/refpolicy/tree/master/policy/modules/system [3] - https://github.com/fedora-selinux/selinux-policy/blob/rawhide/policy/modules/contrib [4] - https://github.com/OpenVPN/openvpn3-linux/blob/master/src/selinux/openvpn3_service.te#L123 [5] - https://github.com/fedora-selinux/selinux-policy/blob/rawhide/policy/modules/contrib/abrt.te#L263 [6] - https://github.com/OpenVPN/openvpn3-linux/blob/b2d2eade5c7232ae55726cae7a44997460578f90/src/selinux/openvpn3_service.te#L59-- kind regards, David Sommerseth OpenVPN Inc
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ selinux mailing list -- selinux@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to selinux-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
