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

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]

Date:	Thu, 24 Oct 2013 13:44:40 +0200
From:	Stefani Seibold <stefani@...bold.net>
To:	Al Viro <viro@...IV.linux.org.uk>
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

Am Dienstag, den 22.10.2013, 20:48 +0100 schrieb Al Viro:
> On Tue, Oct 22, 2013 at 09:27:18PM +0200, Stefani Seibold wrote:
> 
> > 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!
> > 
> > What do you think?
> 
> That it's a bad idea.  Not to mention anything else, the same unreviewed
> libraries can get buggered if the program sets that "global close-on-exec"
> and it's not at all obvious whether the breakage from that change will be less
> or more dangerous than leaking opened files to children.
> 
> Al, fully expecting the Linux S-M crowd to jump on that one and come up with
> yet another one-shot LSM... ;-/

You are right, but only in a perfect world ;-)

It is not always possible to review a library, f.e. on my current gentoo
system currently 20853 libraries installed. And what is with binary only
libraries or closed source code?

And that a library is using the new PR_CLOEXEC is IMHO very constructed.
But if this will happen (what i not believe), this should be very easy
to be locate and fixed.

I think you compare pears with apples, a simple prctl is not a LSM. A
lot of developer asked for this kind of global CLOEXEC functionality.
Try google... Tt adds only about 200 bytes to the current Linux code. 

Linux must cope with the UNIX legacy, but 99,9999 percent of programs
does not depend on the inheritance of file descriptors other than STDIO.
The UNIX default behaviour passing all fd's to the child is still
stupid. I think this is a nice solution for a long standing legacy
issue.

A lot of legacy UNIX issues was addressed and fixed by the linux kernel
with new system-calls or special behaviour. Why not this?

Greetings,
Stefani

--
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/