Richard Weinberger <richard@xxxxxx> writes: > Am 10.07.2015 um 21:30 schrieb Greg Kroah-Hartman: >> On Fri, Jul 10, 2015 at 08:24:41PM +0200, Richard Weinberger wrote: >>> Am 10.07.2015 um 18:17 schrieb Eric W. Biederman: >>>> >>>> Today proc and sysfs do not contain any executable files. Several >>>> applications today mount proc or sysfs without noexec and nosuid and >>>> then depend on there being no exectuables files on proc or sysfs. >>>> Having any executable files show on proc or sysfs would cause >>>> a user space visible regression, and most likely security problems. >>>> >>>> Therefore commit to never allowing executables on proc and sysfs by >>>> adding a new flag to mark them as filesystems without executables and >>>> enforce that flag. >>>> >>>> Test the flag where MNT_NOEXEC is tested today, so that the only user >>>> visible effect will be that exectuables will be treated as if the >>>> execute bit is cleared. >>>> >>>> The filesystems proc and sysfs do not currently incoporate any >>>> executable files so this does not result in any user visible effects. >>>> >>>> This makes it unnecessary to vet changes to proc and sysfs tightly for >>>> adding exectuable files or changes to chattr that would modify >>>> existing files, as no matter what the individual file say they will >>>> not be treated as exectuable files by the vfs. >>>> >>>> Not having to vet changes to closely is important as without this we >>>> are only one proc_create call (or another goof up in the >>>> implementation of notify_change) from having problematic executables >>>> on proc. Those mistakes are all too easy to make and would create >>>> a situation where there are security issues or the assumptions of >>>> some program having to be broken (and cause userspace regressions). >>> >>> Would it make sense to add SB_I_NOEXEC to more pseudo filesystems? >>> Say pstore or devpts? >> >> And configfs and cgroupfs? > > Yep. Any filesystem where exectuables do not make sense. :-) With a threat model of a developer overlooking something and allows executables by accident? I certainly think it makes sense. Mostly because we are solving things at the vfs level. Which gives us one well tested solution instead of several filesystem specific solutions. That isn't quite the same problem that caused me to write this code, so I am not going to volunteer to write the patches for the additional filesystems. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
