All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.