netfilter-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Topi Miettinen <toiwoton@gmail.com>
Cc: netfilter-devel@vger.kernel.org
Subject: Re: Support for loading firewall rules with cgroup(v2) expressions early
Date: Wed, 6 Apr 2022 00:00:19 +0200	[thread overview]
Message-ID: <Yky787OF8/FdnIPr@salvia> (raw)
In-Reply-To: <6786df44-49de-3d35-2c16-030e6290d19d@gmail.com>

On Sun, Apr 03, 2022 at 09:32:11PM +0300, Topi Miettinen wrote:
> On 2.4.2022 11.12, Topi Miettinen wrote:
> > On 30.3.2022 5.53, Pablo Neira Ayuso wrote:
> > > On Wed, Mar 30, 2022 at 12:25:25AM +0200, Pablo Neira Ayuso wrote:
> > > > On Tue, Mar 29, 2022 at 09:20:25PM +0300, Topi Miettinen wrote:
> > > [...]
> > > > You could define a ruleset that describes the policy following the
> > > > cgroupsv2 hierarchy. Something like this:
> > > > 
> > > >   table inet filter {
> > > >          map dict_cgroup_level_1 {
> > > >                  type cgroupsv2 : verdict;
> > > >                  elements = { "system.slice" : jump system_slice }
> > > >          }
> > > > 
> > > >          map dict_cgroup_level_2 {
> > > >                  type cgroupsv2 : verdict;
> > > >                  elements = {
> > > > "system.slice/systemd-timesyncd.service" : jump
> > > > systemd_timesyncd }
> > > >          }
> > > > 
> > > >          chain systemd_timesyncd {
> > > >                  # systemd-timesyncd policy
> > > >          }
> > > > 
> > > >          chain system_slice {
> > > >                  socket cgroupv2 level 2 vmap @dict_cgroup_level_2
> > > >                  # policy for system.slice process
> > > >          }
> > > > 
> > > >          chain input {
> > > >                  type filter hook input priority filter; policy drop;
> > > 
> > > This example should use the output chain instead:
> > > 
> > >            chain output {
> > >                    type filter hook output priority filter; policy drop;
> > > 
> > >  From the input chain, the packet relies on early demux to have access
> > > to the socket.
> > > 
> > > The idea would be to filter out outgoing traffic and rely on conntrack
> > > for (established) input traffic.
> > 
> > Is it really so that 'socket cgroupv2' can't be used on input side at
> > all? At least 'ss' can display the cgroup for listening sockets
> > correctly, so the cgroup information should be available somewhere:
> > 
> > $ ss -lt --cgroup
> > State    Recv-Q   Send-Q       Local Address:Port       Peer
> > Address:Port   Process
> > LISTEN   0        4096                  *%lo:ssh                   *:*
> >      cgroup:/system.slice/ssh.socket
> 
> Also 'meta skuid' doesn't seem to work in input filters. It would have been
> simple to use 'meta skuid < 1000' to simulate 'system.slice' vs.
> 'user.slice' cgroups.
> 
> If this is intentional, the manual page should make this much clearer.

It is not yet described in nft(8) unfortunately, but
iptables-extensions(8) says:

 IMPORTANT: when being used in the INPUT chain, the cgroup matcher is currently only
       of limited functionality, meaning it will only match on packets that are processed
       for local sockets through early socket demuxing. Therefore, general usage on the INPUT
       chain is not advised unless the implications are well understood.

> There's no warning and the kernel doesn't reject the useless input rules.
> 
> I think it should be possible to do filtering on input side based on the
> socket properties (UID, GID, cgroup). Especially with UDP, it should be
> possible to drop all packets if the listening process is not OK.

Everything is possible, it's not yet implemented though.

> My use case is that I need to open ports for Steam games (TCP and UDP ports
> 27015-27030) but I don't want to make them available for system services or
> any other apps besides Steam games. SELinux SECMARKs and TE rules for
> sockets help me here but there are other problems.

  reply	other threads:[~2022-04-06  4:53 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-26 10:09 Support for loading firewall rules with cgroup(v2) expressions early Topi Miettinen
2022-03-27 21:31 ` Pablo Neira Ayuso
2022-03-28 14:08   ` Topi Miettinen
2022-03-28 15:05     ` Pablo Neira Ayuso
2022-03-28 17:46       ` Topi Miettinen
2022-03-29 18:20       ` Topi Miettinen
2022-03-29 22:25         ` Pablo Neira Ayuso
2022-03-30  2:53           ` Pablo Neira Ayuso
2022-04-02  8:12             ` Topi Miettinen
2022-04-03 18:32               ` Topi Miettinen
2022-04-05 22:00                 ` Pablo Neira Ayuso [this message]
2022-04-06 13:57                   ` Topi Miettinen
2022-03-30 16:37           ` Topi Miettinen
2022-03-30 21:47             ` Pablo Neira Ayuso
2022-03-31 15:10               ` Topi Miettinen
2022-04-05 22:18                 ` Pablo Neira Ayuso
2022-04-06 14:02                   ` Topi Miettinen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Yky787OF8/FdnIPr@salvia \
    --to=pablo@netfilter.org \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=toiwoton@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).