linux-kernel - Re: [RFC 20/20] ima: Setup securityfs

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: <c6d7b9363991b80b2f55bbdb7e44c18ea45489da.camel@linux.ibm.com>
Date:   Wed, 01 Dec 2021 16:11:18 -0500
From:   James Bottomley <jejb@...ux.ibm.com>
To:     Stefan Berger <stefanb@...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 20/20] ima: Setup securityfs_ns for IMA namespace

On Wed, 2021-12-01 at 15:25 -0500, Stefan Berger wrote:
> On 12/1/21 14:21, James Bottomley wrote:
> > On Wed, 2021-12-01 at 13:11 -0500, Stefan Berger wrote:
> > > On 12/1/21 12:56, James Bottomley wrote:
> > [...]
> > > I tried this with runc and a user namespace active mapping uid
> > > 1000 on the host to uid 0 in the container. There I run into the
> > > problem that  all of the files and directories without the above
> > > work-around are mapped to 'nobody', just like all the files in
> > > sysfs in this case are also mapped to nobody. This code resolved
> > > the issue.
> > So I applied your patches with the permission shift commented out
> > and instrumented inode_alloc() to see where it might be failing and
> > I actually find it all works as expected for me:
> > 
> > ejb@...tdeb:~> unshare -r --user --mount --ima
> > root@...tdeb:~# mount -t securityfs_ns none /sys/kernel/security
> > root@...tdeb:~# ls -l /sys/kernel/security/ima/
> > total 0
> > -r--r----- 1 root root 0 Dec  1 19:11 ascii_runtime_measurements
> > -r--r----- 1 root root 0 Dec  1 19:11 binary_runtime_measurements
> > -rw------- 1 root root 0 Dec  1 19:11 policy
> > -r--r----- 1 root root 0 Dec  1 19:11 runtime_measurements_count
> > -r--r----- 1 root root 0 Dec  1 19:11 violations
> > 
> > I think your problem is something to do with how runc is installing
> > the uid/gid mappings.  If it's installing them after the
> > security_ns inodes are created then they get the -1 value (because
> > no mappings exist in s_user_ns).  I can even demonstrate this by
> > forcing unshare to enter the IMA namespace before writing the
> > mapping values and I'll see "nobody nogroup" above like you do.
> 
> I am surprised you get this mapping even after commenting the
> permission adjustments... it doesn't work for me when I comment them
> out:
> 
> [stefanb@...-ns-dev rootfs]$ unshare -r --user --mount
> [root@...-ns-dev rootfs]# mount -t securityfs_ns none
> /sys/kernel/security/
> [root@...-ns-dev rootfs]# cd /sys/kernel/security/ima/
> [root@...-ns-dev ima]# ls -l
> total 0
> -r--r-----. 1 nobody nobody 0 Dec  1 15:20 ascii_runtime_measurements
> -r--r-----. 1 nobody nobody 0 Dec  1 15:20
> binary_runtime_measurements
> -rw-------. 1 nobody nobody 0 Dec  1 15:20 policy
> -r--r-----. 1 nobody nobody 0 Dec  1 15:20 runtime_measurements_count
> -r--r-----. 1 nobody nobody 0 Dec  1 15:20 violations
> [root@...-ns-dev ima]# cat /proc/self/uid_map
>           0       1000          1
> [root@...-ns-dev ima]# cat /proc/self/gid_map
>           0       1000          1
> 
> The initialization of securityfs and setup of files and directories 
> happens at the same time as the IMA namespace is created. At this
> time there are no user mappings available, so that's why I need to
> make the adjustments 'late'.

There is one other possible difference:  To get the correct s_user_ns
on the securityfs_ns mount, the mount namespace itself has to be owned
by the user namespace ... is runc doing that correctly?  I always
forget this detail because unshare does it correctly automatically but
it means you must unshare the user namespace first and then unshare the
mount namespace (or do it in the same sys call because the kernel will
get the correct order).

James