netfilter-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Phil Sutter <phil@nwl.cc>, netfilter-devel@vger.kernel.org
Subject: Re: [iptables PATCH] xshared: Fix response to unprivileged users
Date: Thu, 27 Jan 2022 18:31:16 +0100	[thread overview]
Message-ID: <YfLW5BA1EaBXoadZ@salvia> (raw)
In-Reply-To: <YfLWdhzy8C9vI03S@orbyte.nwl.cc>

On Thu, Jan 27, 2022 at 06:29:26PM +0100, Phil Sutter wrote:
> On Thu, Jan 27, 2022 at 06:21:10PM +0100, Pablo Neira Ayuso wrote:
> > On Thu, Jan 27, 2022 at 06:08:31PM +0100, Phil Sutter wrote:
> > > Hi Pablo,
> > > 
> > > On Thu, Jan 27, 2022 at 05:28:39PM +0100, Pablo Neira Ayuso wrote:
> > > > On Thu, Jan 20, 2022 at 11:16:53AM +0100, Phil Sutter wrote:
> > > > > Expected behaviour in both variants is:
> > > > > 
> > > > > * Print help without error, append extension help if -m and/or -j
> > > > >   options are present
> > > > > * Indicate lack of permissions in an error message for anything else
> > > > > 
> > > > > With iptables-nft, this was broken basically from day 1. Shared use of
> > > > > do_parse() then somewhat broke legacy: it started complaining about
> > > > > inability to create a lock file.
> > > > > 
> > > > > Fix this by making iptables-nft assume extension revision 0 is present
> > > > > if permissions don't allow to verify. This is consistent with legacy.
> > > > > 
> > > > > Second part is to exit directly after printing help - this avoids having
> > > > > to make the following code "nop-aware" to prevent privileged actions.
> > > > 
> > > > On top of this patch, it should be possible to allow for some
> > > > nfnetlink command to be used from unpriviledged process.
> > > > 
> > > > I'm attaching a sketch patch, it skips module autoload which is should
> > > > not be triggered by an unpriviledged process.
> > > > 
> > > > This should allow for better help with -m/-j if the module is present.
> > > 
> > > That's interesting. What's the use-case? With my patch, extension help
> > > text printing works fine as unprivileged user. Does it allow to drop the
> > > "revision == 0 && EPERM" hack?
> > 
> > Your patch is needed because we have to deal with older kernels.
> > 
> > You assume revision 0 in case of EPERM. My patch provides better help
> > if the module is present since there is no need to assume revision 0.
> 
> Ah, that's a good point. Users always see rev0 help texts, which are
> naturally the most limited ones.
> 
> > Anyway, I think your approach is fine for the unpriviledged scenario
> > you describe. I just wanted to write here that there is room to extend
> > nfnetlink to support for unpriviledged requests.
> 
> I see, thanks. Yet your approach works only if the module is loaded
> already, right?

Yes, I don't think we should allow to autoload modules for non-CAP_NET_ADMIN.

> Unless it's useful elsewhere as well, I don't think it's worth the
> effort for iptables alone - requesting extension help as non-root is
> quite a corner-case IMHO.

Agreed.

      reply	other threads:[~2022-01-27 17:31 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-20 10:16 [iptables PATCH] xshared: Fix response to unprivileged users Phil Sutter
2022-01-20 10:33 ` Florian Westphal
2022-01-27 16:28 ` Pablo Neira Ayuso
2022-01-27 17:08   ` Phil Sutter
2022-01-27 17:21     ` Pablo Neira Ayuso
2022-01-27 17:29       ` Phil Sutter
2022-01-27 17:31         ` Pablo Neira Ayuso [this message]

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=YfLW5BA1EaBXoadZ@salvia \
    --to=pablo@netfilter.org \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=phil@nwl.cc \
    /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).