Confined binaries running in namespaces unable to read their executable

[Simon Déziel]

It seems that binaries confined by Apparmor attempt to read their own executable when running in a namespace/container. This breaks many profiles that are working perfectly well outside of namespaces.

Original description:

I'm not sure if it's a bug that belongs to Apparmor, rsyslog or even the kernel so please re-assign if needed.

Enabling rsyslog's Apparmor profile in a namespace generates this denial:

[ 3026.956651] audit: type=1400 audit(1487955263.521:39): apparmor="DENIED" operation="file_mprotect" namespace="root//lxd-ganymede_<var-lib-lxd>" profile="/usr/sbin/rsyslogd" name="/usr/sbin/rsyslogd" pid=4165 comm="rsyslogd" requested_mask="r" denied_mask="r" fsuid=165536 ouid=165536

This prevents rsyslog from starting in the said container:

root@ganymede:~# systemctl status rsyslog
● rsyslog.service - System Logging Service
   Loaded: loaded (/lib/systemd/system/rsyslog.service; enabled; vendor preset: enabled)
   Active: inactive (dead) (Result: exit-code) since Fri 2017-02-24 11:54:24 EST; 30min ago
     Docs: man:rsyslogd(8)
           http://www.rsyslog.com/doc/
  Process: 232 ExecStart=/usr/sbin/rsyslogd -n (code=exited, status=127)
 Main PID: 232 (code=exited, status=127)

Feb 24 11:54:24 ganymede systemd[1]: Failed to start System Logging Service.
Feb 24 11:54:24 ganymede systemd[1]: rsyslog.service: Unit entered failed state.
Feb 24 11:54:24 ganymede systemd[1]: rsyslog.service: Failed with result 'exit-code'.
Feb 24 11:54:24 ganymede systemd[1]: rsyslog.service: Service hold-off time over, scheduling restart.
Feb 24 11:54:24 ganymede systemd[1]: Stopped System Logging Service.
Feb 24 11:54:24 ganymede systemd[1]: rsyslog.service: Start request repeated too quickly.
Feb 24 11:54:24 ganymede systemd[1]: Failed to start System Logging Service.

I don't know why rsyslog wants to read its own binary but it seems to really want to.

Both the host and the guest are up to date Xenials. Please not that the host runs the kernel from -proposed.

root@jupiter:~# apt-cache policy linux-image-4.4.0-65-generic apparmor rsyslog
linux-image-4.4.0-65-generic:
  Installed: 4.4.0-65.86
  Candidate: 4.4.0-65.86
  Version table:
 *** 4.4.0-65.86 100
        100 /var/lib/dpkg/status
apparmor:
  Installed: 2.10.95-0ubuntu2.5
  Candidate: 2.10.95-0ubuntu2.5
  Version table:
 *** 2.10.95-0ubuntu2.5 500
        500 http://archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages
        100 /var/lib/dpkg/status
     2.10.95-0ubuntu2 500
        500 http://archive.ubuntu.com/ubuntu xenial/main amd64 Packages
rsyslog:
  Installed: 8.16.0-1ubuntu3
  Candidate: 8.16.0-1ubuntu3
  Version table:
 *** 8.16.0-1ubuntu3 500
        500 http://archive.ubuntu.com/ubuntu xenial/main amd64 Packages
        100 /var/lib/dpkg/status

ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: apparmor 2.10.95-0ubuntu2.5
ProcVersionSignature: Ubuntu 4.4.0-65.86-generic 4.4.49
Uname: Linux 4.4.0-65-generic x86_64
NonfreeKernelModules: zfs zunicode zcommon znvpair zavl
ApportVersion: 2.20.1-0ubuntu2.5
Architecture: amd64
Date: Fri Feb 24 12:17:34 2017
InstallationDate: Installed on 2016-12-19 (66 days ago)
InstallationMedia: Ubuntu-Server 16.04.1 LTS "Xenial Xerus" - Beta amd64 (20161219)
ProcKernelCmdline: BOOT_IMAGE=/boot/vmlinuz-4.4.0-65-generic.efi.signed root=UUID=b23cf18f-e8d0-4a4f-9e8d-6aa47569e86b ro possible_cpus=2 nmi_watchdog=0 kaslr vsyscall=none transparent_hugepage=never
PstreeP: Error: [Errno 2] No such file or directory: '/usr/bin/pstree'
SourcePackage: apparmor
Syslog: Feb 24 11:04:10 jupiter dbus[1812]: [system] AppArmor D-Bus mediation is enabled
UpgradeStatus: No upgrade log present (probably fresh install)

[Simon Déziel (sdeziel)]

It doesn't seem to only affect rsyslog as I have for example a shell script contained by an Apparmor profile and inside the container it doesn't work as it wants to read /bin/dash:

audit: type=1400 audit(1487935787.212:153): apparmor="DENIED" operation="file_mprotect" namespace="root//lxd-smb_<var-lib-lxd>" profile="/usr/local/bin/backuppc-wrapper" name="/bin/dash" pid=29187 comm="backuppc-wrappe" requested_mask="r" denied_mask="r" fsuid=165570 ouid=165536

[Seth Arnold (seth-arnold)]

Thanks Simon,

https://github.com/torvalds/linux/commit/9f834ec18defc369d73ccf9e87a2790bfa05bf46 changed how ELF executables are loaded by the kernel and required many changes to profiles. I'm surprised that the denials you're seeing now weren't generated earlier, due to this change.

Thanks

[Simon Déziel (sdeziel)]

On 2017-02-24 04:04 PM, Seth Arnold wrote:
> I'm surprised that the denials you're seeing now
> weren't generated earlier, due to this change.

Well, I just got the word that Apparmor was now working in containers
after waiting for years so I happily jumped in.

I guess the question is: is there a way to let Apparmor magically let a
binary reads itself? Or do we need to update every single profile to
account for that change?

[Seth Arnold (seth-arnold)]

That's an excellent question. In general we can't solve all cases but perhaps we can find a middle-ground.

In the past, the 'r' flag on the executable determined if the process was dumpable. I expect that to still hold, but there may be other reasons why 'r' is required these days.

I don't know how widespread it would be for someone to put 'm' on a binary but not 'r' so that it couldn't be dumpable. That feels unlikely. Maybe we could automatically give 'mr' permissions to the files listed in the attachment specification?

Thanks

[Simon Déziel (sdeziel)]

Thanks Seth. A general solution covering most cases would be great as
tweaking existing profiles would involve many SRUs and inevitably, new
profiles not working inside containers would show up.

[Jamie Strandboge (jdstrand)]

John, what do you think about Seth's question in https://bugs.launchpad.net/apparmor/+bug/1667751/comments/5?