Bug#704680: tlsdate: AppArmor profile does not support multiarch library locations = tlsdated does not start

2013-10-31 Thread Jacob Appelbaum 
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 
 (0x7f743b798000)
 

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

Bug#704680: tlsdate: AppArmor profile does not support multiarch library locations = tlsdated does not start

2013-10-31 Thread intrigeri 
Jacob Appelbaum wrote (31 Oct 2013 10:43:56 GMT) :
 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?

This will fail on any architecture other than i386 amd64, basically.
See where libcrypto is installed on these architectures.

I don't think this bug was entirely fixed (still no multiarch support
as far as I can see, despite the added support for amd64), so it
should probably be reopened.

Cheers,
-- 
  intrigeri
  | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
  | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#704680: tlsdate: AppArmor profile does not support multiarch library locations = tlsdated does not start

2013-04-04 Thread intrigeri 
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 
(0x7f743b798000)

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 :)

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 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?)

Cheers,
--
  intrigeri
  | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
  | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org