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 netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
