I don't think it is so easy. It can add facl on resolv.conf file before it drops privileges. But Any other process might remove the file again and write a new one, preventing openvpn to update it later. Because openvpn is not supposed to be owner of /etc/resolv.conf, it should not dictate what rights it needs. For example dnsmasq solves similar problem by forking second process connected by a pipe with original. Original then drops privileges and switches to unprivileged user, just keeping NET_ADMIN to be able reopening privileged ports. When it requires lease changes, it sends request over pipe to process still with enough privileges. Because it does not have any other sockets open to attackers, it just have to check input data sufficiently. I think similar position might have netcfg part. It seems safe enough to keep root privileges to manipulate resolv.conf (or resolvconf). On 3/1/21 2:35 PM, Kevin Kofler via devel wrote: > Petr Menšík wrote: >> It is about 2 years when we were removing CAP_DAC_OVERRIDE from our >> services, because selinux-policy does not grant it anymore. I think it >> is a good thing. Running as openvpn user, but requiring then >> CAP_DAC_OVERRIDE is insecure! It gives it more rights than just root >> users without this permission would have. I would suggest reconsider >> such design and run netcfg as root, just with dropped capabilities >> except CAP_NET_ADMIN, if it needs to modify resolv.conf. resolvconf call >> should not pose significant threat. > > IMHO, the proper fix would be to have a proper facl on resolv.conf for the > openvpn user. > > Kevin Kofler -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemensik@xxxxxxxxxx PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-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/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
