Bug#760526: Enable AppArmor support (using libapparmor)
Hi, Michael Scherer wrote (11 Oct 2014 05:51:39 GMT) : Unfortunately, it seems the error code of aa_change_onexec is not propagated, which is a bug ( my fault, will correct upstream ). In the mean time, I guess we will have to use strace and/or gdb to get it and see what is going on. I will try to take a look later, once I can find a VM to debug it. Thanks a lot for caring about this :) Just to be clear: is any of this a blocker in your opinion to enable AppArmor support for Jessie (that is, in the next ~14 days), e.g. with the patch I've proposed? Cheers, -- intrigeri -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760526: Enable AppArmor support (using libapparmor)
On Sat, Oct 11, 2014 at 10:12:44AM +0200, intrigeri wrote: Hi, Michael Scherer wrote (11 Oct 2014 05:51:39 GMT) : Unfortunately, it seems the error code of aa_change_onexec is not propagated, which is a bug ( my fault, will correct upstream ). In the mean time, I guess we will have to use strace and/or gdb to get it and see what is going on. I will try to take a look later, once I can find a VM to debug it. Thanks a lot for caring about this :) Just to be clear: is any of this a blocker in your opinion to enable AppArmor support for Jessie (that is, in the next ~14 days), e.g. with the patch I've proposed? I am not sure if the question is for me, but I would say that the bug need to be fixed before enabling or saying it is supported. But I have no idea where is the problem, so if that's not in systemd, then we may miss the deadline. Ideally, backporting 5482192e5774f5 would help to debug, but I can do it myself I guess. And after battling with Digital Ocean, i was not able to make apparmor work on debian unstable, but mostly due to their platform. I will try again once I am back home to have a proper VM where i can decide the kernel to run without troubles. -- Michael Scherer -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760526: Enable AppArmor support (using libapparmor)
So, investigating the problem. The issue is that : ReadOnlyDirectories = / make aa_change_onexec fail with Oct 11 23:22:25 test-debian systemd[1985]: Failed at step APPARMOR spawning /usr/bin/tor: Read-only file system ( once there is proper reporting ). I suspect the issue is upstream, with the ordering of readonly vs apparmor. Adding : ReadWriteDirectories = /proc Seems to fix the issue as well. I am trying to see if I can fix properly upstream by moving around apparmor support in the source code. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760526: Enable AppArmor support (using libapparmor)
On Sun, Oct 12, 2014 at 01:40:29AM +0200, Michael scherer wrote: So, investigating the problem. The issue is that : ReadOnlyDirectories = / make aa_change_onexec fail with Oct 11 23:22:25 test-debian systemd[1985]: Failed at step APPARMOR spawning /usr/bin/tor: Read-only file system ( once there is proper reporting ). I suspect the issue is upstream, with the ordering of readonly vs apparmor. Adding : ReadWriteDirectories = /proc Seems to fix the issue as well. I am trying to see if I can fix properly upstream by moving around apparmor support in the source code. So there is a catch-22. If we set the profile before the mount, it fail with : Oct 12 00:13:40 test-debian systemd[1121]: Failed at step NAMESPACE spawning /usr/bin/tor: No such file or directory If we set it after, it fail with the previous error. I think someone need to see with upstream apparmor people about the proper way to do that. I will try to see on systemd-devel if someone know why it fail like this. -- Michael Scherer -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760526: Enable AppArmor support (using libapparmor)
On Sun, Oct 12, 2014 at 02:23:22AM +0200, Michael scherer wrote: On Sun, Oct 12, 2014 at 01:40:29AM +0200, Michael scherer wrote: So, investigating the problem. The issue is that : ReadOnlyDirectories = / make aa_change_onexec fail with Oct 11 23:22:25 test-debian systemd[1985]: Failed at step APPARMOR spawning /usr/bin/tor: Read-only file system ( once there is proper reporting ). I suspect the issue is upstream, with the ordering of readonly vs apparmor. Adding : ReadWriteDirectories = /proc Seems to fix the issue as well. I am trying to see if I can fix properly upstream by moving around apparmor support in the source code. So there is a catch-22. If we set the profile before the mount, it fail with : Oct 12 00:13:40 test-debian systemd[1121]: Failed at step NAMESPACE spawning /usr/bin/tor: No such file or directory If we set it after, it fail with the previous error. I think someone need to see with upstream apparmor people about the proper way to do that. I will try to see on systemd-devel if someone know why it fail like this. So after a rather long debugging seance, the problem is a false positive. If /var/run/tor do not exist, then it fail to mount it, obviously. And I gues it doesn't existe because /var/run is on a tmpfs, and I didn't create the proper configuration to create it on boot. So yeah, putting apparmor code before namespace code is the proper fix. I am gonna send it upstream, and then up to you to decide either to backport/adapt, or to just work around with /proc being rw. -- Michael Scherer -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760526: Enable AppArmor support (using libapparmor)
So yeah, putting apparmor code before namespace code is the proper fix. I am gonna send it upstream, and then up to you to decide either to backport/adapt, or to just work around with /proc being rw. Patch sent upstream : http://lists.freedesktop.org/archives/systemd-devel/2014-October/023909.html -- Michael Scherer -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760526: Enable AppArmor support (using libapparmor)
Unfortunately, it seems the error code of aa_change_onexec is not propagated, which is a bug ( my fault, will correct upstream ). In the mean time, I guess we will have to use strace and/or gdb to get it and see what is going on. I will try to take a look later, once I can find a VM to debug it. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760526: Enable AppArmor support (using libapparmor)
Hi, intrigeri wrote (24 Sep 2014 05:33:37 GMT) : So, I don't think that the problem I'm seeing here is a blocker for enabling AppArmor support in systemd. The attached patch implements this. Once something like this is applied, I'll clone this bug report to track the remaining problems. Anything else I can do to help have this feature enabled in Jessie? Cheers, -- intrigeri -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760526: Enable AppArmor support (using libapparmor)
Hi,
intrigeri wrote (09 Sep 2014 00:14:30 GMT) :
So: yes, please. I've been waiting for it eagerly, and will submit
patches to the Tor upstream unit file as soon as Debian's systemd
supports this option.
I really want this to land in time for Jessie, so I've given it a try:
1. added libapparmor-dev to build-depends
2. the current apparmor package in Debian lacked pkg-config support,
and thus the systemd build systemd did not detect it, so:
3. uploaded apparmor 2.8.0-8 with pkg-config support
4. now systemd builds fine, with AppArmor support according to the
build log. Woohoo, first milestone reached! :)
Remaining problems:
a) I don't see any dependency automatically added on libapparmor1, and
I've no idea which binary package exactly should have it. Any hint?
b) The AppArmor support actually doesn't work for me. With the
attached unit file for Tor (i.e. the upstream one, slightly
adjusted for Debian), after un-commenting the AppArmorProfile
directive, running `systemctl --system daemon-reload', and trying
to restart the service, it fails to start. Status:
● tor.service - Anonymizing overlay network for TCP
Loaded: loaded (/etc/systemd/system/tor.service; disabled)
Active: failed (Result: start-limit) since Mon 2014-09-22 23:31:52 PDT;
3s ago
Process: 24186 ExecStartPre=/usr/bin/tor --defaults-torrc
/usr/share/tor/tor-service-defaults-torrc --verify-config (code=exited,
status=231/APPARMOR)
Main PID: 26773 (code=exited, status=0/SUCCESS)
Sep 22 23:31:52 ensifera systemd[1]: Unit tor.service entered failed state.
Sep 22 23:31:52 ensifera systemd[1]: tor.service start request repeated too
quickly, refusing to start.
Sep 22 23:31:52 ensifera systemd[1]: Failed to start Anonymizing overlay
network for TCP.
Sep 22 23:31:52 ensifera systemd[1]: Unit tor.service entered failed state.
zsh: exit 3 sudo service tor status
The status=231/APPARMOR seems to contain (the beginning of) an
explanation, but I'm no C programmer, so diving into the source code
to understand what it can possibly mean is a bit outside of my comfort
zone. Note that the system_tor AppArmor profile *is* loaded in the
kernel, confirmed with aa-status.
Note that the version of the AppArmor userspace we're carrying in
Debian currently is a bit old, and it might be that the AppArmor
support in systemd was only tested with a newer version. If I find
a slot on my copious free time in the next days or weeks, I'll try to
reproduce this problem with the latest upstream version.
Cheers,
--
intrigeri
[Unit]
Description = Anonymizing overlay network for TCP
After = syslog.target network.target nss-lookup.target
[Service]
Type = simple
ExecStartPre = /usr/bin/tor --defaults-torrc
/usr/share/tor/tor-service-defaults-torrc --verify-config
# A torrc that has RunAsDaemon 1 won't work with the simple service type;
# let's explicitly override it.
ExecStart = /usr/bin/tor --defaults-torrc
/usr/share/tor/tor-service-defaults-torrc --RunAsDaemon 0
ExecReload = /bin/kill -HUP ${MAINPID}
KillSignal = SIGINT
TimeoutSec = 30
Restart = on-failure
LimitNOFILE = 32768
# Hardening
PrivateTmp = yes
DeviceAllow = /dev/null rw
DeviceAllow = /dev/urandom r
InaccessibleDirectories = /home
ReadOnlyDirectories = /
ReadWriteDirectories = /var/lib/tor
ReadWriteDirectories = /var/log/tor
ReadWriteDirectories = /var/run/tor
NoNewPrivileges = yes
#AppArmorProfile = system_tor
[Install]
WantedBy = multi-user.target
Bug#760526: Enable AppArmor support (using libapparmor)
Am 23.09.2014 um 08:51 schrieb intrigeri: Hi, intrigeri wrote (09 Sep 2014 00:14:30 GMT) : So: yes, please. I've been waiting for it eagerly, and will submit patches to the Tor upstream unit file as soon as Debian's systemd supports this option. I really want this to land in time for Jessie, so I've given it a try: 1. added libapparmor-dev to build-depends 2. the current apparmor package in Debian lacked pkg-config support, and thus the systemd build systemd did not detect it, so: 3. uploaded apparmor 2.8.0-8 with pkg-config support 4. now systemd builds fine, with AppArmor support according to the build log. Woohoo, first milestone reached! :) Remaining problems: a) I don't see any dependency automatically added on libapparmor1, and I've no idea which binary package exactly should have it. Any hint? Did you add --enable-apparmor to the configure flags? -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#760526: Enable AppArmor support (using libapparmor)
Hi, Michael Biebl wrote (23 Sep 2014 11:59:22 GMT) : a) I don't see any dependency automatically added on libapparmor1, and I've no idea which binary package exactly should have it. Any hint? Did you add --enable-apparmor to the configure flags? I didn't: my understanding of the upstream build system is that AppArmor support is opt-out (if libapparmor-dev can be found, it's enabled by default). But I'll trust you that explicitly enabling it might affect the resulting runtime dependencies, and will try that :) Cheers, -- intrigeri -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760526: Enable AppArmor support (using libapparmor)
Control: tag -1 + patch
Hi,
intrigeri wrote (23 Sep 2014 17:01:21 GMT) :
Michael Biebl wrote (23 Sep 2014 11:59:22 GMT) :
a) I don't see any dependency automatically added on libapparmor1, and
I've no idea which binary package exactly should have it. Any hint?
Did you add --enable-apparmor to the configure flags?
I tried it, and indeed the binary systemd package now Depends:
libapparmor1 (= 2.6~devel). Thanks!
So, only problem (b) remains. I was able to workaround it by
commenting out these directives in the unit file:
ReadOnlyDirectories = /
ReadWriteDirectories = /var/lib/tor
ReadWriteDirectories = /var/log/tor
ReadWriteDirectories = /var/run/tor
Note that for some reason, leaving this directive in is not a problem,
though:
InaccessibleDirectories = /home
And adding these directives works too:
ProtectSystem = full
ProtectHome = yes
To make sure this problem wasn't caused by the old apparmor package we
have, I've prepared a 2.8.96~2652-1 apparmor package yesterday, which
is now in experimental, and rebuilt systemd against it. Then, I've
tested the resulting systemd packages on a system that has apparmor
2.8.96~2652-1 from experimental, and I see the same problem, the and
same workaround applies.
Should we take this problem upstream? I've not subscribed to the
systemd ML, and never interacted with them yet, so I'd rather see you
do that. Still, if you can't or don't want to do it, I guess I can try
to find time to learn how to communicate with yet another friendly
upstream community... during the Jessie+1 dev cycle.
In any case:
* According to codesearch, there's exactly zero unit file in Debian
currently that uses AppArmorProfile= (not a surprise, considering
systemd doesn't support it in Debian yet), let alone combined with
Read{Only,Write}Directories.
* As far as the Tor unit file is concerned, the
Read{Only,Write}Directories directives are not part of the unit
file shipped upstream in the version (0.2.5.x) that will be in
Jessie, so that's not a real problem yet, and we can add
AppArmorProfile= in there. These directories are in Tor 0.2.6.x,
though, so we'll have to handle it somehow for Jessie+1.
So, I don't think that the problem I'm seeing here is a blocker for
enabling AppArmor support in systemd. The attached patch implements
this. Once something like this is applied, I'll clone this bug report
to track the remaining problems.
Cheers,
--
intrigeri
From 6157f1c74e55189cf663904bef429b36dcc2a48f Mon Sep 17 00:00:00 2001
From: intrigeri intrig...@debian.org
Date: Tue, 23 Sep 2014 04:57:13 +
Subject: [PATCH] Enable AppArmor support (Closes: #760526)
- add build-dependency on libapparmor-dev
- add --enable-apparmor to the configure flags
---
debian/control | 1 +
debian/rules | 1 +
2 files changed, 2 insertions(+)
diff --git a/debian/control b/debian/control
index f27beb9..3c02037 100644
--- a/debian/control
+++ b/debian/control
@@ -21,6 +21,7 @@ Build-Depends: debhelper (= 9),
autoconf (= 2.63),
intltool,
gperf,
+ libapparmor-dev,
libcap-dev,
libpam0g-dev,
libaudit-dev,
diff --git a/debian/rules b/debian/rules
index 5a0b8c3..d371d72 100755
--- a/debian/rules
+++ b/debian/rules
@@ -25,6 +25,7 @@ CONFFLAGS = \
--disable-microhttpd \
--disable-sysusers \
--disable-silent-rules \
+ --enable-apparmor \
--with-ntp-servers=0.debian.pool.ntp.org 1.debian.pool.ntp.org 2.debian.pool.ntp.org 3.debian.pool.ntp.org \
--with-system-uid-max=999 \
--with-system-gid-max=999
--
2.1.1
Bug#760526: Enable AppArmor support (using libapparmor)
Hi, Michael Biebl wrote (05 Sep 2014 00:16:43 GMT) : With AppArmor support enabled, services can make use of the AppArmorProfile= option [1]. This option is e.g. needed for the systemd unit file for Tor to be on-par, functionality-wise, with the current initscript we have (a shell wrapper dirty hack would be feasible, but I'd rather avoid doing that when a much better way is available). This specific usecase was actually one of the reasons why Michael Scherer implemented the AppArmorProfile= option upstream initially. So: yes, please. I've been waiting for it eagerly, and will submit patches to the Tor upstream unit file as soon as Debian's systemd supports this option. CCing Kees here, since he is the maintainer of apparmor. ... which is in the process of moving to team-maintenance (decided in-person at DebConf with Kees), so Cc'ing the team :) Cheers, -- intrigeri -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
