Re: [PATCH 0/3] elf: load the main program from AT_EXECFD

[Christian Brauner]

> > At first I was very confused about this proposal but I think I
> > understand what you are after now. Your point is that we shouldn't just
> > fix argv like in my proposal but actually even fix the exe file and
> > remap.
> 
> Not sure about remap.  But I think to turn this into an it-just-works
> solution, we need to fix /proc/self/exe and the auxiliary vector.

Yes.

> 
> > So I think doing this purely in userspace isn't doable. The restore
> > parts can fix everything except the exe link. PR_SET_MM_MAP requires
> > capabilities in the relevant user namespace for the exe file. That makes
> > it pretty useless for us. And dropping that capability requirement isn't
> > feasible, I think. LSMs and audit trust the exe link, so an uncapped
> > exe file would let any process masquerade as an arbitrary executable.
> 
> Is the latter really a problem?

I remember that I spoke out against this about 5 years ago when I merged
CAP_CHECKPOINT_RESTORE. I think changing it is something we can try but
it would take a while.

Extending binfmt_misc to do it as an option when registering a binfmt
handler is way easier imho (and simpler).

> > Everything else (the entire saved auxv, the start/end_code/data, brk and
> > stack markers) is validated but requires no capability at all. So an
> > unprivileged ld.so can already repair /proc/<pid>/auxv and the
> > stat/statm code accounting, but never /proc/self/exe.
> 
> It's good for us if AT_SECURE does not need protecting.  We would like
> to use a fake 1 value in our test suite.
> 
> > Unmapping the first copy is also not really feasible. Even with
> > privilege making this work would be very ugly: The kernel's
> > replace_mm_exe_file() refuses with -EBUSY while any vma still maps the
> > old exe file. From my research, CRIU works around exactly this by
> > copying its restorer blob into an anonymous mapping before it unmaps the
> > old address space.
> 
> Unmapping the first copy was only my idea to make this work with the
> existing kernel facilities.  It's not required for the binfmt_misc case
> and most /usr/bin/ld.so scenarios, and actually drives up complexity
> considerably.

I mean, it is kinda moving into CRIU territory, so yes, doing it like
that will be complex. :)

> > So I think the exe link should be fixed up at exec time.
> > begin_new_exec() sets mm->exe_file to bprm->file which after the
> > binfmt_misc handoff is the interpreter. But bprm->executable is the file
> > the kernel access-checked and kept open for AT_EXECFD. We have it right
> > there. This is the file that would_dump() uses for it's decision and
> > binfmt_misc's 'C' flag derive credentials from.
> >
> > We simply need an extension to binfmt_misc that sets mm->exe_file to
> > bprm->executable. Then it is correct from the start and there's no
> > window and no privilege question and existing 'O'/'C' users (qemu-user
> > registrations) are unaffected. It then raises AT_FLAGS_PRESERVE_ARGV.
> >
> > On the userspace side, ld.so now sees this AT_* flag and in response
> > issues one uncapped PR_SET_MM_MAP (that's available completely
> > unprivileged) to retarget AT_PHDR/AT_ENTRY/AT_BASE and drop the stale
> > AT_EXECFD from saved_auxv.
> >
> > With both in place, attaching gdb to a dispatched process is fully
> > correct and /proc/self/exe-based self-location works. As a bonus the
> > program file gets the same exe_file write-denial a directly executed
> > binary has. Today it is ld.so that gets pinned and the running program's
> > file stays writable while its text is mapped.
> >
> > After this, only uninteresting differences should be left. This would be
> > a follow-up series I'm happy to do. Does that sound reasonable?
> 
> The proposal looks quite straightforward.  It's a shame that it does not

Ok, I'll work on that once the basic AT_EXECFD stuff is done.

> fix the /usr/bin/ld.so case.  Is there anything we can do to address

You mean the case where it's called in userspace. Yeah, that's a bit
more tricky.

> that?
> 
> I wouldn't mind if we had a system call that triggered the kernel ELF
> loader for the main executable.

Ok, certainly another future patch series to consider. Fwiw, if you have
some far out ideas like that (kernel related) you should always feel
free to just file an issue or a pull request at:

https://github.com/uapi-group/kernel-features/

They appear on this website:

https://uapi-group.org/kernel-features/

and we have multiple people (not just me) that regularly pick items from
this list and implement them. This is a good way to avoid ideas just
being forgotten or invisible.