[patch 050/160] prctl: add PR_SET_PROCTITLE_AREA option for prctl()

[patch 050/160] prctl: add PR_SET_PROCTITLE_AREA option for prctl()

[akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b]

From: KOSAKI Motohiro <kosaki.motohiro-+CUm20s59erQFUHtdCDX3A@public.gmane.org>

Currently glibc2 doesn't have setproctitle(3), so several userland daemons
attempt to emulate it by doing some brutal stack modifications.  This
works most of the time, but it has problems.  For example:

 % ps -ef |grep avahi-daemon
 avahi     1679     1  0 09:20 ?        00:00:00 avahi-daemon: running [kosadesk.local]

 # cat /proc/1679/cmdline
 avahi-daemon: running [kosadesk.local]

This looks good, but the process has also overwritten its environment area
and made the environ file useless:

 # cat /proc/1679/environ
 adesk.local]

Another problem is that the process title length is limited by the size of
the environment.  Security conscious people try to avoid potential
information leaks by clearing most of the environment before running a
daemon:

 # env - MINIMUM_NEEDED_VAR=foo /path/to/daemon

The resulting environment size may be too small to fit the wanted process
titles.

This patch makes it possible for userspace to implement setproctitle()
cleanly.  It adds a new PR_SET_PROCTITLE_AREA option for prctl(), which
updates task's mm_struct->arg_start and arg_end to the given area.

 test_setproctitle.c
 ================================================
 #include <string.h>
 #include <stdlib.h>
 #include <unistd.h>
 #include <stdio.h>
 #include <sys/prctl.h>

 #define ERR(str) (perror(str), exit(1))

 void settitle(char* title){
         int err;

         err = prctl(35, title, strlen(title)+1);
         if (err < 0)
                 ERR("prctl ");
 }

 void main(void){
         long i;
         char buf[1024];

         for (i = 0; i < 10000000000LL; i++){
                 sprintf(buf, "loooooooooooooooooooooooong string %d",i);
                 settitle(buf);
         }
 }
 ==================================================

Signed-off-by: KOSAKI Motohiro <kosaki.motohiro-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
Signed-off-by: Timo Sirainen <tss-X3B1VOXEql0@public.gmane.org>
Cc: Bryan Donlan <bdonlan-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Ulrich Drepper <drepper-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: "H. Peter Anvin" <hpa-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org>
Cc: WANG Cong <xiyou.wangcong-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Oleg Nesterov <oleg-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: Ingo Molnar <mingo-X9Un+BFzKDI@public.gmane.org>
Cc: <linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Signed-off-by: Andrew Morton <akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
---

 fs/proc/base.c        |   39 +++++++++++++++++++++++++++++----------
 include/linux/mm.h    |    2 ++
 include/linux/prctl.h |    3 +++
 kernel/sys.c          |   26 ++++++++++++++++++++++++++
 mm/memory.c           |   40 +++++++++++++++++++++++++++-------------
 5 files changed, 87 insertions(+), 23 deletions(-)

diff -puN fs/proc/base.c~prctl-add-pr_set_proctitle_area-option-for-prctl fs/proc/base.c
--- a/fs/proc/base.c~prctl-add-pr_set_proctitle_area-option-for-prctl
+++ a/fs/proc/base.c
@@ -255,34 +255,53 @@ static int proc_pid_cmdline(struct task_
 	int res = 0;
 	unsigned int len;
 	struct mm_struct *mm = get_task_mm(task);
+
 	if (!mm)
 		goto out;
+
+	/* The process was not constructed yet? */
 	if (!mm->arg_end)
 		goto out_mm;	/* Shh! No looking before we're done */
 
- 	len = mm->arg_end - mm->arg_start;
- 
+	down_read(&mm->mmap_sem);
+	len = mm->arg_end - mm->arg_start;
 	if (len > PAGE_SIZE)
 		len = PAGE_SIZE;
- 
-	res = access_process_vm(task, mm->arg_start, buffer, len, 0);
 
-	// If the nul at the end of args has been overwritten, then
-	// assume application is using setproctitle(3).
+	res = access_process_vm_locked(task, mm, mm->arg_start, buffer, len, 0);
+
+	/*
+	 * If argv and environ aren't continuous (i.e. the process used
+	 * prctl(PR_SET_PROCTITLE_AREA)), we don't care about the evironment
+	 * override.
+	 */
+	if (mm->arg_end != mm->env_start)
+		goto out_unlock;
+
+	/*
+	 * If the nul at the end of args has been overwritten, then assume
+	 * application is using sendmail's SPT_REUSEARGV style argv override.
+	 */
 	if (res > 0 && buffer[res-1] != '\0' && len < PAGE_SIZE) {
 		len = strnlen(buffer, res);
-		if (len < res) {
-		    res = len;
-		} else {
+		if (len < res)
+			res = len;
+		else {
 			len = mm->env_end - mm->env_start;
 			if (len > PAGE_SIZE - res)
 				len = PAGE_SIZE - res;
-			res += access_process_vm(task, mm->env_start, buffer+res, len, 0);
+			res += access_process_vm_locked(task, mm, mm->env_start,
+							buffer+res, len, 0);
 			res = strnlen(buffer, res);
 		}
 	}
+
+out_unlock:
+	up_read(&mm->mmap_sem);
+
 out_mm:
 	mmput(mm);
+
 out:
 	return res;
 }
diff -puN include/linux/mm.h~prctl-add-pr_set_proctitle_area-option-for-prctl include/linux/mm.h
--- a/include/linux/mm.h~prctl-add-pr_set_proctitle_area-option-for-prctl
+++ a/include/linux/mm.h
@@ -835,6 +835,8 @@ static inline int handle_mm_fault(struct
 
 extern int make_pages_present(unsigned long addr, unsigned long end);
 extern int access_process_vm(struct task_struct *tsk, unsigned long addr, void *buf, int len, int write);
+extern int access_process_vm_locked(struct task_struct *tsk, struct mm_struct *mm,
+				    unsigned long addr, void *buf, int len, int write);
 
 int get_user_pages(struct task_struct *tsk, struct mm_struct *mm,
 			unsigned long start, int nr_pages, int write, int force,
diff -puN include/linux/prctl.h~prctl-add-pr_set_proctitle_area-option-for-prctl include/linux/prctl.h
--- a/include/linux/prctl.h~prctl-add-pr_set_proctitle_area-option-for-prctl
+++ a/include/linux/prctl.h
@@ -102,4 +102,7 @@
 
 #define PR_MCE_KILL_GET 34
 
+/* Set process title memory area for setproctitle() */
+#define PR_SET_PROCTITLE_AREA 35
+
 #endif /* _LINUX_PRCTL_H */
diff -puN kernel/sys.c~prctl-add-pr_set_proctitle_area-option-for-prctl kernel/sys.c
--- a/kernel/sys.c~prctl-add-pr_set_proctitle_area-option-for-prctl
+++ a/kernel/sys.c
@@ -1575,6 +1575,32 @@ SYSCALL_DEFINE5(prctl, int, option, unsi
 			else
 				error = PR_MCE_KILL_DEFAULT;
 			break;
+		case PR_SET_PROCTITLE_AREA: {
+			struct mm_struct *mm = current->mm;
+			unsigned long start = arg2;
+			unsigned long len = arg3;
+			unsigned long end = start + len;
+
+			if (len > PAGE_SIZE)
+				return -EINVAL;
+
+			/*
+			 * If the process pass broken pointer, EFAULT is might better
+			 * than ps output zero-length proctitle. Plus if
+			 * the process pass kernel address (or something-else),
+			 * We have to block it. Oherwise, strange exploit
+			 * chance is there.
+			 */
+			if (!access_ok(VERIFY_READ, start, len))
+				return -EFAULT;
+
+			down_write(&mm->mmap_sem);
+			mm->arg_start = start;
+			mm->arg_end = end;
+			up_write(&mm->mmap_sem);
+
+			return 0;
+		}
 		default:
 			error = -EINVAL;
 			break;
diff -puN mm/memory.c~prctl-add-pr_set_proctitle_area-option-for-prctl mm/memory.c
--- a/mm/memory.c~prctl-add-pr_set_proctitle_area-option-for-prctl
+++ a/mm/memory.c
@@ -3378,22 +3378,13 @@ int generic_access_phys(struct vm_area_s
 }
 #endif
 
-/*
- * Access another process' address space.
- * Source/target buffer must be kernel space,
- * Do not walk the page table directly, use get_user_pages
- */
-int access_process_vm(struct task_struct *tsk, unsigned long addr, void *buf, int len, int write)
+/* Similar to access_process_vm(), but mmap_sem held is required. */
+int access_process_vm_locked(struct task_struct *tsk, struct mm_struct *mm,
+			     unsigned long addr, void *buf, int len, int write)
 {
-	struct mm_struct *mm;
 	struct vm_area_struct *vma;
 	void *old_buf = buf;
 
-	mm = get_task_mm(tsk);
-	if (!mm)
-		return 0;
-
-	down_read(&mm->mmap_sem);
 	/* ignore errors, just check how much was successfully transferred */
 	while (len) {
 		int bytes, ret, offset;
@@ -3440,10 +3431,33 @@ int access_process_vm(struct task_struct
 		buf += bytes;
 		addr += bytes;
 	}
+
+	return buf - old_buf;
+}
+
+/*
+ * Access another process' address space.
+ * Source/target buffer must be kernel space,
+ * Do not walk the page table directly, use get_user_pages
+ * ignore errors, just check how much was successfully transferred. IOW, this
+ * function always return >=0 value.
+ */
+int access_process_vm(struct task_struct *tsk, unsigned long addr, void *buf, int len, int write)
+{
+	int ret;
+	struct mm_struct *mm;
+
+	/* Probably tsk isn't current. We can't access tsk->mm directly. */
+	mm = get_task_mm(tsk);
+	if (!mm)
+		return 0;
+
+	down_read(&mm->mmap_sem);
+	ret = access_process_vm_locked(tsk, mm, addr, buf, len, write);
 	up_read(&mm->mmap_sem);
 	mmput(mm);
 
-	return buf - old_buf;
+	return ret;
 }
 
 /*
_

Re: [patch 050/160] prctl: add PR_SET_PROCTITLE_AREA option for prctl()

[Linus Torvalds]

On Fri, 5 Mar 2010, akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org wrote:
> 
> This patch makes it possible for userspace to implement setproctitle()
> cleanly.  It adds a new PR_SET_PROCTITLE_AREA option for prctl(), which
> updates task's mm_struct->arg_start and arg_end to the given area.

This looks overly complicated. Why do you change the whole locking rules, 
instead of protecting _only_ the "arg_start/arg_end" case? 

The thing is, there's no reason to hold the mmap_sem over the whole thing, 
and I don't think this is important enough to be a valid reason for 
exposing a whole new "locked" access variant, when a simple "protect just 
the arg_start/end" would handle it.

			Linus

Re: [patch 050/160] prctl: add PR_SET_PROCTITLE_AREA option for prctl()

[Oleg Nesterov]

On 03/06, Linus Torvalds wrote:
>
> On Fri, 5 Mar 2010, akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org wrote:
> >
> > This patch makes it possible for userspace to implement setproctitle()
> > cleanly.  It adds a new PR_SET_PROCTITLE_AREA option for prctl(), which
> > updates task's mm_struct->arg_start and arg_end to the given area.
>
> This looks overly complicated. Why do you change the whole locking rules,
> instead of protecting _only_ the "arg_start/arg_end" case?
>
> The thing is, there's no reason to hold the mmap_sem over the whole thing,
> and I don't think this is important enough to be a valid reason for
> exposing a whole new "locked" access variant, when a simple "protect just
> the arg_start/end" would handle it.

It was me who suggested to re-use mm->mmap_sem instead of adding the new
lock, but looking at this patch again I do not understand the reason this
lock should be held throughout in proc_pid_cmdline(). If there is no such
a reason, then the new access_process_vm_locked (cough, also suggested by
me ;) is not needed.

Oleg.

Re: [patch 050/160] prctl: add PR_SET_PROCTITLE_AREA option for prctl()

[Bryan Donlan]

On Sun, Mar 7, 2010 at 14:28, Oleg Nesterov <oleg-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> On 03/06, Linus Torvalds wrote:
>>
>> On Fri, 5 Mar 2010, akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org wrote:
>> >
>> > This patch makes it possible for userspace to implement setproctitle()
>> > cleanly.  It adds a new PR_SET_PROCTITLE_AREA option for prctl(), which
>> > updates task's mm_struct->arg_start and arg_end to the given area.
>>
>> This looks overly complicated. Why do you change the whole locking rules,
>> instead of protecting _only_ the "arg_start/arg_end" case?
>>
>> The thing is, there's no reason to hold the mmap_sem over the whole thing,
>> and I don't think this is important enough to be a valid reason for
>> exposing a whole new "locked" access variant, when a simple "protect just
>> the arg_start/end" would handle it.
>
> It was me who suggested to re-use mm->mmap_sem instead of adding the new
> lock, but looking at this patch again I do not understand the reason this
> lock should be held throughout in proc_pid_cmdline(). If there is no such
> a reason, then the new access_process_vm_locked (cough, also suggested by
> me ;) is not needed.

Consider:

Process A is reading /proc/pidB/cmdline. As it enters
proc_pid_cmdline, the compiler stashes mm->arg_end and mm->arg_start
in a register or something, and then the process is preempted.
Process B now changes the location of its cmdline buffer. After
changing it, it free()s the buffer. Then it malloc()s a buffer for
sensitive data. Unfortunately, this happens to be at the same address.
Eventually control returns to process A, which reads sensitive data
out of process B's address space using the stale values for arg_end
and arg_start. Process A did not have to be a privileged process or
the same uid to do this.

Note that B cannot defend against this, as it has no idea how long a
hypothetical process A may be preempted. If B is a high-priority or
real-time process, A may be preempted for a very long time indeed.
Alternately process A may be interrupted by a slow interrupt handler.

Since B cannot determine when it may be safe to re-use the buffer, the
conclusion is that without a lock of some sort in the kernel, B must
never re-use any memory used for its cmdline buffer, which is a very
undesirable result.

Re: [patch 050/160] prctl: add PR_SET_PROCTITLE_AREA option for prctl()

[Oleg Nesterov]

On 03/07, Bryan Donlan wrote:
>
> On Sun, Mar 7, 2010 at 14:28, Oleg Nesterov <oleg-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> > On 03/06, Linus Torvalds wrote:
> >>
> >> On Fri, 5 Mar 2010, akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org wrote:
> >> >
> >> > This patch makes it possible for userspace to implement setproctitle()
> >> > cleanly.  It adds a new PR_SET_PROCTITLE_AREA option for prctl(), which
> >> > updates task's mm_struct->arg_start and arg_end to the given area.
> >>
> >> This looks overly complicated. Why do you change the whole locking rules,
> >> instead of protecting _only_ the "arg_start/arg_end" case?
> >>
> >> The thing is, there's no reason to hold the mmap_sem over the whole thing,
> >> and I don't think this is important enough to be a valid reason for
> >> exposing a whole new "locked" access variant, when a simple "protect just
> >> the arg_start/end" would handle it.
> >
> > It was me who suggested to re-use mm->mmap_sem instead of adding the new
> > lock, but looking at this patch again I do not understand the reason this
> > lock should be held throughout in proc_pid_cmdline(). If there is no such
> > a reason, then the new access_process_vm_locked (cough, also suggested by
> > me ;) is not needed.
>
> Consider:
>
> Process A is reading /proc/pidB/cmdline. As it enters
> proc_pid_cmdline, the compiler stashes mm->arg_end and mm->arg_start
> in a register or something, and then the process is preempted.
> Process B now changes the location of its cmdline buffer. After
> changing it, it free()s the buffer. Then it malloc()s a buffer for
> sensitive data. Unfortunately, this happens to be at the same address.

Indeed, I see, thanks.

Oleg.

Re: [patch 050/160] prctl: add PR_SET_PROCTITLE_AREA option for prctl()

[KOSAKI Motohiro]

> On Fri, Mar 05, 2010 at 01:42:37PM -0800, akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org wrote:
> > This patch makes it possible for userspace to implement setproctitle()
> > cleanly.  It adds a new PR_SET_PROCTITLE_AREA option for prctl(), which
> > updates task's mm_struct->arg_start and arg_end to the given area.
> 
> Why can't we make this a proper system call?

I don't think this is big matter. Does using syscall have any benefit?
I don't have strong mention. merely, Timo's original proposal used
prctl.

Re: [patch 050/160] prctl: add PR_SET_PROCTITLE_AREA option for prctl()

[KOSAKI Motohiro]

> 
> 
> On Fri, 5 Mar 2010, akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org wrote:
> > 
> > This patch makes it possible for userspace to implement setproctitle()
> > cleanly.  It adds a new PR_SET_PROCTITLE_AREA option for prctl(), which
> > updates task's mm_struct->arg_start and arg_end to the given area.
> 
> This looks overly complicated. Why do you change the whole locking rules, 
> instead of protecting _only_ the "arg_start/arg_end" case? 
> 
> The thing is, there's no reason to hold the mmap_sem over the whole thing, 
> and I don't think this is important enough to be a valid reason for 
> exposing a whole new "locked" access variant, when a simple "protect just 
> the arg_start/end" would handle it.

Hmm..

I did it at several previous iteration. but Alan and Oleg don't like such
approach. After small discussion, we concluded that this reusing mmap_sem doesn't
have unignorable downside.

We discussed this patch need to conder following two performance worrieness.

Q1) The system doesn't have badboy process, it shouldn't have system
    performance degression.
A1) In writer side, setproctitle() is not frequently called function.
    then, performance damage is nothing. In reader side, this patch doesn't
    add to take any new lock.

Q2) The attacker's process use setproctitle() for attack. The system
    should have enough DoS tolerability.
A2) a lot of /proc file takes mmap_sem. then, this feature doesn't introduce
    new attack way. plus, fork-bomb provide very efficient attack way rather
    than mmap_sem flood. then, we concluded the attackers don't use mmap_sem
    flood in practice.


However, reusing mmap_sem is not my strong mention. if you really dislike it,
I can change it soon.

Re: [patch 050/160] prctl: add PR_SET_PROCTITLE_AREA option for prctl()

[Ulrich Drepper]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/08/2010 08:44 PM, KOSAKI Motohiro wrote:
> I don't think this is big matter. Does using syscall have any benefit?
> I don't have strong mention. merely, Timo's original proposal used
> prctl.

Syscalls don't have to go through the multiplexer in grab bag calls like
prctl, ioctl, etc.  And they are more reliably to test for at runtime.
An ENOSYS error is unmistakably clear.  An EINVAL error, as returned by
prctl when encountering an unknown function argument, could also mean
the argument isn't valid.  That's a common problem of most multiplexer
syscalls and a reason why they should be avoided.

- -- 
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAkuV2vMACgkQ2ijCOnn/RHTRYgCeJd0O3O71jHtvGhvOG5Ax2oxP
I5UAnjujkQBlHxFzXqhsEMavsaVVsEBf
=PnMs
-----END PGP SIGNATURE-----

Re: [patch 050/160] prctl: add PR_SET_PROCTITLE_AREA option for prctl()

[Oleg Nesterov]

On 03/08, Ulrich Drepper wrote:
>
> On 03/08/2010 08:44 PM, KOSAKI Motohiro wrote:
> > I don't think this is big matter. Does using syscall have any benefit?
> > I don't have strong mention. merely, Timo's original proposal used
> > prctl.
>
> Syscalls don't have to go through the multiplexer in grab bag calls like
> prctl, ioctl, etc.  And they are more reliably to test for at runtime.
> An ENOSYS error is unmistakably clear.  An EINVAL error, as returned by
> prctl when encountering an unknown function argument, could also mean
> the argument isn't valid.  That's a common problem of most multiplexer
> syscalls and a reason why they should be avoided.

Agreed, but this applies to any prtcl() request. And we already have
PR_GET_NAME/PR_SET_NAME which is very close to PR_SET_PROCTITLE_AREA.

So, do you really think that this particular case deserves the new
syscall?

Oleg.

Re: [patch 050/160] prctl: add PR_SET_PROCTITLE_AREA option for prctl()

[Ulrich Drepper]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/09/2010 02:17 PM, Oleg Nesterov wrote:
> So, do you really think that this particular case deserves the new
> syscall?

Continuing a bad thing is never a good reason.  Break bad habits.

- -- 
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAkuWzLgACgkQ2ijCOnn/RHSihgCeItNRJlTgBzosgepyQ1SE20qT
qtgAn327G9cf7PVoda7h1+ZoUyDrvzI8
=fgxr
-----END PGP SIGNATURE-----

Re: [patch 050/160] prctl: add PR_SET_PROCTITLE_AREA option for prctl()

[KOSAKI Motohiro]

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 03/09/2010 02:17 PM, Oleg Nesterov wrote:
> > So, do you really think that this particular case deserves the new
> > syscall?
> 
> Continuing a bad thing is never a good reason.  Break bad habits.

OK. the opinion of caller folks (i.e. you) should be important
rather than the patch maker. I'll make respin.

thanks.