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

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

[Andy Lutomirski]

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

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

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

[Tetsuo Handa]

Hello.

Can I read archive of the discussion of this topic from the beginning?
I felt that this topic might be an opportunity of proposing my execute handler
approach.

In TOMOYO LSM (out of tree version), administrator can specify a program
called execute handler which should be executed on behalf of a program
requested by execve(). The specified program performs validation (e.g. whether
argv[]/envp[] are appropriate) and setup (e.g. redirect file handles) before
executing the program requested by execve().

Conceptually execute handler is something like

  #!/bin/sh
  test ... || exit 1
  test ... || exit 1
  test ... || exit 1
  exec ...

which would in practice be implemented using C like
https://osdn.net/projects/tomoyo/scm/svn/blobs/head/tags/ccs-tools/1.8.5p1/usr_lib_ccs/audit-exec-param.c .
It is not difficult to implement the kernel side as well.

Regards.

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

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

[Andy Lutomirski]

On Tue, Jan 24, 2017 at 2:32 AM, Tetsuo Handa
<penguin-kernel@i-love.sakura.ne.jp> wrote:
> Hello.
>
> Can I read archive of the discussion of this topic from the beginning?
> I felt that this topic might be an opportunity of proposing my execute handler
> approach.

It should be in the linux-mm archives.

>
> In TOMOYO LSM (out of tree version), administrator can specify a program
> called execute handler which should be executed on behalf of a program
> requested by execve(). The specified program performs validation (e.g. whether
> argv[]/envp[] are appropriate) and setup (e.g. redirect file handles) before
> executing the program requested by execve().
>
> Conceptually execute handler is something like
>
>   #!/bin/sh
>   test ... || exit 1
>   test ... || exit 1
>   test ... || exit 1
>   exec ...
>
> which would in practice be implemented using C like
> https://osdn.net/projects/tomoyo/scm/svn/blobs/head/tags/ccs-tools/1.8.5p1/usr_lib_ccs/audit-exec-param.c .
> It is not difficult to implement the kernel side as well.
>

The difference is that that last exec means that the kernel is still
exposed to any bugs in its ELF parser.  Moving that to user mode would
reduce the attack surface.

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

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

[David Howells]

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>

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

[Matthew Wilcox]

[-- Attachment #1: Type: text/plain, Size: 2557 bytes --]

Why put it in the user address space? As I said earlier in this thread, we
want the facility to run code from kernel addresses in user mode, limited
to only being able to access its own stack and the user addresses. Of
course it should also be able to make syscalls, like mmap.

On Jan 23, 2017 3:36 PM, "David Howells" <dhowells@redhat.com> wrote:

> 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
> _______________________________________________
> Ksummit-discuss mailing list
> Ksummit-discuss@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
>

[-- Attachment #2: Type: text/html, Size: 3408 bytes --]

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

[Andy Lutomirski]

On Mon, Jan 23, 2017 at 12:59 PM, Matthew Wilcox <willy6545@gmail.com> wrote:
> Why put it in the user address space? As I said earlier in this thread, we
> want the facility to run code from kernel addresses in user mode, limited to
> only being able to access its own stack and the user addresses. Of course it
> should also be able to make syscalls, like mmap.

Would you believe I've already started prototyping this (the
kernel-code-in-user-mode part, not the execve part)?

As a practical matter, though, I think the implementation would be
*much* simpler if code running in user mode sees user addresses.
Otherwise we'd end up with very messy and constrained code on
single-address-space arches like x86 and we might not be able to
implement it at all on split-address-space arches like s390.

That being said, writing a bit of PIC code that parses the ELF file,
finds some unused address space, and relocates itself out of the way
shouldn't be *that* hard.

--Andy

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

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

[Greg Ungerer]

On 24/01/17 06:36, David Howells wrote:
> Andy Lutomirski <luto@amacapital.net> wrote:
[snip]
>>>  (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.

It is true for FLAT as well, they can run on both MMU an noMMU.

Regards
Greg


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