linux-kernel - Re: [PATCHv4 RESEND 0/3] syscalls,x86: Add execveat() system call

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:	Mon, 27 Oct 2014 18:01:10 +0000
From:	David Drysdale <drysdale@...gle.com>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
Cc:	Andy Lutomirski <luto@...capital.net>,
	Alexander Viro <viro@...iv.linux.org.uk>,
	Meredydd Luff <meredydd@...atehouse.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Kees Cook <keescook@...omium.org>,
	Arnd Bergmann <arnd@...db.de>, X86 ML <x86@...nel.org>,
	linux-arch <linux-arch@...r.kernel.org>,
	Linux API <linux-api@...r.kernel.org>
Subject: Re: [PATCHv4 RESEND 0/3] syscalls,x86: Add execveat() system call

On Wed, Oct 22, 2014 at 6:40 PM, Eric W. Biederman
<ebiederm@...ssion.com> wrote:
> David Drysdale <drysdale@...gle.com> writes:
>> On Tue, Oct 21, 2014 at 5:29 AM, Eric W. Biederman
>> <ebiederm@...ssion.com> wrote:
>>> It is more a description of what we have done but as a magic string it
>>> is descriptive.  Documetation/devices.txt documents that /dev/fd/ should
>>> exist, making it an unambiguous path.  Further these days the kernel
>>> sets the device naming policy in dev, so I think we are strongly safe in
>>> using that path in any event.
>>>
>>> I think execveat is interesting in the kernel because the motivating
>>> cases are the cases where anything except a static executable is
>>> uninteresting.
>>
>> FYI, there is potential in the future for something other than static
>> executables -- the FreeBSD Capsicum implementation includes changes
>> to the dynamic linker to get its search path as a list of pre-opened dfds
>> (in LD_LIBRARY_PATH_FDS) rather than paths.
>
> Which still leaves open the question how do you find the dynamic
> linker.  Is that also a pre-opened dfd?

I *think* it's still effectively a path lookup of the INTERP header in
the kernel (but the pathname is restricted to be one of a set of
standard pre-registered interpreters).

> Using /dev/fd/$N is also the kind of thing that a shell or a script
> interpret could special case instead relying on a filesystem node
> to exist.

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