[Ksummit-discuss] security-related TODO items?
luto at amacapital.net
Mon Jan 23 20:10:41 UTC 2017
On Mon, Jan 23, 2017 at 2:48 AM, David Howells <dhowells at redhat.com> wrote:
> Andy Lutomirski <luto at 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.
> (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).
> (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?
More information about the Ksummit-discuss