dnsmasq requires access to /usr/share/dnsmasq for dnssec. The attached patch adds dnsmasq_usr_share_t for this purpose. Side note: I could not find any replacement repo for git.overlays, so this patch was made against a possibly outdated tree and may not apply cleanly.
Created attachment 391084 [details, diff] patch to add dnsmasq_usr_share_t
_usr_share_t is not a common naming. What is inside the /usr/share/dnsmasq location? What is the advantage beyond allowing it read access to usr_t (if it doesn't have it already)?
(In reply to Sven Vermeulen from comment #2) > _usr_share_t is not a common naming. I had noticed that. I have only recently begun to use SELinux (with contribution to gentoo policy in mind), and continue to use grsecurity's RBAC as defense in depth partly for that reason. > What is inside the /usr/share/dnsmasq location? I do not know enough of how DNSSEC works to answer precisely. The gist if it, as I understand it, is a list of fingerprints for DNS root signing keys. > What is the advantage beyond > allowing it read access to usr_t (if it doesn't have it already)? That depends on your threat model (it doesn't). Mine is of an adversary on the other side of a mixing network, having taken control of dnsmasq, attempting to exfiltrate a fingerprint of the system for later forensics. (It is my understanding that MAC is for defense against already compromised subjects.) I do not wish to push the issue, and from a purely selfish standpoint, I would rather the module stay as it is, since it is easier to keep these changes locally than it would be to update custom policy minus full usr_t read privilege on top of future changes. Thank you for your review.
I think it makes more sense to mark /usr/share/dnsmasq as dnsmasq_etc_t as the file(s) in that location are configuration-related (etc). Can you try the following? ~# semanage fcontext -a -t dnsmasq_etc_t "/usr/share/dnsmasq(/.*)?" ~# restorecon -RF /usr/share/dnsmasq I think dnsmasq can work with that, as it has search privs on usr_t so it can access the location.
(In reply to Sven Vermeulen from comment #4) > I think it makes more sense to mark /usr/share/dnsmasq as dnsmasq_etc_t as > the file(s) in that location are configuration-related (etc). > > Can you try the following? > > ~# semanage fcontext -a -t dnsmasq_etc_t "/usr/share/dnsmasq(/.*)?" > ~# restorecon -RF /usr/share/dnsmasq > > I think dnsmasq can work with that, as it has search privs on usr_t so it > can access the location. Yes that works, and does not reveal any more information about dnsmasq to other domains than the patch does. So providing upstream permits types describing a different location, your solution is ideal. Two (slightly OT) questions: * Is sharing types across locations like that, where the type's name only describes one of those locations, preferred? * Is there a publicly pullable copy of hardened-refpolicy, and if so, where? Btw you might like to skim through my github repo, perhaps some of the modules would fit Gentoo policy (znc, dnscrypt-proxy, tlsdate, webkit-gtk/midori, Xephyr, pidgin, for instance.)
I mirror refpolicy through github: https://github.com/sjvermeu/hardened-refpolicy Hopefully the anonymous git access to Gentoo's git repositories is opened up soon. Regarding the reuse of types: there are no strict rules on this. My experience tells me that, if a type can be reused, then it is generally reused. Note that the _etc_t is not meant to refer to /etc/ location, but to configuration and other miscellaneous data used by an application (usually read-only) and necessary for it to function properly.
Added in repo, will be in rev 3
in ~arch
r4 is stable
