linux-kernel - Re: [patch 1/3] MAP_NOZERO - implement a new VM_NOZERO/MAP

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:	Thu, 28 Jun 2007 11:24:13 -0700 (PDT)
From:	Davide Libenzi <davidel@...ilserver.org>
To:	Andy Isaacson <adi@...apodia.org>
cc:	Rik van Riel <riel@...hat.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [patch 1/3] MAP_NOZERO - implement a new VM_NOZERO/MAP_NOZERO
 page retirement policy

On Wed, 27 Jun 2007, Andy Isaacson wrote:

> On Tue, Jun 26, 2007 at 09:32:44PM -0700, Davide Libenzi wrote:
> > > Because an SUID program can change its UID back.
> > > 
> > > At least, one that was SUID root.  OTOH, any
> > > program running as root can change UID, so we
> > > should probably not allow root to get nonzeroed
> > > pages.
> > 
> > Well, root can in general access the whole system in any case. At the 
> > moment, root cannot access othe UIDs pages. Only their own. And this 
> > differs from standard security policies where root can access everything.
> > Pages used internally by the kernel, cannot be reused by anyone.
> 
> But MAP_NOZERO adds a new possible information leak from root out to the
> non-root user.  If root does
> 
>     setuid(newuid);
>     exec(...);
>     exit(1);
> 
> and there are MAP_NOZERO pages which contain sensitive information,
> a process running as newuid would be able to race the exec with
> PTRACE_ATTACH and extract the sensitive information.  Without MAP_NOZERO
> the information leak is limited to information which was in the setuid
> program's address space (and presumably, setuid programs are written to
> be careful about such things).

That probably deserves a patch alone (see below), besides MAP_NOZERO. 
Basically, a new "exec uid" is added and such exec-uid is set only after 
the binary completed the detach from the old context. Ptrace check that 
uid also, and part of the may_attach() function.



> That said, I think I like the idea of MAP_NOZERO.  Could it be
> generalized to some kind of "free pool" rather than keyed off of uid?

Problem is, you end up with yet another pool to be looked up, flushed 
under memory pressure, etc..



- Davide



---
 fs/exec.c             |    2 ++
 include/linux/sched.h |    2 +-
 kernel/ptrace.c       |    1 +
 3 files changed, 4 insertions(+), 1 deletion(-)

Index: linux-2.6.mod/fs/exec.c
===================================================================
--- linux-2.6.mod.orig/fs/exec.c	2007-06-28 11:15:53.000000000 -0700
+++ linux-2.6.mod/fs/exec.c	2007-06-28 11:18:47.000000000 -0700
@@ -905,6 +905,8 @@
 	flush_signal_handlers(current, 0);
 	flush_old_files(current->files);
 
+	current->xuid = current->uid;
+
 	return 0;
 
 mmap_failed:
Index: linux-2.6.mod/include/linux/sched.h
===================================================================
--- linux-2.6.mod.orig/include/linux/sched.h	2007-06-28 11:16:15.000000000 -0700
+++ linux-2.6.mod/include/linux/sched.h	2007-06-28 11:16:49.000000000 -0700
@@ -917,7 +917,7 @@
 	struct list_head cpu_timers[3];
 
 /* process credentials */
-	uid_t uid,euid,suid,fsuid;
+	uid_t uid,euid,suid,fsuid,xuid;
 	gid_t gid,egid,sgid,fsgid;
 	struct group_info *group_info;
 	kernel_cap_t   cap_effective, cap_inheritable, cap_permitted;
Index: linux-2.6.mod/kernel/ptrace.c
===================================================================
--- linux-2.6.mod.orig/kernel/ptrace.c	2007-06-28 11:09:27.000000000 -0700
+++ linux-2.6.mod/kernel/ptrace.c	2007-06-28 11:18:35.000000000 -0700
@@ -135,6 +135,7 @@
 		return 0;
 	if (((current->uid != task->euid) ||
 	     (current->uid != task->suid) ||
+	     (current->xuid != task->xuid) ||
 	     (current->uid != task->uid) ||
 	     (current->gid != task->egid) ||
 	     (current->gid != task->sgid) ||
-
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/