lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 15 Sep 2010 22:14:39 +0200 From: Patrick McHardy <kaber@...sh.net> To: Luciano Coelho <luciano.coelho@...ia.com> CC: ext Jan Engelhardt <jengelh@...ozas.de>, M�kel� Juhani <ext-juhani.3.makela@...ia.com>, ext Changli Gao <xiaosuo@...il.com>, "netfilter-devel@...r.kernel.org" <netfilter-devel@...r.kernel.org>, "netdev@...r.kernel.org" <netdev@...r.kernel.org>, James Morris <jmorris@...ei.org>, "linux-security-module@...r.kernel.org" <linux-security-module@...r.kernel.org> Subject: Re: [PATCH] netfilter: xt_condition: add security capability support 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. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists