linux-kernel - Re: [PATCH] allow execve'ing "/proc/self/exe" even if /proc is not mounted

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

Message-ID: <1158166a0906261618g48605091y2478b832fb25b9a3@mail.gmail.com>
Date:	Sat, 27 Jun 2009 01:18:27 +0200
From:	Denys Vlasenko <vda.linux@...glemail.com>
To:	Al Viro <viro@...iv.linux.org.uk>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Mike Frysinger <vapier@...too.org>
Subject: Re: [PATCH] allow execve'ing "/proc/self/exe" even if /proc is not 
	mounted

On Thu, Jun 25, 2009 at 1:58 AM, Al Viro<viro@...iv.linux.org.uk> wrote:
>> With this patch, it is possible to execute /proc/self/exe
>> even if /proc is not mounted.
>
>> How patch does it: when execve syscall discovers that opening of binary
>> image fails, a small bit of code is added to special case "/proc/self/exe"
>> string. If binary name is *exactly* that string, and if error is ENOENT
>> or EACCES, then exec will still succeed, using current binary's image.
>>
>> Please apply.
>
> No.  This is just plain sick.  Magical pathnames have no business being
> in the kernel.

This is not a magical *pathname*. It only looks like it.
This is the magic 1st argument of execve which makes it perform reexecve().
Sorry, I had to explain it in the first email...

Creating entire new syscall reexecve() just for this purpose seems excessive.
Special-casing execve allows to avoid this.

I could have used "Please reexec me!!!" as a magic 1st parameter to execve.
This has two downsides: the string, however weird, still *can* match
a real file. Second, userspace needs to be modified to use such a name.

Magic parameter of the form "/proc/self/exe" does not suffer from
2nd problem. Userspace already uses it exactly for this purpose,
no change needed.

> If procfs is too much for your sensitive soul, do an
> extremely trimmed-down version that would consist of *one* *file* (yes,
> as root and only node on fs).  Said file being a procfs-style symlink,
> doing exactly what /proc/self/exec would do.
>
> On such system you can just mkdir /proc/self, touch /proc/self/exec,
> mount -t self_exec none /proc/self/exec and be done with that.  No
> magic needed, end of the story.

This would use many times more memory than a small code addition
on an execve's error path I posted.

It also would require mounting a filesystem. So the shell started by
init=/bin/sh on NOMMU machine either will need to be programmed
to do it when execve("/proc/self/exe") fails, or the user will need
to be taught to do it by hand before user can be sure the shell
will be able to run some POSIX constructs like function calls
in pipes etc.

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