3.15.0-1.x breaks lxc-attach for unprivileged containers

[James Hunt]

An unprivileged call to lxc-attach fails with kernel 3.15.0.1.2, but works fine using 3.13.0-24-generic.

Under 3.15.0.1.2, attempting to connect to a running unprivileged container:

$ lxc-attach --clear-env -n trusty -- /bin/true
lxc-attach: Permission denied - Could not open /proc/3805/personality
lxc-attach: failed to get context of the init process, pid = 3805

Note that lxc-start and lxc-console are not affected.

To recreate:

1) Create an unpriv container:

$ lxc-create -n utopic -t download -- -d ubuntu -r utopic -a amd64

2) Boot with 3.13.0-24-generic

3) Start the container:
$ lxc-start -n utopic

4) Run a command in the container:

$ lxc-attach -n utopic --clear-env -n trusty -- /bin/true

5) Reboot into 3.15.0.1.2 and re-run the lxc-start and lxc-attach.

6) Observe the EPERM error.

ProblemType: Bug
DistroRelease: Ubuntu 14.10
Package: linux-generic 3.15.0.1.2
ProcVersionSignature: Ubuntu 3.13.0-24.47-generic 3.13.9
Uname: Linux 3.13.0-24-generic x86_64
ApportVersion: 2.14.2-0ubuntu4
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC1: james 2827 F.... pulseaudio
 /dev/snd/pcmC1D0p: james 2827 F...m pulseaudio
 /dev/snd/controlC0: james 2827 F.... pulseaudio
CurrentDesktop: Unity
Date: Thu May 22 07:21:55 2014
HibernationDevice: RESUME=UUID=db600bbe-faca-41f4-9338-c3e8e227599a
InstallationDate: Installed on 2014-04-11 (40 days ago)
InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Daily amd64 (20140409)
MachineType: LENOVO 20AQCTO1WW
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-3.13.0-24-generic root=/dev/mapper/ubuntu--vg-root ro quiet splash vt.handoff=7
RelatedPackageVersions:
 linux-restricted-modules-3.13.0-24-generic N/A
 linux-backports-modules-3.13.0-24-generic N/A
 linux-firmware 1.129
SourcePackage: linux
UpgradeStatus: Upgraded to utopic on 2014-05-08 (13 days ago)
dmi.bios.date: 02/10/2014
dmi.bios.vendor: LENOVO
dmi.bios.version: GJET71WW (2.21 )
dmi.board.asset.tag: Not Available
dmi.board.name: 20AQCTO1WW
dmi.board.vendor: LENOVO
dmi.board.version: 0B98405 STD
dmi.chassis.asset.tag: No Asset Information
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: Not Available
dmi.modalias: dmi:bvnLENOVO:bvrGJET71WW(2.21):bd02/10/2014:svnLENOVO:pn20AQCTO1WW:pvrThinkPadT440s:rvnLENOVO:rn20AQCTO1WW:rvr0B98405STD:cvnLENOVO:ct10:cvrNotAvailable:
dmi.product.name: 20AQCTO1WW
dmi.product.version: ThinkPad T440s
dmi.sys.vendor: LENOVO

[Brad Figg (brad-figg)]

This change was made by a bot.

[Seth Forshee (sforshee)]

This commit is certainly to blame.

commit 35a35046e4f9d8849e727b0e0f6edac0ece4ca6e
Author: Djalal Harouni <email address hidden>
Date: Mon Apr 7 15:38:36 2014 -0700

    procfs: make /proc/*/{stack,syscall,personality} 0400

    These procfs files contain sensitive information and currently their
    mode is 0444. Change this to 0400, so the VFS will be able to block
    unprivileged processes from getting file descriptors on arbitrary
    privileged /proc/*/{stack,syscall,personality} files.

    This reduces the scope of ASLR leaking and bypasses by protecting already
    running processes.

My questions are:

1) Does lxc really need this data?

2) Is there some way to work around this restriction (e.g. read the data as the user of the process)?

3) Can we argue that the security concerns here are overblown and this file really should be world-readable?

[Seth Forshee (sforshee)]

Fwiw, I suspect the reason for clamping down permissions on the personality file is because it has an ADDR_NO_RANDOMIZE flag. Perhaps the rationale is that having this file world-readable means that an attacker could scan for processes that are vulnerable to an attack which would otherwise be mitigated by ASLR. Just a guess.

[Serge Hallyn (serge-hallyn)]

Unfortunaty the check is not a simple uid comparison, because when I
use lxc-usernsexec to cat the file using the uid of root in the container,
I still get EPERM.

[Serge Hallyn (serge-hallyn)]

Expanding on comment #4: Otherwise we could work around it more easily in lxc. As it is, if we can't cleanly/safely allow it in the kernel, we may need to ask a new lxc command interface query to get the container's personality.

[Stéphane Graber (stgraber)]

Serge, could we just have lxc-attach query lxc.arch using get_config_item over the command interface and do the personality mapping based on the running container config rather than the running processes?

That should spare us the addition of a new command interface call and the usual breakage we get when we do that.

[Serge Hallyn (serge-hallyn)]

Oh, yeah, I forgot we had that. That sounds good.

Far preferable to having to tweak/relax the kernel constraints on reading
that file.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Serge Hallyn (serge-hallyn)]

Fix committed in upstream git with commit 9b8e3c96d87b7208c11204d46f4dd946e0060c95.

[Stéphane Graber (stgraber)]

Marking fix released as this was cherry-picked and uploaded to utopic last week.