linux-kernel - Re: [PATCH v3 resend 1/2] mm: Add an F_SEAL_FUTURE

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:   Fri, 9 Nov 2018 17:49:13 -0800
From:   Joel Fernandes <joel@...lfernandes.org>
To:     Michael Tirado <mtirado418@...il.com>
Cc:     Andy Lutomirski <luto@...capital.net>,
        Jann Horn <jannh@...gle.com>,
        LKML <linux-kernel@...r.kernel.org>, jreck@...gle.com,
        john.stultz@...aro.org, tkjos@...gle.com,
        gregkh@...uxfoundation.org, hch@...radead.org,
        viro@...iv.linux.org.uk, Andrew Morton <akpm@...ux-foundation.org>,
        dancol@...gle.com, bfields@...ldses.org, jlayton@...nel.org,
        khalid.aziz@...cle.com, Lei.Yang@...driver.com,
        linux-fsdevel@...r.kernel.org, linux-kselftest@...r.kernel.org,
        linux-mm@...ck.org, marcandre.lureau@...hat.com,
        mike.kravetz@...cle.com, minchan@...nel.org, shuah@...nel.org,
        valdis.kletnieks@...edu, hughd@...gle.com,
        linux-api@...r.kernel.org
Subject: Re: [PATCH v3 resend 1/2] mm: Add an F_SEAL_FUTURE_WRITE seal to
 memfd

On Fri, Nov 09, 2018 at 08:02:14PM +0000, Michael Tirado wrote:
[...]
> > > That aside: I wonder whether a better API would be something that
> > > allows you to create a new readonly file descriptor, instead of
> > > fiddling with the writability of an existing fd.
> >
> > Every now and then I try to write a patch to prevent using proc to reopen
> > a file with greater permission than the original open.
> >
> > I like your idea to have a clean way to reopen a a memfd with reduced
> > permissions. But I would make it a syscall instead and maybe make it only
> > work for memfd at first.  And the proc issue would need to be fixed, too.
> 
> IMO the best solution would handle the issue at memfd creation time by
> removing the race condition.

I agree, this is another idea I'm exploring. We could add a new .open
callback to shmem_file_operations and check for seals there.

thanks,

 - Joel