Re: [Ksummit-discuss] security-related TODO items?

[Andy Lutomirski <luto@amacapital.net>]

On Mon, Jan 23, 2017 at 2:48 AM, David Howells <dhowells@redhat.com> wrote:
> Andy Lutomirski <luto@amacapital.net> wrote:
>
>> This is not easy at all, but: how about rewriting execve() so that the
>> actual binary format parsers run in user mode?
>
> Sounds very chicken-and-egg-ish.  Issues you'd have:
>
>  (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.

>
>  (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.

>
>  (3) How do you deal with address randomisation?

Non-issue, I think.

>
>  (4) You may have to start without a stack as the kernel wouldn't necessarily
>      know where to put it or how big it should be (see 6).  Or you might have
>      to relocate it, including all the pointers it contains.

The relocation part is indeed a bit nasty.

>
>  (5) Where should the kernel put arguments, environment and other parameters?
>      Currently, this presumes a stack, but see (4).

Hmm.

>
>  (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.

>
>  (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.

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

>
>> A minor one for x86: give binaries a way to opt out of the x86_64
>> vsyscall page.  I already did the hard part (in a branch), so all
>> that's really left is figuring out the ABI.
>
> munmap() it in the loader?

Hmm, *that's* an interesting thought.  You can't remove the VMA (it's
not a VMA) but maybe munmap() could be made to work anyway.  Hey mm
folks, just how weird would it be to let arch code special-case
unmapping of the gate pseudo-vma?

--Andy