Using fexecve to protect the entrypoint of the container

[lifubang]

In https://man7.org/linux/man-pages/man3/fexecve.3.html:

   The idea behind fexecve() is to allow the caller to verify
   (checksum) the contents of an executable before executing it.
   Simply opening the file, checksumming the contents, and then
   doing an execve(2) would not suffice, since, between the two
   steps, the filename, or a directory prefix of the pathname, could
   have been exchanged (by, for example, modifying the target of a
   symbolic link).  fexecve() does not mitigate the problem that the
   contents of a file could be changed between the checksumming and
   the call to fexecve(); for that, the solution is to ensure that
   the permissions on the file prevent it from being modified by
   malicious users.

and:

   If fd refers to a script (i.e., it is an executable text file
   that names a script interpreter with a first line that begins
   with the characters #!)  and the close-on-exec flag has been set
   for fd, then fexecve() fails with the error ENOENT.  This error
   occurs because, by the time the script interpreter is executed,
   fd has already been closed because of the close-on-exec flag.
   Thus, the close-on-exec flag can't be set on fd if it refers to a
   script, leading to the problems described in NOTES.

So, if the type entrypoint of container if a binary format, we can open it as a fd with close-on-exec flag and use execveat(like fexecve) to
start/exec the container process, if a malicious process modify the entrypoint to a Shebang script, execveat will return ENOENT.

So, let's check the original entrypoint of the container, if it is a Shebang script, solve it to get the final real binary file, and check whether it is in the container or not. After we open it as a fd with close-on-exec flag, the malicious process can only modify the final real binary's content, but can't change it to a symbol link. So maybe we can use it to defeat CVE-2019-5736.