> > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
