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.
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
_______________________________________________
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
