[apparmor] missing 'mr' on binary for usage on containers

Bug #1827253 reported by Simon Déziel on 2019-05-01
12
This bug affects 1 person
Affects Status Importance Assigned to Milestone
rsyslog (Ubuntu)
Undecided
Unassigned
Bionic
Low
Unassigned
Disco
Low
Unassigned

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@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@rs1:~# lsb_release -rd
Description: Ubuntu Eoan EANIMAL (development branch)
Release: 19.10
root@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)

Related branches

Simon Déziel (sdeziel) wrote :
tags: added: server-next
Changed in rsyslog (Ubuntu):
status: New → In Progress

This actually is a perfect bug:
- simple case
- solution on a silver plate
- only changing d/* content
- already ubuntu Delta

I feel bad that this hung around so log, but today I saw it and gave it a review.
This is building in Eoan now.

On 2019-07-03 10:47 a.m., Christian Ehrhardt  wrote:
> I feel bad that this hung around so log, but today I saw it and gave it a review.
> This is building in Eoan now.

No worries for the delay, I know where to find you if something more
critical is taking too long to my taste ;) Thank you Christian!

Regards,
Simon

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package rsyslog - 8.1901.0-1ubuntu2

---------------
rsyslog (8.1901.0-1ubuntu2) eoan; urgency=medium

  [ Simon Deziel ]
  * d/usr.sbin.rsyslogd: allow reading/mmap'ing rsyslog binary
    This is required for usage inside containers (LP: #1827253)

 -- Christian Ehrhardt <email address hidden> Wed, 03 Jul 2019 16:34:41 +0200

Changed in rsyslog (Ubuntu):
status: In Progress → Fix Released
Simon Déziel (sdeziel) wrote :

I'm hitting the same problem when using a Bionic host with a Bionic container when using the 5.0 HWE kernel.

@paelzer, I'd appreciate if this could be SRU'ed to Bionic, please :)

The fix is trivial, so this should be fine.
But I'm just back from PTO and a bit swamped by TODOs right now, so bear with me as I'll need some time :-)

Changed in rsyslog (Ubuntu Bionic):
status: New → Triaged
Changed in rsyslog (Ubuntu Disco):
status: New → Triaged
description: updated

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

MPs got reviewed and uploaded to D/B SRU queue

Łukasz Zemczak (sil2100) wrote :

Reviewing this, it feels to me like something nice to have, but low-importance enough that I'd be worried about users getting an upgrade with no impact for them (and, as per the regression potential, some low-chance but still regression risk). The SRU policy is a bit conflicted there: on one side we should only do high-impact bugs *or* low-risk bugs in case of applications. But this is rsyslog, so something a bit more low-level, so it's up to some interpretation as to what the policy thinks about it.

One option would be to accept it into -proposed pockets and set the block-proposed-* tags to not make it migrate, only including it in case some additional SRU gets uploaded on top. Would that be fine? The only problem I see is that rsyslog doesn't seem to have an active SRU history looking a disco and bionic, so the chances this would go out into -updates would be low...

Thanks for the review Łukasz,
I somewhat agree with your summary. The reason I went on with it was because it was very low hanging fruit and Simon (Bug reporter) is like "The Ubuntu community good bug reports role model".
But I agree that the update for everyone (it is always installed) might be too much.

I'd be ok getting it only to proposed, we have done so in the past for other things and since it can be changed by the user prio is low anyway.

@Simon - opinions on proposed / abort / convince ?

Simon Déziel (sdeziel) wrote :

Thanks Łukasz and Christian. I find the block-proposed-* tags idea interesting if that's not too much work on your side.

Hello Simon, or anyone else affected,

Accepted rsyslog into disco-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/rsyslog/8.32.0-1ubuntu7.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-disco to verification-done-disco. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-disco. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

tags: added: block-proposed-bionic block-proposed-disco
Changed in rsyslog (Ubuntu Disco):
status: Triaged → Fix Committed
tags: added: verification-needed verification-needed-disco
Changed in rsyslog (Ubuntu Bionic):
status: Triaged → Fix Committed
tags: added: verification-needed-bionic
Robie Basak (racb) wrote :

Hello Simon, or anyone else affected,

Accepted rsyslog into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/rsyslog/8.32.0-1ubuntu4.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Simon Déziel (sdeziel) wrote :

I feel really bad now :/

The initial commit that went in doesn't even fix the problem due to a typo/confusion. The proposed manual workaround was OK but the merge proposal was not.

 "/usr/sbin/rsyslog mr," != "/usr/sbin/rsyslogd mr,"

I'm failing the verification and have proposed a new MP. Sorry.

tags: added: verification-failed verification-failed-bionic verification-failed-disco
removed: verification-needed verification-needed-bionic verification-needed-disco
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers