Re: How is the upstream SELinux refpolicy tied into Fedora?

On 3/31/23 18:09, David Sommerseth wrote:
> On 31/03/2023 17:41, Petr Lautrbach wrote:
>> David Sommerseth <[email protected]> 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 -- [email protected]
To unsubscribe send an email to [email protected]
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/[email protected]
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue