Re: [uml-devel] T-mode processes

[BlaisorBlade <blaisorblade_spam@yahoo.it>]

On Monday 04 October 2004 22:25, Henrik Nordstrom wrote:
> On Mon, 4 Oct 2004, BlaisorBlade wrote:
> > Actually, what I should do is to set the "mm->dumpable" flag to 1 inside
> > mm/proc_mm.c (after mm_alloc(), it is 0). The situation is clear.
> > However, to write a good patch, I want to study well the "mm->dumpable"
> > flag use (when it's set, when not...) otherwise I could open a security
> > hole (even because there are people using UML setuid to root, for the
> > mlock() patch).
>
> I don't think it is safe to set dumpable to 1 once it has become 0.

I think you are overlooking something ... read the original mail. The problem 
is that for the userspace thread mm->dumpable is always 0, and this happens 
on every known SKAS3 patch revision. Simply nobody thought about this before 
now.

The field does not "become" 0. allocate_mm, or whatever, allocates the 
mm_struct, fills it with 0, and then initializes some basic fields. After 
fork and execve, the dumpable field is adjusted according to the needs (and 
can become 1).

Since opening /proc/mm is more or less like creating a new process (or even 
like forking), dumpable can become 1, following the general Linux rules. 

Actually, the current fork() code simply copies the dumpable flag with all the 
rest, and does not change it; this also makes a lot of sense, and I guess 
that open_proc_mm will just copy the current->mm->dumpable setting to the new 
mm.

However, that's a problem if a process using /proc/mm changes its setting of 
mm->dumpable (which happens on uid changes and with prctl). Does in that case 
the uid of the ptraced process change?

If needed, it could be reloaded on the new mm when using PROC_SWITCH_MM, but 
that is strange. Also, I don't understand why prctl() does not do any 
security check.

And anyway, I'm not rushing on this... I want to study the mainstream code and 
the ptrace exploit patch, before coding anything here.

> If you want to fix this you need to find secure ways to prevent it from
> becoming 0, or to add another parameter defining "security restricted"
> processes differently from dumpable.

Hmm, Alan Cox has been writing some changes to the dumpable flag (a sysctl 
option, I think).

Bye
-- 
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel