intrig...@debian.org:
> Package: tlsdate
> Version: 0.0.5-2
> Severity: important
>
> Hi,
>
> I'm starting tlsdate with "sudo service tlsdate start" on a Wheezy
> amd64 system with AppArmor enabled, and:
>
> 1. tlsdated does not start, hence the >>normal severity.
> 2. my syslog reads:
> kernel: [21040.419293] type=1400 audit(1365081871.989:61):
> apparmor="DENIED" operation="open" parent=1
> profile="/usr/bin/tlsdated"
> name="/usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0" pid=6341
> comm="tlsdated" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
>
> It does not look entirely scandalous that tlsdated wants to load
> libcrypto from this location, given:
>
> $ ldd /usr/bin/tlsdated | grep libcrypto
> libcrypto.so.1.0.0 => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
> (0x00007f743b798000)
>
I've updated the AppArmor profile to include /usr/lib/x86_64-linux-gnu/
in git commit 7976210871063f98d001221a7eac6901dfd47f81. This will go
into the next tlsdate release.
> Having a look at /etc/apparmor.d/usr.bin.tlsdate, it's obvious why.
> Most profiles in there have lines such as:
>
> # Allow mapping of shared libraries
> /lib/* rm,
> /lib32/* rm,
> /lib64/* rm,
> /usr/lib/* rm,
> /lib/x86_64-linux-gnu/* rm,
>
> (with variations on this theme, some have /usr/local/lib/* too, some
> haven't, but I digress :)
I've added this to each stanza:
/usr/lib/x86_64-linux-gnu/* rm,
>
> Unfortunately, this does not support multiarch library directories.
>
> I suggest using the @{multiarch} profile variable, as most other
> profiles I have installed do, instead of trying to do it by hand.
>
> See e.g. /etc/apparmor.d/abstractions/base for nice examples of how
> one may easily support all architectures that Debian supports :)
>
I'd be interested in researching this a bit later - how does this fail?
> I suspect that /usr/bin/tlsdate-helper will need access to
> /usr/lib/@{multiarch}/* too, for the same reason.
>
> (To end with, and digressing again, it looks like the few profiles
> that are in usr.bin.tlsdate could benefit from some factorization into
> abstractions/, possibly even using existing abstractions if they're
> not to wide for your taste. Shall I file a wishlist bug about it?)
>
Ideally, I'd prefer a patch. :)
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
