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>
next prev 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