Deep argument inspection for seccomp

Posted Sep 18, 2019 20:24 UTC (Wed) by Cyberax (✭ supporter ✭, #52523)
Parent article: Deep argument inspection for seccomp

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).

Deep argument inspection for seccomp

Posted Sep 18, 2019 21:16 UTC (Wed) by anselm (subscriber, #2796) [Link]

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

Posted Sep 18, 2019 22:13 UTC (Wed) by k3ninho (subscriber, #50375) [Link] (4 responses)

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

Posted Sep 18, 2019 22:37 UTC (Wed) by cyphar (subscriber, #110703) [Link] (3 responses)

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

Posted Sep 18, 2019 22:52 UTC (Wed) by iabervon (subscriber, #722) [Link] (2 responses)

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

Posted Sep 18, 2019 22:57 UTC (Wed) by jake (editor, #205) [Link] (1 responses)

> 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

Posted Sep 18, 2019 23:06 UTC (Wed) by cyphar (subscriber, #110703) [Link]

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.