12.05.2020 16:14, L3P3 wrote:
> I used auditd to log all executions.
> The commands I catched are these, the first one being the initial one.
> /usr/bin/qemu-x86_64-static /usr/share/code/bin/../code
> /usr/share/code/bin/../resources/app/out/cli.js --verbose
> -> /usr/bin/qemu-x86_64-static /usr/share/code/code --verbose --no-sandbox
> -> /usr/bin/qemu-x86_64-static /usr/share/code/code --type=zygote
> --no-sandbox
Okay.
> These commands are run successfully. Note the --type=zygote thing on
> the last one. Since we get the qemu error that type=gpu-process is not
> supported, it is weird, that type=zygote is properly executed. In the
Nope, your interpretation here is not correct. qemu-user does not interpret
options after the first non-optional argument, this has always been the
case, it stops at /usr/share/code/code and does not look further. This
is unlike most other GNU utilitites who interprets --options after
non-option arguments. For qemu-user the only problem is when the _first_
argument starts with a minus sign, - should it be qemu-user's option or the
executable name?
> console, I can see the same message still:
>> qemu: unknown option 'type=gpu-process'
> So this call was not catched by auditd. I wonder if it can be so
> different from the others... Maybe code is depending on argv[0] being
> code? I do not know how binfmt or qemu-static is dealing with these
> things...
Hmm. Now this is twice interesting.
What you see here in auditd records is what _kernel_ does. Your `code'
executable does NOT see the "/usr/bin/qemu-x86_64-static" prefix, it
sees its argv[0] as "/usr/share/code/code", not ".../qemu-..".
And having also said the above about not interpreting other options,
I can _guess_ that at the problematic execution, argv[0] when your
"code" executes something (or itself) is _missing_, so actual argv[0]
_is_ "--type=gpu-process". If your "code" forgot to set argv[0] with
its own executable name, but the image to execute is specified correctly,
things will be exactly as you see - without qemu it will run your "code"
correctly with argv[0] being "--type=gpu-process", while under qemu, qemu
will try to interpret this as its own option.
I wonder how this program ("code") interprets its own options in this
case.
This is just a guess, but it smells quite realistic. BTW, it's quite
common to forget to specify proper argv[0] for execl()/execlp(), --
since usually one have to double the executable name here, since the
first argument is the image name to execute.
Why it isn't logged by auditd in this case is also quite understandable,
since kernel in the end failed to execute the process. Maybe it should
log unsuccessful attempts too, or maybe it _is_ logging these but into
some other place?
Try to run this code on an actual x86_64 machine and see what is being
logged by auditd.
Thanks,
/mjt
