linux-kernel - Re: [kernel-hardening] [PATCH 00/11] S.A.R.A. a new stacked LSM

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]

Message-ID: <988555a2-bed9-234c-843c-0bb68dc60d3f@nmatt.com>
Date:   Thu, 13 Jul 2017 08:39:47 -0400
From:   Matt Brown <matt@...tt.com>
To:     Mimi Zohar <zohar@...ux.vnet.ibm.com>,
        Salvatore Mesoraca <s.mesoraca16@...il.com>,
        Mickaël Salaün <mic@...ikod.net>
Cc:     kernel list <linux-kernel@...r.kernel.org>,
        linux-security-module <linux-security-module@...r.kernel.org>,
        Kernel Hardening <kernel-hardening@...ts.openwall.com>,
        Brad Spengler <spender@...ecurity.net>,
        PaX Team <pageexec@...email.hu>,
        Casey Schaufler <casey@...aufler-ca.com>,
        Kees Cook <keescook@...omium.org>,
        James Morris <james.l.morris@...cle.com>,
        "Serge E. Hallyn" <serge@...lyn.com>
Subject: Re: [kernel-hardening] [PATCH 00/11] S.A.R.A. a new stacked LSM

On 7/11/17 3:31 PM, Mimi Zohar wrote:
> On Tue, 2017-07-11 at 13:49 -0400, Matt Brown wrote:
> 
>> I have merged my TPE LSM with Mimi Zohar's shebang LSM and will be
>> releasing a version 3 soon. I have also added securityfs support to
>> shebang that will allow users to update the interpreter list at run
>> time. This allows for user's to configure TPE/Shebang without any
>> xattrs. For a preview of my version 3 you can check out my dev tree
>> here:
>> https://github.com/nmatt0/linux-security/tree/tpe/security/tpe
>>
>> Note: that git tree is WIP and may not have all of the attribution and
>> documentation needed.
> 
> You'll want to detect when an interpreter is deleted or renamed.  I
> would define security_inode_rename, security_path_rename,
> security_inode_unlink and security_path_unlink hooks.
> 
> "rename" could be an indication that the existing interpreter is being
> updated. "unlink" indicates that the interpreter has been deleted.  At
> either of these points, you'll want to start checking for the creation
> of a new file with the expected pathname.
> 
> Mimi
> 

Would it be better just to check for paths rather than inodes?

Matt