Alex is right, i promise you if it made sense to do seccomp-bpf like things for Windows we would have done it by now. Windows is a different beast entirely. Hyper-v/WDAG containers are the best way we currently have to abstract away attack kernel surface.https://twitter.com/aionescu/status/1092263015699730437 …
-
Show this thread
-
The real question is when are we going to give HV containers to app developers and when can we get enough density and perf. I believe in
@mamyun ;)1 reply 0 retweets 8 likesShow this thread -
Replying to @dwizzzleMSFT @mamyun
I don't see why it couldn't work, seccomp-bpf doesn't require you to be a libc developer. I think HV containers solve a different problem.
2 replies 0 retweets 2 likes -
Replying to @taviso @dwizzzleMSFT
NT/win32k syscalls are more or less abstracted from the public API. So, exposing syscall filtering at that level would be fragile as we update Windows and as apps evolve. It needs to be exposed at a higher level. We're investigating...
2 replies 0 retweets 1 like -
It’s worse than that. You have NtUserMessageCall and the like which have dozens or hundreds of sub functions based on message type. Many APIs generate implicit messages. Blocking at the entry point level is way to coarse to get comparable security value to seccomp
1 reply 0 retweets 2 likes -
Replying to @dwizzzleMSFT @mamyun
That's just plain not true Dave, it sounds like you think seccomp-bpf is just filtering based on syscall number. The "bpf" part means that there is a little turing complete program that can examine parameters, such as class or message type, and decide an action.
4 replies 1 retweet 8 likes -
I've very familiar with seccomp-bpf and what it can do :) My point is finding the APIs is hard enough, but not close to sufficient. I think total cost/work involved for developers to build an effective filter on windows is massive
2 replies 0 retweets 3 likes -
Agree with this. It is microsofts biggest security failing imo. You need like a PhD in windows to write a half decent sandbox. Knowledge of SDs, low integrity, low box, jobs, desktops, sessions, and semi or undocumented process flags
2 replies 0 retweets 3 likes -
Yeah 100% agree it’s not good enough. I own the sandbox now and a better/real public api is at the top of the list
2 replies 0 retweets 1 like -
The Apple api is sort of exactly what developers need imo. A XML (or similar) description of what resources you want to access and with what access. Makes it easy for developers and also appsec reviewers
3 replies 0 retweets 6 likes
Yeah, agreed. It would be nice if you could use a syscall filtering API directly if desired, with a higher level declarative API available.
-
-
Apple's model is nice, but they have the same problem as everyone else of granting excessive ambient permissions—even in a fully locked down sandbox. That's why we had to build our macOS bootstrap sandbox for Chrome.
0 replies 1 retweet 1 likeThanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
Yeah. For most people I imagine the syscall filtering route is too much of a mess on windows. I think declarative system would be pretty good
0 replies 0 retweets 1 likeThanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.