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  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
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