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@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@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@coreos-lnx2 bpf]$ gcc -o norenameat2 norenameat2.c filterout_renameat2.c [kamensky@coreos-lnx2 bpf]$ mkdir foo
[kamensky@coreos-lnx2 bpf]$ strace -o ./trace.mv.txt -f mv foo bar
[kamensky@coreos-lnx2 bpf]$ grep rename ./trace.mv.txt
2218  renameat2(AT_FDCWD, "foo", AT_FDCWD, "bar", 0) = 0
[kamensky@coreos-lnx2 bpf]$ rm -r -f bar
[kamensky@coreos-lnx2 bpf]$ mkdir foo
[kamensky@coreos-lnx2 bpf]$ strace -o ./trace.norenameat2.mv.txt -f 
./norenameat2 mv foo bar
[kamensky@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@coreos-lnx2 bpf]$

Thanks,
Victor

On Sat, 24 Mar 2018, Seebs wrote:

On Sat, 24 Mar 2018 12:42:45 -0700
Andre McCurdy <[email protected]> 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
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core

--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Reply via email to