Promptly stated we have the following two problems:
* The --uid-owner and --gid-owner flags may only be specified in the
output chain (as the man page says).
However to block all network traffic for a certain user we do also
need it in the input chain.
Curiously we can log the user who is going to receive a package but
we can not select for this.
* The --gid-owner iptables-rule is apparently ineffective for
http-access (lynx localhost:631).
It is the first rule and would be expected to reject any package
with the specified gid.
Jan Engelhardt & Lars Nooden:
Thxs for your advice.
Using Reject would for sure be the cleaner solution as Drop only lags
for normal app. users and does not help against professional
portscans.
Nonetheless our primary goal here should be to block all network
access for a certain user and only for this user.
The idea is to run programs which do not need network access under the
specified user id (as apache runs under wwwrun).
Richard Horton:
I have connected with lynx to cups (localhost:631).
Lynx does not have the suid-group id bit set so the group should not change.
Lars Nooden & Richard Horton:
As you can see my rule is the first to execute (It is on the right
place but obviously does not work right):
>iptables -L -v
Chain OUTPUT (policy ACCEPT 1 packets, 52 bytes)
pkts bytes target prot opt in out source
destination
8683 506K user_spec all -- any any anywhere
anywhere
0 0 ACCEPT all -- any lo anywhere
anywhere
8682 506K ACCEPT all -- any any anywhere
anywhere state NEW,RELATED,ESTABLISHED
1 52 LOG all -- any any anywhere
anywhere limit: avg 3/min burst 5 LOG level warning
tcp-options ip-options prefix `SFW2-OUT-ERROR '
Chain reject_func (0 references)
pkts bytes target prot opt in out source
destination
0 0 REJECT tcp -- any any anywhere
anywhere reject-with tcp-reset
0 0 REJECT udp -- any any anywhere
anywhere reject-with icmp-port-unreachable
0 0 REJECT all -- any any anywhere
anywhere reject-with icmp-proto-unreachable
Chain user_spec (1 references)
pkts bytes target prot opt in out source
destination
0 0 DROP all -- any any anywhere
anywhere owner GID match app
...
Nonetheless the rule is there and being executed:
> ping localhost
ping: sendmsg: Operation not permitted
ping: sendmsg: Operation not permitted
ping: sendmsg: Operation not permitted
PING localhost (127.0.0.1) 56(84) bytes of data.
--- localhost ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2000ms
2010/7/30 Lars Nooden <lars.curator@xxxxxxxxx>:
> On 07/30/2010 12:00 PM, Jan Engelhardt wrote:
>>
>> Ref: http://marc.info/?l=netfilter&m=128043201731932&w=2
>>
>> On Thursday 2010-07-29 21:33, Lars Nooden wrote:
>>> On 7/29/10 10:09 PM, Elmar Stellnberger wrote:
>>>> iptables -A mychain -m owner --gid-owner blockedusergroup -j DROP
>>>
>>> For starters, consider using the REJECT target instead of DROP if for no other
>>> reason than that it will make your engineering easier:
>>>
>>> http://www.chiark.greenend.org.uk/~peterb/network/drop-vs-reject
>>
>> That page - especially the summary - is leaving out one essential feature
>> Gáspar already mentioned it in another thread; the CHAOS target from
>> Xtables-addons.
>
> CHAOS and TARPIT look about the same as DROP in regards to the question
> of REJECT vs DROP. The same arguments apply about a quick response from
> the filter or not.
>
> http://www.chrisbrenton.org/2009/07/why-firewall-reject-rules-are-better-than-firewall-drop-rules/
>
> http://www.chiark.greenend.org.uk/~peterb/network/drop-vs-reject
>
>
> /Lars
>
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
