linux-kernel - Re: [RFC v2 19/19] ima: Setup securityfs for IMA namespace

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: <e4134d4f-5134-ade8-6428-3510ac940757@linux.ibm.com>
Date:   Mon, 6 Dec 2021 09:03:37 -0500
From:   Stefan Berger <stefanb@...ux.ibm.com>
To:     jejb@...ux.ibm.com, linux-integrity@...r.kernel.org
Cc:     zohar@...ux.ibm.com, serge@...lyn.com,
        christian.brauner@...ntu.com, containers@...ts.linux.dev,
        dmitry.kasatkin@...il.com, ebiederm@...ssion.com,
        krzysztof.struczynski@...wei.com, roberto.sassu@...wei.com,
        mpeters@...hat.com, lhinds@...hat.com, lsturman@...hat.com,
        puiterwi@...hat.com, jamjoom@...ibm.com,
        linux-kernel@...r.kernel.org, paul@...l-moore.com, rgb@...hat.com,
        linux-security-module@...r.kernel.org, jmorris@...ei.org
Subject: Re: [RFC v2 19/19] ima: Setup securityfs for IMA namespace


On 12/5/21 23:27, James Bottomley wrote:
> On Fri, 2021-12-03 at 14:11 -0500, Stefan Berger wrote:
>> On 12/3/21 13:50, James Bottomley wrote:
>>> On Fri, 2021-12-03 at 13:06 -0500, Stefan Berger wrote:
> [...]
>>>> I suppose any late filesystem init callchain would have to be
>>>> connected to the user_namespace somehow?
>>>   
>>> I don't think so; I think just moving some securityfs entries into
>>> the user_namespace and managing the notifier chain from within
>>> securityfs will do for now.  [although I'd have to spec this out in
>>> code before I knew for sure].
>> It doesn't have to be right in the user_namespace. The IMA namespace
>> is  connected to the user namespace and holds the dentries now...
>>
>> Please spec it out...
> OK, this is what I have.  fill_super turned out to be a locking
> nightmare, so I triggered it from free context instead (which doesn't
> have the once per keyed superblock property, so I added a flag in the
> user namespace).  I've got it to the point where the event is triggered
> on mount and unmount, so all the entries for the namespace are added
> when the filesystem is mounted and remove when it's unmounted.  This
> style of addition no longer needs the simple_pin_fs, because the
> add/remove callbacks substitute (plus, if we pinned, the free_super
> wouldn't trigger on unmount).  The default behaviour still does pinning
> and unpinning, but that can be keyed off the current user_namespace.
>
> This is all on top of your current series ... some of the functions
> should probably be renamed, but I kept them to show how the code was
> migrating in this sketch.
>
> James
>
> ---
>
>  From 59c45daa8698c66c3bcebfb194123977d548a9a6 Mon Sep 17 00:00:00 2001
> From: James Bottomley <James.Bottomley@...senPartnership.com>
> Date: Sat, 4 Dec 2021 16:38:37 +0000
> Subject: [PATCH] rework securityfs
>
> ---
>
> -
> -static void _securityfs_remove(struct dentry *dentry,
> -			       struct vfsmount **mount, int *mount_count)
> +void securityfs_remove(struct dentry *dentry)
>   {
>   	struct inode *dir;
> +	struct user_namespace *ns = current_user_ns();

I had problems with this in this place. So I had to use use

struct user_namespace *user_ns = dentry->d_sb->s_user_ns;

I'll try to split up your patch and post a v3 with then. Or is it too early?

   Stefan