linux-kernel - Re: [PATCH RFC v2 2/3] security: add the ModAutoRestrict Linux Security Module

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:   Mon, 10 Apr 2017 21:55:54 +0200
From:   Djalal Harouni <tixxdz@...il.com>
To:     Casey Schaufler <casey@...aufler-ca.com>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Andy Lutomirski <luto@...nel.org>,
        Kees Cook <keescook@...omium.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        kernel-hardening@...ts.openwall.com,
        LSM List <linux-security-module@...r.kernel.org>,
        Linux API <linux-api@...r.kernel.org>,
        Dongsu Park <dpark@...teo.net>,
        James Morris <james.l.morris@...cle.com>,
        "Serge E. Hallyn" <serge@...lyn.com>,
        Paul Moore <paul@...l-moore.com>,
        Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: [PATCH RFC v2 2/3] security: add the ModAutoRestrict Linux
 Security Module

On Mon, Apr 10, 2017 at 9:04 PM, Casey Schaufler <casey@...aufler-ca.com> wrote:
> On 4/10/2017 11:27 AM, Djalal Harouni wrote:
>> On Mon, Apr 10, 2017 at 5:42 PM, Casey Schaufler <casey@...aufler-ca.com> wrote:
>>> On 4/9/2017 3:42 AM, Djalal Harouni wrote:
[...]

>>>> --- a/security/security.c
>>>> +++ b/security/security.c
>>>> @@ -70,6 +70,7 @@ int __init security_init(void)
>>>>       capability_add_hooks();
>>>>       yama_add_hooks();
>>>>       loadpin_add_hooks();
>>>> +     modautorestrict_init();
>>> This should be modautorestrict_add_hooks() if this were
>>> a "minor" module, but as it's using a blob it is a "major"
>>> module. Either way, this is not right.
>> Do you mean that if I'm using a blob, it should go with the rest LSMs
>> in do_security_initcalls() ?
>
> Right. Today you have coincidental non-interference because
> no one else is using the task blob. As you're aware, TOMOYO
> is going to start using it, and I believe the AppArmor has
> plans for it as well. There are parts of the Smack cred blob
> that should probably go in the task blob as they aren't used
> in access decisions. I haven't looked closely enough, but that's
> possible for SELinux, too. So even though it's a new blob, the
> major/minor rules apply.
>

Ok, point taken.

Thanks!

-- 
tixxdz