netdev - Re: [PATCH] netfilter: xt_condition: add security capability support

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 24 Aug 2010 09:32:35 +0200 (CEST)
From:	Jan Engelhardt <jengelh@...ozas.de>
To:	Luciano Coelho <luciano.coelho@...ia.com>
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 Tuesday 2010-08-24 09:00, Luciano Coelho wrote:
>>
>>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/.
>
>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).
>[..] 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.

Indeed so. But you did not invent any new interface. You are reusing
files, which can be protected by DAC modes, or LSMs doing
funky-stuff. xt_{condition,recent,..} already implement file modes,
but does it check for it? Well no, because fs/namei.c does it for
them. As for LSMs, well, I hope they do cater for testing for
capability bits.

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

Certainly not. An administrator may create a condition rule and thus
procfs entry, but the rule may be sufficiently safe and/or integrated
that a subordinate may be given permission to control things in a
limited fashion on a per-need basis. One I use personally is

	-A FORWARD -m condition --condition windows -s
	192.168.100.0/25 -i eth1 -o eth0 -j ACCEPT
	-P FORWARD DROP

	chown jengelh /proc/net/nf_condition/windows;

The presence of such rule would indicate that the administrator
generally allows Windows machines out; but personal paranoia defaults
to rejecting that unless explicitly enabled. (Gives the reassurance
that they won't succeed talking home unless Internet connectivity is
explicitly needed by the user.)
--
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