On Wed, 2010-09-15 at 22:14 +0200, ext Patrick McHardy wrote: > Am 27.08.2010 09:55, schrieb Luciano Coelho: > > That's what I tried to say when I said that we have a security team > > taking care of this. They are implementing solutions to make the > > product more secure, defending it against malware, misuse, attacks and > > other such things. In this specific case, security-wise, we are trying > > to prevent some bogus or malicious application from changing our > > netfilter rules and causing havoc. > > > > LSM doesn't seem to be an option, here I quote Juhani (my colleague from > > our security team): > > > >> The problem with capabilites is that they are assigned to binaries, not > >> users. Kind of a setuid-mechanism, really. In our embedded environment > >> that makes a lot of sense, but in a server-type environment with > >> multiple users and a competent sysadmin, not so much. In such an > >> environment using a LSM might also actually make sense. But for us it's > >> not an option, mostly because LSMs are not stackable - you can have only > >> one effective at any time - and I'm afraid we have already reserved some > >> of the LSM hooks. > > > > Maybe Juhani can clarify this a bit more. > > > > One other idea that Juhani had was to add an option to the condition > > match/target where the capability requiremets could be set, instead of > > checking them by default. If nothing is specified, everything still > > works as before (no caps checks). Or even a Kconfig option? > > I agree with Jan, adding module parameters to control permission checks > or capabilities seems like a bad precedent. Okay, the idea is now officially dropped. We'll use normal ACL to control access to the conditions. Thanks for your comments and sorry for trying to push ;) -- Cheers, Luca. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
