linux-kernel - RE: [PATCH] capabilities: Introduce CAP

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: <ac167440b8b64f02a034dd94687b8aee@EXMBDFT11.ad.twosigma.com>
Date:   Wed, 27 May 2020 16:37:31 +0000
From:   Nicolas Viennot <Nicolas.Viennot@...sigma.com>
To:     Casey Schaufler <casey@...aufler-ca.com>,
        Adrian Reber <areber@...hat.com>
CC:     Christian Brauner <christian.brauner@...ntu.com>,
        Eric Biederman <ebiederm@...ssion.com>,
        Pavel Emelyanov <ovzxemul@...il.com>,
        Oleg Nesterov <oleg@...hat.com>,
        Dmitry Safonov <0x7f454c46@...il.com>,
        Andrei Vagin <avagin@...il.com>,
        Michał Cłapiński <mclapinski@...gle.com>,
        Kamil Yurtsever <kyurtsever@...gle.com>,
        "Dirk Petersen" <dipeit@...il.com>,
        Christine Flood <chf@...hat.com>,
        Mike Rapoport <rppt@...ux.ibm.com>,
        Radostin Stoyanov <rstoyanov1@...il.com>,
        "Cyrill Gorcunov" <gorcunov@...nvz.org>,
        Serge Hallyn <serge@...lyn.com>,
        "Stephen Smalley" <stephen.smalley.work@...il.com>,
        Sargun Dhillon <sargun@...gun.me>,
        Arnd Bergmann <arnd@...db.de>,
        Aaron Goidel <acgoide@...ho.nsa.gov>,
        "linux-security-module@...r.kernel.org" 
        <linux-security-module@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "selinux@...r.kernel.org" <selinux@...r.kernel.org>,
        Eric Paris <eparis@...isplace.org>,
        Jann Horn <jannh@...gle.com>
Subject: RE: [PATCH] capabilities: Introduce CAP_RESTORE

> > If I understand part of CRIU correctly, then we only need read-access 
> > for the current user. I am sure Andrei, Pavel or Cyrill will correct 
> > me if I am wrong concerning map_files.
> If I do "ls -l /proc/self/map_files" I get the link name and link content.
> While I can't open /proc/self/map_files/7fbde0c3200-7fbde0c3300 I can read that it points to /usr/lib64/ld-2.30.so, which is something I can open and read. Sure, it's an extra step, but it's no big deal. It does raise the question of what value comes from disallowing open via the symlink.

Reading the symlink doesn't work in two cases:
1) The file has been deleted
2) The file is a memfd file