[Ksummit-discuss] security-related TODO items?

[David Howells]

Andy Lutomirski <luto at 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