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

Message-ID: <4681E52A.8030300@redhat.com>
Date:	Wed, 27 Jun 2007 00:18:50 -0400
From:	Rik van Riel <riel@...hat.com>
To:	Davide Libenzi <davidel@...ilserver.org>
CC:	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

Davide Libenzi wrote:
> On Tue, 26 Jun 2007, Rik van Riel wrote:
> 
>> SUID programs should not be able to use this feature,
>> either.
> 
> Why? A SUID programs runs under the UID of the owner, and should be no 
> problems in it seeing the owners data.

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.

> But the patch post was more a quest for possible scenarios where the use 
> of MAP_NOZERO can result in lower security WRT the same program (under the 
> same security restrictions) not using such feature.
> If you have something specific in mind, please go ahead and shoot.

Besides the non-enforcing of SELinux security
labels (and maybe namespaces?), I cannot think
of anything.

>>> When pages exit (unmapped from) a  vma, they are marked with the effective
>>> UID of the  mm_struct  that owns it.
>>
>>> --- linux-2.6.mod.orig/include/linux/mm_types.h	2007-06-21
>>> 14:02:06.000000000 -0700
>>> +++ linux-2.6.mod/include/linux/mm_types.h	2007-06-25 19:11:22.000000000
>>> -0700
>>> @@ -64,6 +64,7 @@
>>>  	struct list_head lru;		/* Pageout list, eg. active_list
>>>  					 * protected by zone->lru_lock !
>>>  					 */
>>> +	int owner_uid;			/* Last owner of the page */
>>>  	/*
>>>  	 * On machines where all RAM is mapped into kernel address space,
>>>  	 * we can simply calculate the virtual address. On machines with
>> Since this is only set when the page is freed, could
>> the owner_uid and security context be put inside a
>> union with some fields that are not otherwise used
>> for free pages?
> 
> I tried to look, and the attempt to reuse _mapcount failed miserably :)
> The last time we have the owner info (vma->mm) available, is before 
> processing of the other fields ends. OTOH I'm not VM guru either, so I may 
> be wrong. It can share ->virtual (when enabled).

I think the process that actually calls the page freeing
functions is always the process that owned the page, so
going for current->mm should work.

Getting the UID wrong for file pages caught in a truncate
is fine, since the process obviously already had access
to the data in that page.

-- 
Politics is the struggle between those who want to make their country
the best in the world, and those who believe it already is.  Each group
calls the other unpatriotic.
-
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/