[Bug 1827253] Re: [apparmor] missing 'mr' on binary for usage on containers
Christian Ehrhardt
1827253 at bugs.launchpad.net
Mon Oct 14 06:59:41 UTC 2019
I prepped the two MPs for the SRU as this isn't the biggest impact fix,
but OTOH patch-on-a-platter and also easy to review for code/impact.
** Changed in: rsyslog (Ubuntu Disco)
Importance: Undecided => Low
** Changed in: rsyslog (Ubuntu Bionic)
Importance: Undecided => Low
** Description changed:
[Impact]
- * rsyslog ships with a (Default disable) apparmor profile.
- * Security sensitive users are in general encouraged to enable such
- profiles but unfortunately due to slightly new behavior of the program
- the profile prevents its usage.
- * Allow the program to map/read its binary to get this working again
+ * rsyslog ships with a (Default disable) apparmor profile.
+ * Security sensitive users are in general encouraged to enable such
+ profiles but unfortunately due to slightly new behavior of the program
+ the profile prevents its usage.
+ * Allow the program to map/read its binary to get this working again
[Test Case]
1) Create a 'eoan' container called rs1 here:
lxc launch ubuntu-daily:e rs1
2) Enter the container
lxc shell rs1
3) Enable apparmor profile
rm /etc/apparmor.d/disable/usr.sbin.rsyslogd
apparmor_parser -r -T -W /etc/apparmor.d/usr.sbin.rsyslogd
systemctl restart rsyslog
4) notice rsyslog failed to start
systemctl status rsyslog
[Regression Potential]
- * This is just opening up the apparmor profile a bit. Therefore the only
- regression it could cause IMHO is a security issue. But then what it
- actually allows is reading (not writing!) its own binary which should
- be very safe.
+ * This is just opening up the apparmor profile a bit. Therefore the only
+ regression it could cause IMHO is a security issue. But then what it
+ actually allows is reading (not writing!) its own binary which should
+ be very safe.
+ * Thinking further it came to my mind that package updates (independent
+ to the change) might restart services and that means if there is any
+ issue e.g. in a local config that worked but now fails (not by this
+ change but in general) then the upgrade will not cause, but trigger
+ this. This is a general regression risk for any upload, but in this
+ case worth to mention as it is about log handling - which if broken -
+ makes large scale systems hard to debug.
[Other Info]
-
- * n/a
+
+ * n/a
---
Issue description:
Enabling the rsyslog (disabled by default) Apparmor profile causes
rsyslog to fail to start when running *inside a container*.
Steps to reproduce:
1) Create a 'eoan' container called rs1 here:
lxc launch ubuntu-daily:e rs1
2) Enter the container
lxc shell rs1
3) Enable apparmor profile
rm /etc/apparmor.d/disable/usr.sbin.rsyslogd
apparmor_parser -r -T -W /etc/apparmor.d/usr.sbin.rsyslogd
systemctl restart rsyslog
4) notice rsyslog failed to start
systemctl status rsyslog
Workaround:
echo ' /usr/sbin/rsyslogd mr,' >> /etc/apparmor.d/local/usr.sbin.rsyslogd
apparmor_parser -r -T -W /etc/apparmor.d/usr.sbin.rsyslogd
systemctl restart rsyslog
Additional information:
root at rs1:~# uname -a
Linux rs1 4.15.0-48-generic #51-Ubuntu SMP Wed Apr 3 08:28:49 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
root at rs1:~# lsb_release -rd
Description: Ubuntu Eoan EANIMAL (development branch)
Release: 19.10
root at rs1:~# dpkg -l| grep -wE 'apparmor|rsyslog'
ii apparmor 2.13.2-9ubuntu6 amd64 user-space parser utility for AppArmor
ii rsyslog 8.32.0-1ubuntu7 amd64 reliable system and kernel logging daemon
ProblemType: Bug
DistroRelease: Ubuntu 19.10
Package: rsyslog 8.32.0-1ubuntu7
ProcVersionSignature: Ubuntu 4.15.0-48.51-generic 4.15.18
Uname: Linux 4.15.0-48-generic x86_64
ApportVersion: 2.20.10-0ubuntu27
Architecture: amd64
Date: Wed May 1 17:36:29 2019
ProcEnviron:
TERM=xterm-256color
PATH=(custom, no user)
XDG_RUNTIME_DIR=<set>
LANG=en_US.UTF-8
SHELL=/bin/bash
SourcePackage: rsyslog
UpgradeStatus: No upgrade log present (probably fresh install)
--
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to rsyslog in Ubuntu.
https://bugs.launchpad.net/bugs/1827253
Title:
[apparmor] missing 'mr' on binary for usage on containers
Status in rsyslog package in Ubuntu:
Fix Released
Status in rsyslog source package in Bionic:
Triaged
Status in rsyslog source package in Disco:
Triaged
Bug description:
[Impact]
* rsyslog ships with a (Default disable) apparmor profile.
* Security sensitive users are in general encouraged to enable such
profiles but unfortunately due to slightly new behavior of the program
the profile prevents its usage.
* Allow the program to map/read its binary to get this working again
[Test Case]
1) Create a 'eoan' container called rs1 here:
lxc launch ubuntu-daily:e rs1
2) Enter the container
lxc shell rs1
3) Enable apparmor profile
rm /etc/apparmor.d/disable/usr.sbin.rsyslogd
apparmor_parser -r -T -W /etc/apparmor.d/usr.sbin.rsyslogd
systemctl restart rsyslog
4) notice rsyslog failed to start
systemctl status rsyslog
[Regression Potential]
* This is just opening up the apparmor profile a bit. Therefore the only
regression it could cause IMHO is a security issue. But then what it
actually allows is reading (not writing!) its own binary which should
be very safe.
* Thinking further it came to my mind that package updates (independent
to the change) might restart services and that means if there is any
issue e.g. in a local config that worked but now fails (not by this
change but in general) then the upgrade will not cause, but trigger
this. This is a general regression risk for any upload, but in this
case worth to mention as it is about log handling - which if broken -
makes large scale systems hard to debug.
[Other Info]
* n/a
---
Issue description:
Enabling the rsyslog (disabled by default) Apparmor profile causes
rsyslog to fail to start when running *inside a container*.
Steps to reproduce:
1) Create a 'eoan' container called rs1 here:
lxc launch ubuntu-daily:e rs1
2) Enter the container
lxc shell rs1
3) Enable apparmor profile
rm /etc/apparmor.d/disable/usr.sbin.rsyslogd
apparmor_parser -r -T -W /etc/apparmor.d/usr.sbin.rsyslogd
systemctl restart rsyslog
4) notice rsyslog failed to start
systemctl status rsyslog
Workaround:
echo ' /usr/sbin/rsyslogd mr,' >> /etc/apparmor.d/local/usr.sbin.rsyslogd
apparmor_parser -r -T -W /etc/apparmor.d/usr.sbin.rsyslogd
systemctl restart rsyslog
Additional information:
root at rs1:~# uname -a
Linux rs1 4.15.0-48-generic #51-Ubuntu SMP Wed Apr 3 08:28:49 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
root at rs1:~# lsb_release -rd
Description: Ubuntu Eoan EANIMAL (development branch)
Release: 19.10
root at rs1:~# dpkg -l| grep -wE 'apparmor|rsyslog'
ii apparmor 2.13.2-9ubuntu6 amd64 user-space parser utility for AppArmor
ii rsyslog 8.32.0-1ubuntu7 amd64 reliable system and kernel logging daemon
ProblemType: Bug
DistroRelease: Ubuntu 19.10
Package: rsyslog 8.32.0-1ubuntu7
ProcVersionSignature: Ubuntu 4.15.0-48.51-generic 4.15.18
Uname: Linux 4.15.0-48-generic x86_64
ApportVersion: 2.20.10-0ubuntu27
Architecture: amd64
Date: Wed May 1 17:36:29 2019
ProcEnviron:
TERM=xterm-256color
PATH=(custom, no user)
XDG_RUNTIME_DIR=<set>
LANG=en_US.UTF-8
SHELL=/bin/bash
SourcePackage: rsyslog
UpgradeStatus: No upgrade log present (probably fresh install)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1827253/+subscriptions
More information about the foundations-bugs
mailing list