From: Patrick McHardy <kaber@trash.net>
To: Luciano Coelho <luciano.coelho@nokia.com>
Cc: "ext Jan Engelhardt" <jengelh@medozas.de>,
"M�kel� Juhani" <ext-juhani.3.makela@nokia.com>,
"ext Changli Gao" <xiaosuo@gmail.com>,
"netfilter-devel@vger.kernel.org"
<netfilter-devel@vger.kernel.org>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"James Morris" <jmorris@namei.org>,
"linux-security-module@vger.kernel.org"
<linux-security-module@vger.kernel.org>
Subject: Re: [PATCH] netfilter: xt_condition: add security capability support
Date: Wed, 15 Sep 2010 22:14:39 +0200 [thread overview]
Message-ID: <4C91292F.3090602@trash.net> (raw)
In-Reply-To: <1282895723.2006.135.camel@powerslave>
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.
next prev parent reply other threads:[~2010-09-15 20:14 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-23 12:50 [PATCH] netfilter: xt_condition: add security capability support luciano.coelho
2010-08-23 13:37 ` Changli Gao
2010-08-23 13:42 ` Luciano Coelho
2010-08-23 14:34 ` Jan Engelhardt
2010-08-23 18:45 ` Luciano Coelho
2010-08-23 18:58 ` Jan Engelhardt
2010-08-24 7:00 ` Luciano Coelho
2010-08-24 7:32 ` Jan Engelhardt
2010-08-25 7:09 ` Luciano Coelho
2010-08-25 9:04 ` Jan Engelhardt
2010-08-27 7:55 ` Luciano Coelho
2010-09-15 20:14 ` Patrick McHardy [this message]
2010-09-21 19:56 ` Luciano Coelho
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4C91292F.3090602@trash.net \
--to=kaber@trash.net \
--cc=ext-juhani.3.makela@nokia.com \
--cc=jengelh@medozas.de \
--cc=jmorris@namei.org \
--cc=linux-security-module@vger.kernel.org \
--cc=luciano.coelho@nokia.com \
--cc=netdev@vger.kernel.org \
--cc=netfilter-devel@vger.kernel.org \
--cc=xiaosuo@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.