From mboxrd@z Thu Jan 1 00:00:00 1970 From: Patrick McHardy Subject: Re: [PATCH] netfilter: xt_condition: add security capability support Date: Wed, 15 Sep 2010 22:14:39 +0200 Message-ID: <4C91292F.3090602@trash.net> References: <1282567801-2673-1-git-send-email-luciano.coelho@nokia.com> <1282570935.7198.5.camel@powerslave> <1282589101.7198.28.camel@powerslave> <1282633220.7198.123.camel@powerslave> <1282720198.18016.72.camel@powerslave> <1282895723.2006.135.camel@powerslave> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: ext Jan Engelhardt , =?UTF-8?B?Te+/vWtlbO+/vSBKdWg=?= =?UTF-8?B?YW5p?= , ext Changli Gao , "netfilter-devel@vger.kernel.org" , "netdev@vger.kernel.org" , James Morris , "linux-security-module@vger.kernel.org" To: Luciano Coelho Return-path: In-Reply-To: <1282895723.2006.135.camel@powerslave> Sender: netdev-owner@vger.kernel.org List-Id: netfilter-devel.vger.kernel.org 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.