linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: David Howells <dhowells@redhat.com>
To: Andy Lutomirski <luto@amacapital.net>
Cc: dhowells@redhat.com, "linux-mm@kvack.org" <linux-mm@kvack.org>,
	Kees Cook <keescook@chromium.org>,
	Josh Armour <jarmour@google.com>,
	Greg KH <gregkh@linuxfoundation.org>,
	"ksummit-discuss@lists.linuxfoundation.org"
	<ksummit-discuss@lists.linuxfoundation.org>
Subject: Re: [Ksummit-discuss] security-related TODO items?
Date: Mon, 23 Jan 2017 20:36:28 +0000	[thread overview]
Message-ID: <5024.1485203788@warthog.procyon.org.uk> (raw)
In-Reply-To: <CALCETrV5b4Z3MF51pQOPtp-BgMM4TYPLrXPHL+EfsWfm+CczkA@mail.gmail.com>

Andy Lutomirski <luto@amacapital.net> wrote:

> >  (1) You'd need at least one pre-loader binary image built into the kernel
> >      that you can map into userspace (you can't upcall to userspace to go get
> >      it for your core binfmt).  This could appear as, say, /proc/preloader,
> >      for the kernel to open and mmap.
> 
> No need for it to be visible at all.  I'm imagining the kernel making
> a fresh mm_struct, directly mapping some text, running that text, and
> then using the result as the mm_struct after execve.

What would you see in /proc/pid/maps?

> >  (2) Where would the kernel put the executable image?  It would have to
> >      parse the binary to find out where not to put it - otherwise the code
> >      might have to relocate itself.
> 
> In vmlinux.

You misunderstood the question.  I meant at what address would you map it into
userspace?  You would have to avoid anywhere the executable needs to place
something - though as long as you can manage to start the loader, you can
ditch the pre-loader, so that might not be a problem.

> >  (6) NOMMU could be particularly tricky.  For ELF-FDPIC at least, the stack
> >      size is set in the binary.  OTOH, you wouldn't have to relocate the
> >      pre-loader - you'd just mmap it MAP_PRIVATE and execute in place.
> 
> For nommu, forget about it.

Why?  If you do that, you have to have bimodal binfmts.  Note that the
ELF-FDPIC binfmt, at least, can be used for both MMU and NOMMU environments.
This may also be true of FLAT.

> >  (7) When the kernel finds it's dealing with a script, it goes back through
> >      the security calculation procedure again to deal with the interpreter.
> 
> The security calculation isn't what I'm worried about.  I'm worried
> about the parser.

But you may have to redo the security calculation *after* doing the parsing.

> Anyway, I didn't say this would be easy :)

True... :-)

David

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  parent reply	other threads:[~2017-01-23 20:36 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAGXu5j+nVMPk3TTxLr3_6Y=5vNM0=aD+13JM_Q5POts9M7kzuw@mail.gmail.com>
     [not found] ` <CALCETrVKDAzcS62wTjDOGuRUNec_a-=8iEa7QQ62V83Ce2nk=A@mail.gmail.com>
     [not found]   ` <31033.1485168526@warthog.procyon.org.uk>
2017-01-23 20:10     ` Andy Lutomirski
2017-01-24 10:32       ` Tetsuo Handa
2017-01-24 20:58         ` Andy Lutomirski
2017-01-23 20:36     ` David Howells [this message]
2017-01-23 20:59       ` Matthew Wilcox
2017-01-23 21:53         ` Andy Lutomirski
2017-01-23 23:26       ` Greg Ungerer

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=5024.1485203788@warthog.procyon.org.uk \
    --to=dhowells@redhat.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jarmour@google.com \
    --cc=keescook@chromium.org \
    --cc=ksummit-discuss@lists.linuxfoundation.org \
    --cc=linux-mm@kvack.org \
    --cc=luto@amacapital.net \
    /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