Hi Ingo, On Fri, Jul 01, 2011 at 15:07 +0200, Ingo Molnar wrote: > Have you addressed my basic objection of why we should go for a more > complex and less capable variant over a shared yet more capable > facility: > > http://lkml.kernel.org/r/20110526091518.GE26775@xxxxxxx > > ? > > You are pushing the 'filter engine' approach currently, not the > (much) more unified 'event filters' approach. I'm sorry if my question was already addressed - I wasn't CC'ed to the first series of the patch, I read some emails from lkml.org, so I might miss something. You're proposing the more generic solution than a more limited syscalls filtering thing. AFAIU, you're trying to merge different security models like syscalls filtering, defining object policies, hardening, etc. This would be a something like a generic framework, which will be used by specific models like syscalls filtering: http://marc.info/?l=linux-kernel&m=130639834930092&w=2 I'm worried about one thing, one of important properties of all *generic* things: what disadvantages would this framework have? The generic filtering engine might be: 1) Too slow if it can filter everything and supersets almost every policy. 2) Too compicated in sense it exposes too much attack surface. The latest patch is rather simple to audit, but generic filters, as every generic thing, is hard to properly audit. Will mentioned that tracepoints code is currently a bit complicated for this sort of things. It is a subjective point, but anyway. 3) Too complicated in sense of API/usage. E.g. current SELinux policies is too hard to configure properly for most of users, plenty of users just use the predefined policies coming with distributions. Would be the "superset" more complicated? 4) Not "generic" enough. Some awfully cool new security model invented in 5 years will need some thing that cannot be added to the current model without changing ABI or will need the full framework refactoring. This would lead to reimplementing some already existing filters, but in sense of this model desires. (I don't claim that event filtering will end with these issues, surely no, I'm merely asking about possible problems.) On the contrary, the syscalls sandboxing clearly has potential users like QEMU and daemons with privilege separation architecture, similar (but more weak) model with namespaces separation is proven to work just well. The set of users is more or less understandable. The unprivileged process has a clearly defined set of permitted operations, which can be enforced by syscalls inhibitions. The code is simple enough to audit. Yes, this model has a limited set of users, but - hey! - every security model with the same mission will be used only by restricted set of users. Another perhaps naive question - how long should it take to bring the event filtering code to the state when it is aleady useful at leasy for the complete syscalls filtering? (Will posted a list of issues that were not addressed in his PoC because of proper API lacking.) Wouldn't the time frame be too large to spawn numerous users of not yet complete solution, leading to the stalling with incomplete/nonscalabe ABI, which would be worse than any particular speciality models? Please don't take my words as an attack to your model, but an attempt to clarify dark spots, which might be a real barrier of your mutual understanding. Thanks, -- Vasiliy Kulikov http://www.openwall.com - bringing security into open computing environments -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
