Bug#882731: apparmor policy only accepts root.key in /var/lib/unbound

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Bug#882731: apparmor policy only accepts root.key in /var/lib/unbound

Peter Palfrader
Package: unbound
Version: 1.6.7-1
User: [hidden email]
Usertags: needed-by-DSA-Team
Control: found -1 1.6.0-3+deb9u1
X-Debbugs-Cc: [hidden email]

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.

--
                            |  .''`.       ** Debian **
      Peter Palfrader       | : :' :      The  universal
 https://www.palfrader.org/ | `. `'      Operating System
                            |   `-    https://www.debian.org/

Reply | Threaded
Open this post in threaded view
|

Bug#882731: apparmor policy only accepts root.key in /var/lib/unbound

Simon Deziel-2
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.

Regards,
Simon

bug882731.diff (675 bytes) Download Attachment
signature.asc (817 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#882731: apparmor policy only accepts root.key in /var/lib/unbound

Peter Palfrader
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.

Cheers,
--
                            |  .''`.       ** Debian **
      Peter Palfrader       | : :' :      The  universal
 https://www.palfrader.org/ | `. `'      Operating System
                            |   `-    https://www.debian.org/

Reply | Threaded
Open this post in threaded view
|

Bug#882731: apparmor policy only accepts root.key in /var/lib/unbound

Simon Deziel-2
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.


bug882731-v2.diff (707 bytes) Download Attachment
signature.asc (817 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Robert Edmonds-4
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?

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?

--
Robert Edmonds
[hidden email]

Reply | Threaded
Open this post in threaded view
|

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

Simon Deziel-2
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 (817 bytes) Download Attachment