[ 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
I suspect this is something to do with initrd-less boot: it's usually the initramfs which mounts /dev: https:/
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