From: Luciano Coelho <luciano.coelho@nokia.com>
To: ext Jan Engelhardt <jengelh@medozas.de>
Cc: ext Changli Gao <xiaosuo@gmail.com>,
"kaber@trash.net" <kaber@trash.net>,
"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: Tue, 24 Aug 2010 10:00:20 +0300 [thread overview]
Message-ID: <1282633220.7198.123.camel@powerslave> (raw)
In-Reply-To: <alpine.LNX.2.01.1008232052170.31619@obet.zrqbmnf.qr>
On Mon, 2010-08-23 at 20:58 +0200, ext Jan Engelhardt wrote:
> On Monday 2010-08-23 20:45, Luciano Coelho wrote:
> >> But it looks as strange as the Yama code attempt.
> >
> >What is so strange about it? Is it because it's possible to set the
> >capability requirement from modprobe arguments? The capability check
> >already exists in at least in nfnetlink, where it checks for received
> >messages for the CAP_NET_ADMIN capability. Is it strange because we're
> >checking for the capability when someone tries to write to a file?
>
> It is strange that you check this capability from a module focused on
> packet handling. For lack of a better example, it's as if you tried
> to check the uid of the file, the latter of which is better left to
> the routines in fs/.
Okay, thanks for the explanation! I'll have to figure something else out
then.
What I don't understand is that I see lots of components, which have
nothing to do with security, making this kind of checks. Most of them
(if not all) are checking for input from userspace where they provide
their own interfaces (eg. ioctl calls, netlink messages).
I can see that ip_tables checks for this capability when it gets "set"
socket calls. Now, with the xt_condition, we're opening a new route
from userspace to the kernel and I think it might be a good idea to
protect that too.
It's kind of useless to protect someone without CAP_NET_ADMIN from
creating a condition rule if it is possible to change the condition from
userspace without any capability protection.
> >> This is the one time
> >> where I would personally be looking into SELinux, or perhaps SMACK if
> >> the former is too complex, to whether _t'ing off procfs is possible.
> >
> >Yeah, but it's not up to me to decide this. We have one entire team
> >dedicated to figuring out how to ensure "security" in our device. It
> >was that team who advised us to protect this file by checking for
> >CAP_NET_ADMIN.
>
> You can do whatever you want with your product. I am just saying this
> does not look like kernel material, and I suppose it won't go well
> with the maintainers up the chain either.
Yeah, my company can do whatever they want with the product. But my
role here is to work with upstream, so if you guys think that what I'm
doing is total bulls*it, I'll have to go back to the drawing board and
restart my work ;)
Again, I must stress that I really appreciate your comments and help. I
know I can get good advice from people who are millions of times more
experienced in this area than I am (and yes, that's *you* ;) -- and this
is one of the various reasons I send my patches to netfilter-devel in
the first place. Another reason is that I want to contribute my work
(however shitty it is) to an eventual benefit for the community as a
whole. :)
--
Cheers,
Luca.
next prev parent reply other threads:[~2010-08-24 7:00 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 [this message]
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
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=1282633220.7198.123.camel@powerslave \
--to=luciano.coelho@nokia.com \
--cc=jengelh@medozas.de \
--cc=jmorris@namei.org \
--cc=kaber@trash.net \
--cc=linux-security-module@vger.kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).