All of lore.kernel.org
 help / color / mirror / Atom feed
From: Serge Hallyn <serge.hallyn@canonical.com>
To: Cyrill Gorcunov <gorcunov@gmail.com>
Cc: Kees Cook <keescook@chromium.org>,
	linux-kernel@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>,
	Tejun Heo <tj@kernel.org>, Andrew Vagin <avagin@openvz.org>,
	Pavel Emelyanov <xemul@parallels.com>,
	Vasiliy Kulikov <segoon@openwall.com>
Subject: Re: [rfc 3/3] prctl: Add PR_SET_MM codes to tune up mm_struct entires
Date: Tue, 29 Nov 2011 14:49:11 -0600	[thread overview]
Message-ID: <4ED54547.5060905@canonical.com> (raw)
In-Reply-To: <20111129202951.GG1775@moon>

On 11/29/2011 02:29 PM, Cyrill Gorcunov wrote:
> On Tue, Nov 29, 2011 at 12:19:38PM -0800, Kees Cook wrote:
>> On Tue, Nov 29, 2011 at 11:12:55PM +0400, Cyrill Gorcunov wrote:
>>> At restore time we need a mechanism to restore those values
>>> back and for this sake PR_SET_MM prctl code is introduced.
>>>
>>> Note at moment this inteface is allowed for CAP_SYS_ADMIN
>>> only.
>>
>> NAK from me; this needs more bounds checking. Though, yes, it absolutely
>> must be a privileged action since this is potentially very dangerous. Can
>> we invent something stronger than CAP_SYS_ADMIN? ;)
>
> Heh.
>
>>
>>> @@ -1841,6 +1841,58 @@ SYSCALL_DEFINE5(prctl, int, option, unsi
>>>   			else
>>>   				error = PR_MCE_KILL_DEFAULT;
>>>   			break;
>>> +		case PR_SET_MM: {
>>> +			struct mm_struct *mm;
>>> +			struct vm_area_struct *vma;
>>> +
>>> +			if (arg4 | arg5)
>>> +				return -EINVAL;
>>> +
>>> +			if (!capable(CAP_SYS_ADMIN))
>>> +				return -EPERM;
>>> +
>>> +			error = -ENOENT;
>>> +			mm = get_task_mm(current);
>>> +			if (!mm)
>>> +				return error;
>>> +
>>> +			down_read(&mm->mmap_sem);
>>> +			vma = find_vma(mm, arg3);
>>> +			if (!vma)
>>> +				goto out;
>>
>> arg3 needs to be significantly more carefully validated. find_vma() doesn't
>> say that vm_start<= addr, only that vm_end>  addr. This effectively
>> bypasses all the vma checks (mmap_min_addr, max process size, etc), with
>> some pretty crazy side-effects, I think.
>>
>
> Yes, I know it needs some more testing, but apart from vma bounds (yup,
> good point with find_vma, I'll fix) I thought about what else should be
> checked? I think VMA prototype should be checked to fit "code", "data"
> templates, ie code should be at least readable and execytable, but what
> about data and stack and brk, should stack be executable? That is the
> point where I've got a bit confused and though putting RFC out might be
> a good idea to collect opinions.

My memory is a bit hazy here, but cryo 
(http://git.sr71.net/?p=cryo-forhallyn.git;a=summary) did also do this 
from userspace.  As I recall the one problem we had was ... that we 
couldn't lower the mm_start of the first segment?  I think.  But I bring 
it up only because the advantage of doing it this way was that all of 
the ptrace protections automatically applied.

-serge

  parent reply	other threads:[~2011-11-29 20:49 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-29 19:12 [rfc 0/3] A small bundle in a sake of checkpoint/restore Cyrill Gorcunov
2011-11-29 19:12 ` [rfc 1/3] fs, proc: Add start_data, end_data, start_brk members to /proc/$pid/stat Cyrill Gorcunov
2011-11-29 20:06   ` Kees Cook
2011-12-02  0:24     ` Alexey Dobriyan
2011-12-02  7:28       ` Cyrill Gorcunov
2011-12-02 19:23         ` Kees Cook
2011-12-02 19:28           ` Cyrill Gorcunov
2011-11-29 20:32   ` Serge Hallyn
2011-11-30  5:04   ` KAMEZAWA Hiroyuki
2011-11-29 19:12 ` [rfc 2/3] fs, proc: Introduce the Children: line in /proc/<pid>/status Cyrill Gorcunov
2011-11-30  5:00   ` KAMEZAWA Hiroyuki
2011-11-30  6:05     ` Cyrill Gorcunov
2011-12-01  9:54       ` Cyrill Gorcunov
2011-12-01 15:43         ` Tejun Heo
2011-12-01 15:53           ` Cyrill Gorcunov
2011-12-01 16:07             ` Tejun Heo
2011-12-01 21:29         ` Andrew Morton
2011-12-01 21:38           ` Cyrill Gorcunov
2011-12-02  0:40         ` KAMEZAWA Hiroyuki
2011-12-02 12:41           ` Pedro Alves
2011-12-02 12:43             ` Pavel Emelyanov
2011-12-02 12:45               ` Cyrill Gorcunov
2011-12-02 13:10                 ` Pedro Alves
2011-12-02 13:40                   ` Pedro Alves
2011-12-02 12:58               ` Pedro Alves
2011-12-02 13:16                 ` Pavel Emelyanov
2011-12-02 13:44                   ` Pedro Alves
2011-12-02 13:52                     ` Pavel Emelyanov
2011-12-02 14:00                       ` Pedro Alves
2011-12-02 14:17                         ` Pavel Emelyanov
2011-12-02 14:25                           ` Pedro Alves
2011-12-02 14:37                             ` Pavel Emelyanov
2011-12-02 14:45                               ` Pedro Alves
2011-11-29 19:12 ` [rfc 3/3] prctl: Add PR_SET_MM codes to tune up mm_struct entires Cyrill Gorcunov
2011-11-29 20:19   ` Kees Cook
2011-11-29 20:29     ` Cyrill Gorcunov
2011-11-29 20:37       ` Cyrill Gorcunov
2011-11-29 20:40         ` Kees Cook
2011-11-29 20:47           ` Cyrill Gorcunov
2011-11-30 17:37           ` Cyrill Gorcunov
2011-11-30 18:10             ` Kees Cook
2011-11-30 18:23               ` Cyrill Gorcunov
2011-11-30 21:06                 ` Cyrill Gorcunov
2011-12-07 12:27                   ` Cyrill Gorcunov
2011-12-07 22:43                     ` Andrew Morton
2011-12-08  7:07                       ` Cyrill Gorcunov
2011-12-08  7:15                         ` Andrew Morton
2011-12-08  7:30                           ` Cyrill Gorcunov
2011-11-29 20:37       ` Kees Cook
2011-11-29 20:49       ` Serge Hallyn [this message]
2011-11-29 20:55         ` Cyrill Gorcunov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4ED54547.5060905@canonical.com \
    --to=serge.hallyn@canonical.com \
    --cc=akpm@linux-foundation.org \
    --cc=avagin@openvz.org \
    --cc=gorcunov@gmail.com \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=segoon@openwall.com \
    --cc=tj@kernel.org \
    --cc=xemul@parallels.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.