Messages in this thread | | | Date | Tue, 20 Nov 2012 23:53:53 +0000 | From | Alan Cox <> | Subject | Re: [PATCH v2] devtmpfs: mount with noexec and nosuid |
| |
> > 1. Why not just have your userspace mount -o remount the file system this > > way already in early boot. (and if you trojanned boot that early then any > > supposed security gain is already lost) > > That's certainly possible, but I am hoping to avoid adding any extra > boot time. The kernel is responsible for this mount, so its flags > should be configurable, resulting in no time penalty anywhere.
You just broke my bullshitometer
It's a single syscall from your init binary, its microseconds.
> > 2. If you want to do this right then you need to work out what you are > > trying to prevent. Your devtmpfs can force file permissions on the > > underlying device nodes by having its own operation handling for chmod. > > > > At that point you can force permissions on anything that you want to > > avoid floating around that filesystem with other rights, while not > > touching it on device or directory nodes where the meaning is different. > > > > In its current form however it appears to be a kernel implementation of > > "mount is too hard". > > This change also stops mmap() with PROT_EXEC which a chmod handler > wouldn't be able to do.
You don't want to stop mmap with PROT_EXEC on /dev/mem as that breaks a load of stuff, you want to stop people adding stuff to that file system and executing it.
Think about it more carefully - if I've got access to /dev/mem you already lost.
The patch is as is nonsense. It's doable in all kernels (including existing legacy ones) as a single syscall in your init code. That's portable back compatible and works all over the place. Your patch introduces a pointless config option to make things less compatible than before. It's bogus.
Alan
| |