On Tuesday 2010-08-24 09:00, Luciano Coelho wrote:

quoted

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