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.
-
-
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 -
so every app gets a bpf-filtered custom sandbox that would have to be recalculated for every Windows update that touches any syscall sub function?
1 reply 0 retweets 0 likes -
Things are recalculated all the time, just loading a DLL has to recalculate offsets and relocations. I think I don't understand the complaint, the developer writes a policy, everything else can be automated.
1 reply 0 retweets 0 likes -
that sounds very dynamic for a sandbox; does it introduce overhead?
2 replies 0 retweets 0 likes -
Not significantly, miniscule load time overhead and then miniscule syscall overhead. The alternative being pitched here is spinning up a HV container.... now that's overhead
1 reply 0 retweets 0 likes -
doesn't that depend on whether it's a full HV VM for the container or a minimal process with no HV services like LSASS or shared memory and scheduling like the new Sandbox (where the overhead is *installing the whole damn app* every time)
1 reply 0 retweets 0 likes -
Replying to @marypcbuk @taviso and
I'd really like a version of the sandbox that completely isolated an app from Windows so it can't dig its tentacles in but also doesn't have to be installed from scratch every time
1 reply 0 retweets 1 like
Either way, we're talking orders of magnitude more overhead. It's either just many orders of magnitude or many many many orders of magnitude.
-
-
Replying to @taviso @marypcbuk and
I think the problem with the approach is : 1) lack of tooling to generate the metadata reliably 2) risk of things going haywire if done wrong with dependencies 3) with enough dependencies, the tree becomes so large that you lose the filtering, unless your metadata is per-fn
0 replies 0 retweets 0 likesThanks. 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.