Date:	Tue, 24 Aug 2010 10:00:20 +0300
From:	Luciano Coelho <luciano.coelho@...ia.com>
To:	ext Jan Engelhardt <jengelh@...ozas.de>
Cc:	ext Changli Gao <xiaosuo@...il.com>,
	"kaber@...sh.net" <kaber@...sh.net>,
	"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

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.

--
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