linux-kernel - Re: [PATCH] add new prctl for a per process wide close on exec V.3

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Sun, 27 Oct 2013 22:15:29 +0000
From:	Al Viro <viro@...IV.linux.org.uk>
To:	Stefani Seibold <stefani@...bold.net>
Cc:	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	akpm@...ux-foundation.org, mingo@...hat.com, peterz@...radead.org
Subject: Re: [PATCH] add new prctl for a per process wide close on exec V.3

On Sun, Oct 27, 2013 at 12:48:06PM +0100, Stefani Seibold wrote:
> This small patch adds a runtime prctl config option for a per process
> "close on exec" without breaking existing code.
> 
> With this feature a developer can decide if the application will pass all non
> "close on exec" file descriptors to a new process or not.
> 
> The mode of the process wide "close on exec" can be set with PR_SET_CLOEXEC and
> PR_GET_CLOEXEC returns the current mode. Mode is one of the following:
> 
> - PR_CLOEXEC_DEFAULT closes only the fd's marked as "close on exec" in
>    the child process, this is the linux default behaviour.
> 
> - PR_CLOEXEC_ONCE closes all fd's expect 0, 1 and 2 which are regular
>    handled as in PR_CLOEXEC_DEFAULT and reset the mode of the child to
>    PR_CLOEXEC_DEFAULT.
> 
> - PR_CLOEXEC_INHERIT is like PR_CLOEXEC_ONCE, but the mode will stay in the
>    child
> 
> STDIO file descriptors will be passed to the child process depending on the
> ..._CLOEXEC flag. So the new modes should be compatible to regular code.
> 
> This patch will increase security since no developers can review all libraries
> which there are using. Also in a team of developers it is not always possible
> to have a full survey over the code which is produced. Or the output of a code
> generators and so one. This patch allows a kind of preventive measures.
> 
> It can also prevent resource occupation. Imagine a long running process (a
> daemon) is execute from the application after open some file desciptors. For
> example libpcsclite.so will not open the socket with SOCK_CLOEXEC. Or a device
> driver which alows only a single open. In both cases the resource cannot
> reopened after a close. Sigh!
> 
> The usage is very simple:
> 
> if (prctl(PR_SET_CLOEXEC, PR_CLOEXEC_INHERIT, 0, 0, 0)) {
> 	perror("PR_SET_CLOEXEC");
> 	exit(1);
> }
> 
> If the prctl PR_SET_CLOEXEC was missused in a library, the caller will
> fail!

NAK.  All your arguments about Big Bad Wolf^WLibrary leaking opened files
through execve() are completely missing that possibility that "proactive"
program using this kludge might be linked against a Big Bad Library that
spawns a process and expects close-on-exec to work as designed.

And if execve() is in your program and under your control and you worry about
library-opened descriptors leaking through execve(), something like
unshare(CLONE_FILES | CLONE_CLOSEALL) before execve() would be a much

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/