[OE-core] pseudo: host user contamination

[Victor Kamensky]

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.

Here is tiny example based on my todays learning or
seccomp and eBPF, it shows how on my FC27 filtering out
renameat2 forces coreutils mv do use other calls to do the job.

[kamensky at coreos-lnx2 bpf]$ cat filterout_renameat2.c
#include <stddef.h>
#include <linux/unistd.h>
#include <linux/seccomp.h>
#include <linux/filter.h>
#include <sys/prctl.h>
#include <errno.h>

#define syscall_nr (offsetof(struct seccomp_data, nr))

struct sock_filter filterout_renameat2[] = {
     BPF_STMT(BPF_LD+BPF_W+BPF_ABS, syscall_nr),
     BPF_JUMP(BPF_JMP+BPF_JEQ+BPF_K, __NR_renameat2, 0, 1),
     BPF_STMT(BPF_RET+BPF_K, SECCOMP_RET_ERRNO + ENOSYS),
     BPF_STMT(BPF_RET+BPF_K, SECCOMP_RET_ALLOW)
};

struct sock_fprog filterout_renameat2_prog = {
     .len = (unsigned short)(sizeof(filterout_renameat2) /
                             sizeof(filterout_renameat2[0])),
     .filter = filterout_renameat2,
};

int disable_renameat2_syscall (void)
{
     int err;
     err = prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0);
     if (!err) {
         err = prctl(PR_SET_SECCOMP, SECCOMP_MODE_FILTER,
 		    &filterout_renameat2_prog);
     }

     return err;
}
[kamensky at coreos-lnx2 bpf]$ cat norenameat2.c
#include <unistd.h>
#include <stdio.h>

int disable_renameat2_syscall (void);

int main(int argc, char **argv)
{
     int err = 0;

     err = disable_renameat2_syscall();
     if(err) {
         perror("disable_renameat2_syscall");
     }

     execvp (argv[1], &argv[1]);
     return 0;
}
[kamensky at coreos-lnx2 bpf]$ gcc -o norenameat2 norenameat2.c filterout_renameat2.c 
[kamensky at coreos-lnx2 bpf]$ mkdir foo
[kamensky at coreos-lnx2 bpf]$ strace -o ./trace.mv.txt -f mv foo bar
[kamensky at coreos-lnx2 bpf]$ grep rename ./trace.mv.txt
2218  renameat2(AT_FDCWD, "foo", AT_FDCWD, "bar", 0) = 0
[kamensky at coreos-lnx2 bpf]$ rm -r -f bar
[kamensky at coreos-lnx2 bpf]$ mkdir foo
[kamensky at coreos-lnx2 bpf]$ strace -o ./trace.norenameat2.mv.txt -f ./norenameat2 mv foo bar
[kamensky at coreos-lnx2 bpf]$ grep rename ./trace.norenameat2.mv.txt
2228  execve("./norenameat2", ["./norenameat2", "mv", "foo", "bar"], 0x7ffd16d930e0 /* 37 vars */) = 0
2228  renameat2(AT_FDCWD, "foo", AT_FDCWD, "bar", 0) = -1 ENOSYS (Function not implemented)
2228  renameat(AT_FDCWD, "foo", AT_FDCWD, "bar") = 0
[kamensky at coreos-lnx2 bpf]$

Thanks,
Victor

On Sat, 24 Mar 2018, Seebs wrote:

> On Sat, 24 Mar 2018 12:42:45 -0700
> Andre McCurdy <armccurdy at gmail.com> wrote:
>
>> Right. The musl example is to show how it's possible to transparently
>> intercept and pass on any call to the syscall() ABI without
>> interpreting anything.
>
> Yes, if you don't need to interpret things, and aren't making
> additional other unrelated system calls after doing so.
>
>> Those details are all taken care of within the libc implementation of
>> syscall(). It's not something we need to care about at all in a
>> wrapper for it.
>
> I don't think that's correct.
>
> musl's call sequence:
> 	real_syscall() // sets a3
> 	return
>
> pseudo's call sequence:
> 	various_setup()
> 	real_syscall() // sets a3
> 	other system calls // also set a3
> 	return
>
> In the case where pseudo is actually *disabled*, we just return
> right away after the real call. In every other case, we're making
> other calls some of which imply system calls, and those system calls
> could potentially overwrite things that the libc implementation of
> syscall took care of. (Mutex and signal mask operations.)
>
> So for that to work, I would in principle have to stash the value
> stored in, for instance, "a3", wait until after the other system calls,
> and then restore it. Unless *only* syscall() itself actually sets
> that register, and other system calls don't, and nothing else is
> using it either.
>
> -s
> -- 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>