linux-kernel - Re: [PATCH v2 2/5] clone: add CLONE

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] [day] [month] [year] [list]

Message-ID: <20190419133918.7uedlqgc6cvt7fjt@yavin>
Date:   Fri, 19 Apr 2019 23:39:18 +1000
From:   Aleksa Sarai <cyphar@...har.com>
To:     Christian Brauner <christian@...uner.io>
Cc:     Oleg Nesterov <oleg@...hat.com>, torvalds@...ux-foundation.org,
        viro@...iv.linux.org.uk, jannh@...gle.com, dhowells@...hat.com,
        linux-api@...r.kernel.org, linux-kernel@...r.kernel.org,
        serge@...lyn.com, luto@...nel.org, arnd@...db.de,
        ebiederm@...ssion.com, keescook@...omium.org, tglx@...utronix.de,
        mtk.manpages@...il.com, akpm@...ux-foundation.org,
        joel@...lfernandes.org, dancol@...gle.com
Subject: Re: [PATCH v2 2/5] clone: add CLONE_PIDFD

On 2019-04-18, Christian Brauner <christian@...uner.io> wrote:
> > Why O_CLOEXEC? I am just curious, I do not really care.
> 
> I think that having the file descriptor O_CLOEXEC by default is a good
> security measure in general. Most of the time you do not want to pass a
> file descriptor through exec() (apart from 0,1,2) and it is usually more
> of an issue when you accidently do it then when you accidently don't. So
> if users really care about passing a pidfd they should do so by removing
> the O_CLOEXEC flag explicitly.
> (New file descriptors should probably all default to that but that's just
> my opinion.)
> Another thing is that for a pidfds it makes even more sense to have them
> cloexec by default. You don't want to *unintentionally* leak an fd that
> can be used to operate on a process.

There is another factor as well -- if you want to set O_CLOEXEC in a
multi-threaded process you can't be sure that another thread didn't fork
in between you getting the fd_install'd and the userspace process
setting O_CLOEXEC (leading to the fd leaking outside the current
process). This is why a lot of syscalls have a way to get an O_CLOEXEC
fd from the outset.

So I'm +1 on doing O_CLOEXEC by default -- you can always disable it
safely but enabling it safely isn't so simple (and I don't think it
makes much sense to add the mechanism to pass PIDFD_CLOEXEC as well,
given how tight the flags are getting).

-- 
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
<https://www.cyphar.com/>

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)