linux-kernel - Re: [RFC PATCH 1/2] lsm: introduce new hook security_vm

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Fri, 15 Mar 2024 11:41:06 -0700
From: Casey Schaufler <casey@...aufler-ca.com>
To: Christian Göttsche <cgzones@...glemail.com>
Cc: linux-security-module@...r.kernel.org,
 Eric Biederman <ebiederm@...ssion.com>, Kees Cook <keescook@...omium.org>,
 Alexander Viro <viro@...iv.linux.org.uk>,
 Christian Brauner <brauner@...nel.org>, Jan Kara <jack@...e.cz>,
 Paul Moore <paul@...l-moore.com>, James Morris <jmorris@...ei.org>,
 "Serge E. Hallyn" <serge@...lyn.com>,
 Khadija Kamran <kamrankhadijadj@...il.com>,
 Andrii Nakryiko <andrii@...nel.org>, Alexei Starovoitov <ast@...nel.org>,
 Ondrej Mosnacek <omosnace@...hat.com>,
 Roberto Sassu <roberto.sassu@...wei.com>, Alfred Piccioni
 <alpic@...gle.com>, John Johansen <john.johansen@...onical.com>,
 linux-mm@...ck.org, linux-fsdevel@...r.kernel.org,
 linux-kernel@...r.kernel.org, Casey Schaufler <casey@...aufler-ca.com>
Subject: Re: [RFC PATCH 1/2] lsm: introduce new hook security_vm_execstack

On 3/15/2024 11:30 AM, Christian Göttsche wrote:
> On Fri, 15 Mar 2024 at 19:22, Casey Schaufler <casey@...aufler-ca.com> wrote:
>> On 3/15/2024 11:08 AM, Christian Göttsche wrote:
>>> Add a new hook guarding instantiations of programs with executable
>>> stack.  They are being warned about since commit 47a2ebb7f505 ("execve:
>>> warn if process starts with executable stack").  Lets give LSMs the
>>> ability to control their presence on a per application basis.
>> This seems like a hideously expensive way to implement a flag
>> disallowing execution of programs with executable stacks. What's
>> wrong with adding a flag VM_NO_EXECUTABLE_STACK?
> That would be global and not on a per application basis.
> One might want to exempt known legacy programs.

OK, I can see that.

> Also is performance a concern for this today's rare occurrence?

Performance is *always* a concern. You're adding a new hook list
for a "rare" case. You're extended SELinux policy to include the
case. This really should be a hardening feature, not an SELinux policy
feature. The hook makes no sense for an LSM like Smack, which only
implements subject+object controls. You could implement a stand alone
LSM that implements only this hook, but again, it's not really access
control, it's hardening.