[OE-core] pseudo: host user contamination

[Victor Kamensky]

On Sat, 24 Mar 2018, Andre McCurdy wrote:

> On Sat, Mar 24, 2018 at 5:09 PM, Victor Kamensky <kamensky at cisco.com> wrote:
>> On Sat, 24 Mar 2018, Burton, Ross wrote:
>>> On 24 March 2018 at 20:12, Victor Kamensky <kamensky at cisco.com> wrote:
>>>>
>>>> Here is another crazy idea how to deal with it, just
>>>> brainstorming what options are on the table: disable
>>>> renameat2 with help of seccomp and force coreutils to
>>>> use other calls. Something along the lines that were
>>>> suggested with intercept of syscall function call, but
>>>> let kernel to do interception work.
>>>
>>> Wow, that's impressively magic.  Does this depend on kernel options or
>>> specific recent versions?
>
> Yeah, it's impressive but perhaps overkill for this situation.
>
> Having the kernel run a BPF script on every syscall is going to have a
> much bigger performance impact than intercepting one specific libc
> function in user space.

I don't think we should worry about overhead in pseudo case.

> Also, AFAIK, seccomp can't be nested - so building within an
> environment which has already been secured with seccomp (e.g. recent
> versions of docker?) might be a problem if pseudo starts to rely on
> seccomp too.

Above is true. It was on my mind.

Note I have no problem whatsoever if you can intercept syscall
function correctly. Function intercepting way is definitely more
aligned with what pseudo does. I was just listing other
possible options.

But please note syscall function takes a
variable number of arguments and call another variable
number of argument function, real syscall implementation, in
general, cannot be done. One would need to have complimentary
vsyscall function taking va_list. I.e like printf and vprintf.

Please see http://c-faq.com/varargs/handoff.html

But maybe something special can be done for syscall case.
Disclaimer: I did not read full thread, maybe you already
discussed this.

Thanks,
Victor