seccomp: emulate safe privileged system calls #61
Conversation
Snaipe
force-pushed
the
feature/seccomp-emulation
branch
from
b3e6804
to
157dddc
Compare
Snaipe
force-pushed
the
feature/seccomp-emulation
branch
from
157dddc
to
579c4ae
Compare
Snaipe
force-pushed
the
feature/seccomp-emulation
branch
from
579c4ae
to
ea5e81e
Compare
Snaipe
force-pushed
the
feature/seccomp-emulation
branch
from
ea5e81e
to
82d5c35
Compare
Snaipe
force-pushed
the
feature/seccomp-emulation
branch
from
82d5c35
to
600cef5
Compare
Snaipe
force-pushed
the
feature/seccomp-emulation
branch
from
600cef5
to
01f207f
Compare
| @@ -0,0 +1,35 @@ | |||
| /* THIS FILE WAS GENERATED BY arch/x86/gen-syscall.bash -- DO NOT EDIT */ | |||
There was a problem hiding this comment.
Can we avoid checking this in, given we generate it, and you've gone to the trouble of not needing anything other than bash to do so?
| /* Check again that the process is alive and blocked on the syscall. This | ||
| handles cases where the syscall got interrupted by a signal handler | ||
| and the program state changed before we read the pathname or other | ||
| information from proc. */ |
There was a problem hiding this comment.
What prevents this happening while executing the callback and, more specifically, writing the data back to that process? Are we assuming that writing into that less privileged environment is not an issue?
There was a problem hiding this comment.
As far as I can tell from the seccomp_unotify manual, this shouldn't be a concern. If the system call gets interrupted there's a race regardless of whether we check the cookie: if we check it before we write to /proc/pid/mem, the syscall can still get interrupted after the check but before the write.
This does raise a bit of a pickle that I don't think is solvable with the current seccomp API: if the user program doesn't restart the interrupted syscall automatically, and returns from the function that called stat(), it's possible for the supervisor to write into the stack of that previous function call. I don't think this is very likely to happen, though I could reduce the race window by checking the cookie right before the writes. Still racy, as mentioned, but better than nothing.
| typedef int syscall_handler_func(int, int, struct seccomp_notif *); | ||
|
|
||
| enum { | ||
| SYSCALL_HANDLED, |
| resp->error = rc; | ||
| } else if (rc == SYSCALL_CONTINUE) { | ||
| goto fallthrough; | ||
| } |
There was a problem hiding this comment.
The "HANDLED" case isn't mentioned here, but in the event that the local invocation of the call returns something other than zero, should that be communicated back to the caller? I know for mknod it makes no difference, but say for something like "write", or any other syscall that might return a non-zero value for success, for completeness you probably want to put rc into resp->val, correct?
| }; | ||
|
|
||
| #ifdef BST_SECCOMP_32 | ||
| syscall_handler_func *syscall_table_32[BST_NR_MAX32+1] = { |
There was a problem hiding this comment.
also static? The fact that it's also not const suggests that the intent was to modify it maybe, but I don't see that happening, or see why you would, and the table is pretty big to initialize on the stack for every call to sec_seccomp_dispatch_syscall
| @@ -0,0 +1,130 @@ | |||
| #!/bin/bash | |||
There was a problem hiding this comment.
I'm not sure I love bash as the tool here, but hey, I guess it's better than pulling a templating engine into the bst build!
|
|
||
| char line[4096]; | ||
| while (fgets(line, sizeof (line) - 1, f)) { | ||
| sscanf(line, "Umask:\t%o\n", &out->umask); |
There was a problem hiding this comment.
Pedantry - that assumes that sizeof out->umask/mode_t == sizeof int. It's probably true for anything we'll ever care abut, but consider using the address of a local int, and assigning it to out->umask and using the integer conversions instead.
These commits introduce the use of a seccomp supervisor that emulates for now the mknod and mknodat system calls. The supervisor checks that the user is requesting the creation of safe devices, like /dev/null or /dev/zero, and performs the actual system call in the host user namespace.