lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Sun, 12 May 2019 17:21:56 +0000 From: bugzilla-daemon@...zilla.kernel.org To: linux-ext4@...r.kernel.org Subject: [Bug 203585] New: Feature Request for filesystems that support noexec/exec mount options https://bugzilla.kernel.org/show_bug.cgi?id=203585 Bug ID: 203585 Summary: Feature Request for filesystems that support noexec/exec mount options Product: File System Version: 2.5 Kernel Version: all Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: enhancement Priority: P1 Component: ext4 Assignee: fs_ext4@...nel-bugs.osdl.org Reporter: Speeddymon@...il.com Regression: No Greetings, I want to ask for a new mount flag to be considered which enhances the noexec/exec flag for filesystems that support those flags. What I would like to do is to designate in /etc/fstab that a filesystem with either flag can be bypassed by certain users. For example, there is a web app that insists on writing a file to the root of /tmp, (a shared object library) in order to then load that file into memory to perform some operation. Why it is done this way, I don't know, but we have /tmp set to noexec for security reasons. The app is required to be able to execute the file in order to load it into memory it seems, because the app fails when we have noexec flag set on the /tmp filesystem, and it works fine without that flag. So, I was hoping that in the future, we might be able to work around this dilemma by having a "exec_users=/noexec_users=" type mount option. Where, if a filesystem has "noexec", you could do: "noexec,exec_user=john", and conversely if a filesystem has "exec" and you want to lock down a certain user/set of users, you could do "exec,noexec_user=paul" If this is considered useful enough, and is able to be implemented without much fuss -- BTW I'm HOPING that since the kernel does permissions checks for file/directory access, it can also do those checks for noexec/exec access -- then could you please also extend the mount options to have group_noexec/group_exec flags as well? -- You are receiving this mail because: You are watching the assignee of the bug.
Powered by blists - more mailing lists