public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Cyrill Gorcunov <gorcunov@gmail.com>
To: Kees Cook <keescook@chromium.org>
Cc: linux-kernel@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>,
	Tejun Heo <tj@kernel.org>, Andrew Vagin <avagin@openvz.org>,
	Serge Hallyn <serge.hallyn@canonical.com>,
	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: Wed, 30 Nov 2011 22:23:10 +0400	[thread overview]
Message-ID: <20111130182310.GL14515@moon> (raw)
In-Reply-To: <CAGXu5jL=46_MyxrrB8G4FntnLJBtt+DbvVX0kEXh9n8Ss+Yfsw@mail.gmail.com>

On Wed, Nov 30, 2011 at 10:10:35AM -0800, Kees Cook wrote:
...
> >
> > Hi Kees,
> >
> > what about this one? Note that these mm_struct members don't affect
> > kernel much (at least as far as I see, except maybe brk,start_brk and
> > start_stack values), so I've added some sanity checks here, hope they
> > would fit. Still main protection is root-only access only. The kernel
> > itself uses vma_area::start/end members for overlows tests internally
> > so I think even passing crazy data here won't crash the kernel itself.
> 
> Right, though besides just crashing the kernel, I'm trying to look at
> this from the perspective of a paranoid admin that doesn't even trust
> the root user. Is there some way this new interface could be used to
> provide the building blocks for gaining kernel execute control?
> (Imagine a system running with modules disabled, STRICT_DEVMEM
>  enabled, etc.)
> 

Well, I don't see a way to use it for gaining some control execution at the
moment but (!) kernel evolves and I fear one might forget about this new
interface when he will be doing some tossing over this mm_struct members.

I though about adding some kind of mark to kernel log on first usage of
this prctl codes (so if some crash happened for any reason, the log would
point someone used this interface).

> > What do you think?
> 
> This looks way better, yes. I have this feeling like these validations
> should be more centralized or tied to the mm code more directly to
> avoid drift, but I don't have any constructive suggestions
> unfortunately. Maybe other folks do?
> 

Yeah, good point, but on the other hands have these tests in one place
is easier to read I think.

> > +       switch (opt) {
> > +       case PR_SET_MM_START_CODE:
> > +       case PR_SET_MM_END_CODE:
> > +
> > +               vm_req_flags = VM_READ | VM_EXEC;
> > +               vm_bad_flags = VM_WRITE | VM_MAYSHARE;
> > +
> > +               if ((vma->vm_flags & vm_req_flags) != vm_req_flags ||
> > +                   (vma->vm_flags & vm_bad_flags))
> > +                       goto out;
> 
> Another random thought: given this very regular set of checks you're
> doing, perhaps the flags should be part of a data structure instead,
> just to reduce the size of this routine?
> 
> struct mm_flags {
>   int req_flags;
>   int bad_flags;
> };
> 
> struct mm_flags opt_flags[] = {
> ...
>  { VM_READ | VM_EXEC, VM_WRITE | VM_MAYSHARE }, /* PR_SET_MM_START_CODE */
>  { VM_READ | VM_EXEC, VM_WRITE | VM_MAYSHARE }, /* PR_SET_MM_END_CODE */
> ...
> 
> then do validation before the switch statement all in one place, and
> leave the switch for more programmatic checks?
> 
> -Kees
> 

Nod! I'll update, thanks!

	Cyrill

  reply	other threads:[~2011-11-30 18:23 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 [this message]
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
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=20111130182310.GL14515@moon \
    --to=gorcunov@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=avagin@openvz.org \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=segoon@openwall.com \
    --cc=serge.hallyn@canonical.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox