linux-kernel - Re: [PATCH signal#execve2] syscalls,x86: Add execveat() system call (v3)

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:	Tue, 8 Jan 2013 12:39:48 +0000
From:	Meredydd Luff <meredydd@...atehouse.org>
To:	Al Viro <viro@...iv.linux.org.uk>
Cc:	linux-kernel@...r.kernel.org, "H. Peter Anvin" <hpa@...or.com>,
	Kees Cook <keescook@...omium.org>,
	Ingo Molnar <mingo@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH signal#execve2] syscalls,x86: Add execveat() system call (v3)

On Sun, Jan 6, 2013 at 4:31 PM, Al Viro <viro@...iv.linux.org.uk> wrote:
>
> OK, now that sys_execve() unification has settled down, let's get back
> to this one.  The real problem is what you are doing with bprm->filename
> and bprm->interp; blind use of ->d_name is completely wrong.
ACK. I've blocked out tomorrow to dive in and figure out what I should
be doing instead. My current plan is "look at how we get a string
value out when readlink()ing /proc/self/fd/N, then copy that
approach". Feel free to save me from wasting time if this is a bad
idea.

> For what it's worth, how should it work for e.g. shell scripts?  That's
> the main user of bprm->{filename,interp}, after all - other places are
> either seriously exotic or are just using it for printks.
>
> For shell scripts, however, these guys are really used - we have the original
> argv[0] removed and <shell name> <optional argument> <filename> pushed in
> its place.

As I see it, this is a question of how much can be supported.
Fundamentally, a hash-bang interpreter is handed a filename. This will
inevitably break in a world in which not everything you want to
execute can be reliably named by a path in the interpreter's
namespace. The demand for a "real" fexecve() argues that this world is
desirable, and under those circumstances the best you can hope for is
probably to fail gracefully, or at least predictably.

> How will it work with execveat()?  If we have procfs in place, we can
> cook an equivalent pathname (/proc/self/fd/<n>/<relative part of pathname>),
> but then why not do just that in userland and be done with that?
A pure-userland execveat() suffers all the problems of a pure-userland
fexecve(). I think it's important to be able to use this in
environments where /proc is absent or not trustworthy (weird embedded
systems, sandboxes, etc).

If I'm understanding this right, the behaviour I was originally
planning would leave the hash-bang interpreter with a pathname that
"should" resolve to the script, barring jiggery-pokery with passing
FDs between namespaces - but without the atomicity of the *at() call.
This places execveat() into the category of "desirable things whose
atomicity guarantees interact poorly with shell scripts" (a group with
a long and [ig]noble history).

I suppose the munging could be conditional: "If /proc is owned by root
and mounted as procfs, we'll give you a /proc/self/fd/... path.
Otherwise you're on your own and getting whatever
readlink(/proc/self/fd/<n>) would have given you." But that would
still require the kernel knowing something about the filesystem
layout.

Either way, it seems, we leave a rake in the grass for somebody...

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