On Wed, Mar 23, 2016 at 6:46 PM, Mickaël Salaün <mic@xxxxxxxxxxx> wrote: > Hi, > > This series is a proof of concept (not ready for production) to extend seccomp > with the ability to check argument pointers of syscalls as kernel object (e.g. > file path). This add a needed feature to create a full sandbox managed by > userland like the Seatbelt/XNU Sandbox or the OpenBSD Pledge. It was initially > inspired from a partial seccomp-LSM prototype [1] but has evolved a lot since :) > > The audience for this RFC is limited to security-related actors to discuss > about this new feature before enlarging the scope to a wider audience. This > aims to focus on the security goal, usability and architecture before entering > into the gory details of each subsystem. I also wish to get constructive > criticisms about the userland API and intrusiveness of the code (and what could > be the other ways to do it better) before going further (and addressing the > TODO and FIXME in the code). > > The approach taken is to add the minimum amount of code while still allowing > the userland to create access rules via seccomp. The current limitation of > seccomp is to get raw syscall arguments value but there is no way to > dereference a pointer to check its content (e.g. the first argument of the open > syscall). This seccomp evolution brings a generic way to check against argument > pointer regardless from the syscall unlike current LSMs. Okay, I've read through this whole series now (sorry for the huge delay). I think that it is overly complex for what it results in providing. Here are some background thoughts I had: 1) People have asked for "dereferenced argument inspection" (I will call this DAI...), in that they would like to be able to process arguments like how BPF traditionally processes packets. This series doesn't provide that. Rather, it provides static checks against specific arguments types (currently just path checks). 2) When I dig into the requirements people have around DAI, it's mostly about checking path names. There is some interest in some of the network structures, but mostly it's path names. This series certainly underscores this since your first example is path names. :) 3) Solving ToCToU should also solve performance problems. For example, this series, on a successful syscall, will look up a pathname twice (once in seccomp, then again in the syscall, and then compares the results in the LSM as a ToCToU back-stop). This seems like a waste of effort, since this reimplements the work the kernel is already doing to pass the resulting structure to the LSM hooks. As such, since this series is doing static checks and not allowing byte processing for DAI, I'm convinced that it should entirely happen in the LSM hooks. 4) Performing the checks in the LSM hooks carries a risk of exposing the syscall's argument processing code to an attacker, but I think that is okay since very similar code would already need to be written to do the same thing before entering the syscall. The only way out of this, I think, would be to standardize syscall argument processing. 5) If we can standardize syscall argument processing, we could also change when it happens, and retain the results for the syscall, allowing for full byte processing style of DAI. e.g. copy userspace to kernel space, do BPF on the argument, if okay, pass the kernel copy to the syscall where it continues the processing. If the kernel copy wasn't already created by seccomp, the syscall would just make that copy itself, etc. So, I see DAI as going one of two ways: a) rewrite all syscall entry to use a common cacheable argument parser and offering true BPF processing of the argument bytes. b) use the existing LSM hooks and define a policy language that can be loaded ahead of time. Doing "a" has many problems, I think. Not the least of which is that I can't imagine a way for such an architectural change to not have negative performance impacts for the regular case. Doing "b" means writing a policy engine. I would expect it to look a lot like either AppArmor or TOMOYO. TOMOYO has network structure processing, so probably it would look more like TOMOYO if you wanted more than just file paths. Maybe a seccomp LSM could share logic from one of the existing path-based LSMs. Another note I had for this series was that because the checker tries to keep a cached struct path, it allows unprivileged users to check for path names existing or not, regardless of the user's permissions. Instead, you have to check the path against the policy each time. AppArmor does this efficiently with a pre-built deterministic finite automatons (built from regular expressions), and TOMOYO just does string compares and limited glob parsing every time. So, I can't take this as-is, but I'll take the one fix near the start. :) I hope this isn't too discouraging, since I'd love to see this solved. Hopefully you can keep chipping away at it! Thanks! -Kees -- Kees Cook Chrome OS & Brillo Security -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
