LWN: Comments on "Deep argument inspection for seccomp"

Shallow argument inspection for execve

jreiser — Thu, 19 Sep 2019 19:56:26 +0000

It would even be handy if argv[k] could be readily inspected during the LSM processing for execve. Today this is possible but cumbersome using tomoyo_security. Instead, remove_arg_zero() in fs/exec.c could return into a buffer what it removed. The entire argv[] could be restored by remembering and resetting the original string pointer and count before any calls to remove_arg_zero().

Deep argument inspection for seccomp

cyphar — Thu, 19 Sep 2019 12:31:28 +0000

From what I understood, the primary concern of "exposing internals" is that the implementation details of the LSM hook infrastructure might become a user-space ABI (and thus must not be broken). Currently, LSM hooks can be redesigned within the kernel because all of the LSM hook users are also in-kernel. If you allow eBPF programs to be attached as LSM hooks, then you can no longer redesign the API as easily because you will break user-space unless you provide backwards-compatible shims.

And note that Linus recently said he feels that eBPF *tracepoints* are an ABI[1].

[1]: https://lwn.net/Articles/799262/

Deep argument inspection for seccomp

gnoack — Thu, 19 Sep 2019 12:19:40 +0000

The article says that the Landlock approach "exposes LSM internals that the LSM developers are not comfortable exposing."

Which LSM internals are that, which they aren't comfortable exposing? (Sorry, I must have missed the discussion.) Is that a concern for other proposed LSMs as well?

Deep argument inspection for seccomp

gnoack — Thu, 19 Sep 2019 12:16:32 +0000

My understanding was that this was discussed (and dismissed as too difficult) in the two paragraphs in the article starting with "Yet another idea would be to have system calls declare their argument types more completely so that the parsing of the arguments and, if needed, conversion to kernel objects could be done early in the system call path."?

Deep argument inspection for seccomp

Cyberax — Wed, 18 Sep 2019 23:29:05 +0000

Come to think about it, what if there's a generic layer in front of syscalls/ioctls that would copy the arguments from userspace and marshall them into nice eBPF-friendly structures with type information. And then simply route them across the layers.

Some syscalls like clone3() are already doing the right thing, so for them it'd be a trivial wrapper. For other syscalls custom code will have to be written.

This can also be done incrementally. I doubt sandboxes care much about arguments for vm86 syscall, they would just filter it out entirely.

Deep argument inspection for seccomp

cyphar — Wed, 18 Sep 2019 23:06:46 +0000

Not to mention that there are dozens of syscalls that already take structs as arguments, so this definitely isn't a new problem we have to worry about. Calling copy_struct_from_user() on the same buffer twice -- or (heaven forbid) doing get_user() directly -- in a proposed syscall body would definitely result in a NACK from at least a few reviewers.

Deep argument inspection for seccomp

jake — Wed, 18 Sep 2019 22:57:53 +0000

> just in case a future syscall that follows the pattern of clone3 ever looks twice at the same parameter and expects it to stay the same.

system calls copy the user-space arguments before they start using them; after that point, user space can no longer change them (and affect the system call) ... the caching idea would just move that copying earlier in the system-call flow ...

jake

Deep argument inspection for seccomp

iabervon — Wed, 18 Sep 2019 22:52:28 +0000

It seems like this would be a good idea irrespective of seccomp, just in case a future syscall that follows the pattern of clone3 ever looks twice at the same parameter and expects it to stay the same.

Deep argument inspection for seccomp

cyphar — Wed, 18 Sep 2019 22:37:08 +0000

If we go with the "cached" proposal (where we do argument parsing earlier and within seccomp) then the copied struct that was seccomp-filtered will be re-used for the actual syscall body (precisely to avoid the obvious TOCTTOU attacks).

Deep argument inspection for seccomp

k3ninho — Wed, 18 Sep 2019 22:13:34 +0000

If there's a TOCTTOU (time if call to time of use) race, then I'd love to use something like RCU to record "you called with this, it changed on the way" for diagnosis of what *really* was executed vs what the user (and sysadmin-approved system services) thought they caused to happen. There's a security implication to catching intended versus actual activity, right?

K3n.

Deep argument inspection for seccomp

anselm — Wed, 18 Sep 2019 21:16:22 +0000

Foresight? I think Windows NT inherited that idea from VAX/VMS. Remember that, way back when, Microsoft hired the head VMS guy from Digital to work on Windows NT; accordingly, Windows NT, when it was new, had a lot in common with VMS.

Deep argument inspection for seccomp

Cyberax — Wed, 18 Sep 2019 20:24:58 +0000

You seriously start appreciate Windows NT designers who had the foresight to require all IO-requests to be self-contained (with some exceptions for requests dealing with large amounts of data).