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

Date:	Sat, 25 Oct 2014 23:22:21 +0200
From:	Pavel Machek <pavel@....cz>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	Al Viro <viro@...iv.linux.org.uk>,
	David Drysdale <drysdale@...gle.com>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	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

Hi!

> >> Oh, you mean that #!/usr/bin/make -f would turn into /usr/bin/make
> >> /dev/fd/3?  That could be interesting, although I can imagine it
> >> breaking things, especially if /dev/fd/3 isn't set up like that, e.g.
> >> early in boot.
> >
> > Sigh...  What I mean is that fexecve(fd, ...) would have to put _something_
> > into argv when it execs the interpreter of #! file.  Simply because the
> > interpreter (which can be anything whatsoever) has no fscking idea what
> > to do with some descriptor it has before execve().  Hell, it doesn't have
> > any idea *which* descriptor had it been.
> >
> > You need to put some pathname that would yield your script upon open(2).
> > If you bothered to read those patches, you'd see that they do supply
> > one, generating it with d_path().  Which isn't particulary reliable.
> >
> > I'm not sure there's any point putting any of that in the kernel - if
> > you *do* have that pathname, you can just pass it.
> 
> Hmm.
> 
> This issue certainly makes fexecve or execveat less attractive, at
> least in cases where d_path won't work.
> 
> On the other hand, if you want to run a static binary on a cloexec fd
> (or, for that matter, a dynamic binary if you trust the interpreter to
> close the extra copy of the fd it gets) in a namespace or chroot where
> the binary is invisible, then you need kernel help.
> 
> It's too bad that script interpreters don't have a mechanism to open
> their scripts by fd.

Every interpretter depends on /dev/zero... so what about having
/dev/script_im_running? Standard character device, contains whatever
script it should contain...
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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/