[Pkg-dns-devel] Bug#882731: Bug#882731: apparmor policy only accepts root.key in /var/lib/unbound

[Simon Deziel]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-dns-devel/attachments/20180130/e4bd27eb/attachment.sig>