dev file system is mounted without nosuid or noexec

[Dave Chiluk]

[ SRU TEMPLATE ]
[ Impact ]

 * nosuid, and noexec bits are not set on /dev
 * This has the potential for nefarious actors to use this as an avenue for attack. see https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1450960 for more discussion around this.
 * It is not best security practice.

[ Test Plan ]

   1.Boot a Canonical Supplied EC2 instance
   2.Check the mount options for /dev.
   3.You will notice the lack of nosuid and noexec on /dev.

[ Where problems could occur ]

 * As of 2022/10/06, I need to test this, but don't know how to build -aws flavored ubuntu kernels. Instructions welcome. I'm holding off on adding SRU tags until I can actually get this tested.

 * If this is applied to non initramfs-less kernels it could potentially cause a regression for very old hardware that does nefarious things with memory. For a larger discussion about that see:
https://lore.kernel.org/lkml/YcMfDOyrg647RCmd@debian-BULLSEYE-live-builder-AMD64/T/

 * Low risk if a driver depends on /dev allowing suid or exec this might prevent boot. That being said, all kernels that have been booting with an initramfs have been getting nosuid, and noexec set so hopefully we can consider that risk fairly well tested.

[ Other Info ]

 * Patch is accepted into 5.17, and will drop out quickly
 * Any server booting with an initramfs already has nosuid, and noexec set, so hopefully

<<<<<<< ORIGINAL TEXT >>>>>>>>>>>>

This is similar to https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1450960 but new.

I discovered that my ec2 instances based off of Canonical supplied AMI ami-0a23d90349664c6ee *(us-east-2), have dev mounted mounted without the nosuid option.

https://us-east-2.console.aws.amazon.com/ec2/home?region=us-east-2#Images:visibility=public-images;imageId=ami-0a23d90349664c6ee

My usb installed 20.04.4 home machine does not have this problem, but it has been installed for quite some time. My 22.04 laptop machine also does not have this issue.

Reproduce.
Start an ec2 instance based off of ami-0a23d90349664c6ee.
$ mount | grep devtmpfs
nosuid is not found in the options list.

I've checked the initrd, and /etc/init.d/udev script and all places I know of where dev gets mounted set nosuid, so it's non-obvious what boot code-path is being taken that results in nosuid missing.

ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: udev 245.4-4ubuntu3.18
ProcVersionSignature: Ubuntu 5.15.0-1020.24~20.04.1-aws 5.15.53
Uname: Linux 5.15.0-1020-aws x86_64
ApportVersion: 2.20.11-0ubuntu27.24
Architecture: amd64
CasperMD5CheckResult: skip
CustomUdevRuleFiles: 60-cdrom_id.rules 70-snap.snapd.rules
Date: Thu Oct 6 17:39:42 2022
Ec2AMI: ami-0a23d90349664c6ee
Ec2AMIManifest: (unknown)
Ec2AvailabilityZone: us-east-2c
Ec2InstanceType: t2.medium
Ec2Kernel: unavailable
Ec2Ramdisk: unavailable
Lsusb: Error: command ['lsusb'] failed with exit code 1:
Lsusb-t:

Lsusb-v: Error: command ['lsusb', '-v'] failed with exit code 1:
MachineType: Xen HVM domU
ProcEnviron:
 TERM=xterm-256color
 PATH=(custom, no user)
 LANG=C.UTF-8
 SHELL=/bin/bash
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.15.0-1020-aws root=PARTUUID=5bb90437-9efc-421d-aa94-c512c3b666a3 ro console=tty1 console=ttyS0 nvme_core.io_timeout=4294967295 panic=-1
SourcePackage: systemd
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 08/24/2006
dmi.bios.release: 4.2
dmi.bios.vendor: Xen
dmi.bios.version: 4.2.amazon
dmi.chassis.type: 1
dmi.chassis.vendor: Xen
dmi.modalias: dmi:bvnXen:bvr4.2.amazon:bd08/24/2006:br4.2:svnXen:pnHVMdomU:pvr4.2.amazon:cvnXen:ct1:cvr:sku:
dmi.product.name: HVM domU
dmi.product.version: 4.2.amazon
dmi.sys.vendor: Xen

[Dan Watkins (oddbloke)]

I suspect this is something to do with initrd-less boot: it's usually the initramfs which mounts /dev: https://git.launchpad.net/ubuntu/+source/initramfs-tools/tree/init#n40

The comment above that line is:

# Note that this only becomes /dev on the real filesystem if udev's scripts
# are used; which they will be, but it's worth pointing out

[Ubuntu Kernel Bot (ubuntu-kernel-bot)]

This change was made by a bot.

[Dave Chiluk (chiluk)]

So far I've only tested focal AWS images, but this may likely exist elsewhere as well.

[Dave Chiluk (chiluk)]

I was hoping to work around this in /etc/init.d/udev, but it looks like that gets redirected to systemctl via
. lib/lsb/init-functions

[Launchpad Janitor (janitor)]

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

[Simon Déziel (sdeziel)]

I can confirm the issue on an *old* GCP instance:

$ mount | grep devtmp
devtmpfs on /dev type devtmpfs (rw,relatime,size=490260k,nr_inodes=122565,mode=755,inode64)

$ cat /etc/cloud/build.info
build_name: server
serial: 20200902

$ uname -a
Linux mx1 5.15.0-1018-gcp #24~20.04.1-Ubuntu SMP Mon Sep 12 06:14:01 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

[Dave Chiluk (chiluk)]

Looks like Kees already found this years ago.
https://lore.kernel.org/lkml/YcMfDOyrg647RCmd@debian-BULLSEYE-live-builder-AMD64/T/

Looks like it was accepted as commit 28f0c335dd4a1 in 5.17. So I think we should apply this patch and the corresponding set CONFIG_DEVTMPFS_SAFE=y at least for the aws kernel and preferably all the 5.15 kernels.

[Dave Chiluk (chiluk)]

Here is a workaround for this issue in case anyone finds this in the future.

Copy remount_dev.service to /etc/systemd/system
sudo chown root:root /etc/systemd/system/remount_dev.service
sudo systemctl daemon-reload
sudo systemctl enable remount_dev.service

Still I think the kernel patch should be applied, but at least there's a workaround for now.

[Julian Andres Klode (juliank)]

On my kinetic system, /dev has nosuid, but no noexec.

[Dave Chiluk (chiluk)]

@juliank, is this an aws system? If not there's a good chance that you are using an initramfs to mount the filesystems. That's definited in either /etc/init.d/udev or directly out of the init that lives in the initramfs.

[Dimitri John Ledkov (xnox)]

@juliank please test initrd-less boot; for example lxc launch --vm which uses linux-kvm flavour booted without initrd.

There are differences of the mount options as applied by initramfs-tools; systemd; and kernel itself.

[Dave Chiluk (chiluk)]

In case anyone is curious conversation is on-going on the kernel-team mailing list
https://lists.ubuntu.com/archives/kernel-team/2022-October/133764.html

[Lukas Märdian (slyon)]

Setting the systemd bug task to "Invalid", as this is being handled in the kernel.

[Dimitri John Ledkov (xnox)]

./src/nspawn/nspawn-mount.c missing NO_EXEC on /dev
./src/shared/mount-setup.c missing NO_EXEC on /dev

when booting containers

[Nick Rosbrook (enr0n)]

FWIW upstream systemd removed the MS_NOEXEC flag from /dev in https://github.com/systemd/systemd/commit/4eb105fa4aae30566d23382e8c9430eddf1a3dd4.

[Dave Chiluk (chiluk)]

Alright so that means we either need to push a change to remove noexec from the kernel init code, or we go ahead with noexec, and give people on option to remount with exec should they want sgx functionality. I do think the nosuid flag does still provide some benefit even if we decide not to include the noexec flag by default until 5.17+.

[Dimitri John Ledkov (xnox)]

initramfs-tools also mounts /dev with nosuid, without noexec

> mount -t devtmpfs -o nosuid,mode=0755 udev /dev

I believe all of these should be the same, thus kernel can mount /dev with nosuid, but should not mount it with noexec.

[Seth Arnold (seth-arnold)]

Just a heads-up that SGX has been deprecated by Intel:

https://edc.intel.com/content/www/us/en/design/ipla/software-development-platforms/client/platforms/alder-lake-desktop/12th-generation-intel-core-processors-datasheet-volume-1-of-2/004/deprecated-technologies/

===

The processor has deprecated the following technologies and they are no longer supported:

    Intel® Memory Protection Extensions (Intel® MPX)
    Branch Monitoring Counters
    Hardware Lock Elision (HLE), part of Intel® TSX-NI
    Intel® Software Guard Extensions (Intel® SGX)
    Intel® TSX-NI
    Power Aware Interrupt Routing (PAIR)

===

I think we shouldn't put too much weight on SGX support in making this decision.

Thanks

[Dave Chiluk (chiluk)]

So where are we on this folks?

[Dimitri John Ledkov (xnox)]

I'm not too sure if updates from sed1991s above are correct

[Guruprasad (lgp171188)]

These metadata edits on this bug and a few others look spammy to me. Taking the appropriate action now.