On 2018-01-30 03:40 PM, Robert Edmonds wrote: > Simon Deziel wrote: >> On 2017-11-27 09:22 AM, Peter Palfrader wrote: >>> On Mon, 27 Nov 2017, Simon Deziel wrote: >>> >>>> On 2017-11-26 03:31 AM, Peter Palfrader wrote: >>>>> The apparmor policy for unbound allows access to >>>>> /var/lib/unbound/root.key*, but it does not allow access to any >>>>> other dynamically updated key the admin might have put there, >>>>> such as debian.org.key on DSA infrastructure. >>>>> >>>>> Please allow access to all key files. >>>> >>>> Please see the attached patch. >>> >>>> # chrooted paths >>>> /var/lib/unbound/** r, >>>> + owner /var/lib/unbound/*.key* rw, >>>> owner /var/lib/unbound/**/*.key* rw, >>> >>> This would allow /var/lib/unbound/root.key "twice", once via root.key, >>> once via *.key. >> >> Indeed, this patch should be better, thanks Peter. > > Hi, > > I'm a little bit confused here. The unbound daemon runs as user > 'unbound', thus it should have read-write permission to the directory > /var/lib/unbound/, because that's what the permission on the directory > is. Is the apparmor policy intentionally overriding this?
Yes. > There's no requirement that an auto-trust-anchor-file be configured with > a filename that ends in ".key". Does the apparmor policy break unbound > if a sysadmin doesn't follow this convention? Yes. Preventing writes in /etc/unbound made sense (to me) and it was carried over to /var/lib/unbound. I agree that such restrictions for /var/lib/unbound are not warranted and breaks the principle of least surprise. Feel free to scrap those restrictions, I can provide a patch/updated profile if that's easier [*]. I think there is still some value in keeping the "audit deny" rules to alert an admin if something fishy is done on the cert/key used by the control channel. Regards, Simon *: I could also bundle the tiny fix for bug 867186 in it
signature.asc
Description: OpenPGP digital signature