netfilter buglog - Dec 2017 - [Bug 1208] New: --gid-owner ignores non-primary group memberships

https://bugzilla.netfilter.org/show_bug.cgi?id=1208

            Bug ID: 1208
           Summary: --gid-owner ignores non-primary group memberships
           Product: netfilter/iptables
           Version: linux-2.6.x
          Hardware: All
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: ip_tables (kernel)
          Assignee: netfilter-buglog at lists.netfilter.org
          Reporter: dguyton at gmail.com

Created attachment 515
  --> https://bugzilla.netfilter.org/attachment.cgi?id=515&action=edit
Screenshot of iptables/netfilter man page section on -m owner

=======Synopsis
=======Request change to current packet owner filtering process by iptables.

======Problem
======iptables extension "-m owner --gid-owner" only examines the
packet owner's
primary gid. 

================Proposed Solution
================One of two steps should be taken by Dev:

1. Update man pages to declare current behavior; OR
2. Change current behavior to include examining owner's primary and
secondary
group memberships, and branch --gid-owner filter if there is a match of ANY
group membership of the owner.

Solution #2 is suggested as it is in the spirit of the feature. Solution #1
would simply bring the documentation in-line with current behavior, but does
not solve the problem.

============Justification
============Common scenario consists of system environments where usernames are
assigned to
multiple user groups, for purpose of filtering users based on file permissions,
access permissions, content filtering, etc. This is a very common practice.

Current behavior only allows network packet filtering based on primary user
group. This creates a challenge for programmers when packets owned by a class
of users needs to be manipulated in iptables, yet other requirements dictate
the associated username accounts cannot share a common, primary user group.

While this issue can be mitigated through the use of multiple --uid-owner
commands in iptables, doing so is inefficient and time consuming. That process
also makes server maintenance more difficult as the sysadmin must know to add a
new rule everytime a new user is created who should be branched by the same
filter. This also defeats the purpose of creating the --gid-owner parameter in
the first place.

==================Illustrated Example
==================Scenario: Sysadmin is creating a split VPN. A specific user
group 'vpn' is
created for the purpose of forcing its network traffic through a VPN interface
and blocking it from the default internet gateway.

Problem: This won't work as desired if any target users belong to group
'vpn'
as a secondary group. It will only branch users who belong to group
'vpn' as
their primary/default user group.

`--gid-owner` only examines the primary/default group of the owner of the
packet

The user will be forced to create individual rules for each username, using
'--uid-owner' instead; a very inefficient process.

-- 
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20171230/515c2610/attachment.html>

https://bugzilla.netfilter.org/show_bug.cgi?id=1208

David <dguyton at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P5                          |P4
           Severity|enhancement                 |minor

-- 
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20171230/fd69759d/attachment.html>

https://bugzilla.netfilter.org/show_bug.cgi?id=1208

David <dguyton at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 OS|All                         |Ubuntu
                 CC|                            |dguyton at gmail.com
          Component|ip_tables (kernel)          |unknown

-- 
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20171230/bd5cce4f/attachment.html>

https://bugzilla.netfilter.org/show_bug.cgi?id=1208

David <dguyton at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|unknown                     |ip_tables (kernel)
                 OS|Ubuntu                      |All

--- Comment #1 from David <dguyton at gmail.com> ---
Related to bug 1035. This bug report (1208) provides more information on the
problem, and suggested solutions.

-- 
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20171230/0843871e/attachment.html>

https://bugzilla.netfilter.org/show_bug.cgi?id=1208

Pablo Neira Ayuso <pablo at netfilter.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
                 CC|                            |pablo at netfilter.org

--- Comment #2 from Pablo Neira Ayuso <pablo at netfilter.org> ---
You can create a set that stores all uids that belong to the given group in
nftables.

table ip x {
        set y {
                type uid
                elements = { "root", "avahi" }
        }

        chain c1 {
                type filter hook output priority 0; policy accept;
                skuid @y counter packets 0 bytes 0
        }
}

-- 
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20180202/aadf0737/attachment.html>