3

I have the following rule to prohibit use of interface for users outside of fullnetwork group.

iptables -I OUTPUT -o eth+  -m owner \! --gid-owner fullnetwork -j REJECT

How can I allow local networks for users outside of fullnetwork?

I've tried this, but it didn't work

ipset create local hash:net
ipset add local 192.168.0.0/16
ipset add local 172.16.0.0/16
ipset add local 10.0.0.0/8
iptables -I OUTPUT -o eth+  -m owner \! --gid-owner fullnetwork -j REJECT
iptables -I OUTPUT -o eth+  -m owner \! --gid-owner fullnetwork -m set --match-set local src -j ACCEPT
4
  • If outside of fullnetwork, and not match better I think, just one line. 'iptables -I OUTPUT -o eth+ -m owner \! --gid-owner fullnetwork -m set ! --match-set local src -j REJECT'
    – K-attila-
    Sep 19, 2023 at 13:34
  • That didn't work
    – andreoss
    Sep 29, 2023 at 21:53
  • What does it mean, didn't work? You have an accept line too, isn't it?
    – K-attila-
    Oct 2, 2023 at 9:39
  • Note that my answer was made after the "that didn't work" comment.
    – A.B
    Oct 2, 2023 at 9:49

1 Answer 1

1

The required functionality has been added in iptables >= 1.8.4 and around kernel 5.3 (and is not available at all in nftables): also matching on supplementary groups, rather than only the current (primary) group: --suppl-groups:

--suppl-groups

Causes group(s) specified with --gid-owner to be also checked in the supplementary groups of a process.

Without this option, and without using this group directly for example with sg fullnetwork, even this command:

iptables -I OUTPUT -o eth+  -m owner \! --gid-owner fullnetwork -j REJECT

can't have the announced effect: it won't allow users having the group fullnetwork just in their supplementary group list to use network.

So to have this match as needed and reject other users, one should use for example:

iptables -I OUTPUT -o eth+  -m owner ! --gid-owner fullnetwork --suppl-groups -j REJECT

To be consistent, adding exceptions to exceptions should not become an ACCEPT rule, else users part of fullnetwork get potentially less access rights for the local networks than users merely permitted to access some LANS, in case further restrictions are added in later rules. Instead create an user chain to organize the rules together and have them bail out from rejection with a RETURN verdict without ever using an ACCEPT verdict and end with a single REJECT verdict. Replace the two previous iptables rules with:

iptables -N reject_non_allowed_on_eth

iptables -A reject_non_allowed_on_eth -m owner --gid-owner fullnetwork --suppl-groups -j RETURN
iptables -A reject_non_allowed_on_eth -m set --match-set local dst -j RETURN
iptables -A reject_non_allowed_on_eth -j REJECT

iptables -I OUTPUT -o eth+ -j reject_non_allowed_on_eth

This can be read like this:

  • if using an Ethernet interface,

    • if in fullnetwork group, bail out
    • if reaching private LANs, bail out
    • whatever is left is not authorized: reject it
  • more rules could be added later to further filter the remaining packets

Please also note an other change: the match is done on the destination (dst) and not the source (src) which would have allowed to reach anything as long as the system has an address in this range. Emitting from this address would always have been permitted if matching on source and this doesn't appear intended.

3
  • I've tried this verbatim on Linux 6.5, and any user outside of fullnetwork group is able to access non-local networks nevertheless
    – andreoss
    Oct 15, 2023 at 19:02
  • @andreoss I made a typo in my answer for the one-liner part. Fixed (check the changed order of the parameters). If it still doesn't work, can you provide iptables-save -c's output (the -c parameter will tell where the rules matched)?
    – A.B
    Oct 15, 2023 at 21:44
  • I still stand by my answer. But iptables-save -c (with my answer used in it) was never provided to help debug.
    – A.B
    Apr 5 at 10:48

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .