From: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
To: "Maciej Żenczykowski" <zenczykowski@gmail.com>
Cc: "David S . Miller" <davem@davemloft.net>,
Linux NetDev <netdev@vger.kernel.org>,
Sean Tranchetti <stranche@codeaurora.org>,
Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>,
Eric Dumazet <edumazet@google.com>,
Linux SCTP <linux-sctp@vger.kernel.org>
Subject: Re: [PATCH] net: introduce ip_local_unbindable_ports sysctl
Date: Wed, 27 Nov 2019 20:00:01 -0300 [thread overview]
Message-ID: <20191127230001.GO388551@localhost.localdomain> (raw)
In-Reply-To: <CANP3RGePJ+z1t8oq-QS1tcwEYWanPHPargKpHkZZGiT4jMa6xw@mail.gmail.com>
On Wed, Nov 27, 2019 at 12:50:39PM -0800, Maciej Żenczykowski wrote:
> On Wed, Nov 27, 2019 at 5:14 AM Marcelo Ricardo Leitner
> <marcelo.leitner@gmail.com> wrote:
> >
> > On Tue, Nov 26, 2019 at 04:13:13PM -0800, Maciej Żenczykowski wrote:
> > > From: Maciej Żenczykowski <maze@google.com>
> > >
> > > and associated inet_is_local_unbindable_port() helper function:
> > > use it to make explicitly binding to an unbindable port return
> > > -EPERM 'Operation not permitted'.
> > >
> > > Autobind doesn't honour this new sysctl since:
> > > (a) you can simply set both if that's the behaviour you desire
> > > (b) there could be a use for preventing explicit while allowing auto
> > > (c) it's faster in the relatively critical path of doing port selection
> > > during connect() to only check one bitmap instead of both
> > ...
> > > If we *know* that certain ports are simply unusable, then it's better
> > > nothing even gets the opportunity to try to use them. This way we at
> > > least get a quick failure, instead of some sort of timeout (or possibly
> > > even corruption of the data stream of the non-kernel based use case).
> >
> > This is doable with SELinux today, no?
>
> Perhaps, but SELinux isn't used by many distros, including the servers
> where I have nics that steal some ports. It's also much much
> more difficult, requiring a policy, compilers, etc... and it gets even
> more complex if you need to dynamically modify the set of ports,
> which requires extra tools and runtime permissions.
I'm no SELinux expert, but my /etc/ssh/sshd_config has this nice handy
comment:
# If you want to change the port on a SELinux system, you have to tell
# SELinux about this change.
# semanage port -a -t ssh_port_t -p tcp #PORTNUMBER
The kernel has no specific knowledge of 'ssh_port_t' and all I need to
do to allow such port, is run the command above. No compiler, etc.
The distribution would have to have a policy, say,
'unbindable_ports_t', and it could work similarly, I suppose, but I
have no knowledge on this part.
As a reference only,
# semanage port -l
gives a great list of ports that daemons are supposed to be using, and
it supports ranges and so, like:
amqp_port_t tcp 15672, 5671-5672
gluster_port_t tcp 38465-38469, 24007-24027
On not having SELinux enabled, you got me there. I not really willing
to enter a "to do SELinux or not" discussion. :-)
next prev parent reply other threads:[~2019-11-27 23:00 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-27 0:13 [PATCH] net: introduce ip_local_unbindable_ports sysctl Maciej Żenczykowski
2019-11-27 2:10 ` subashab
2019-11-27 13:14 ` Marcelo Ricardo Leitner
2019-11-27 20:50 ` Maciej Żenczykowski
2019-11-27 22:33 ` David Miller
2019-11-27 23:00 ` Marcelo Ricardo Leitner [this message]
2019-11-29 20:00 ` Maciej Żenczykowski
2019-12-04 18:27 ` Marcelo Ricardo Leitner
2019-12-09 22:43 ` Maciej Żenczykowski
2019-12-09 22:45 ` [PATCH v2] " Maciej Żenczykowski
2019-12-09 23:42 ` Jakub Kicinski
2019-12-10 0:02 ` Maciej Żenczykowski
2019-12-10 0:18 ` Jakub Kicinski
2019-12-10 7:00 ` subashab
2019-12-10 11:46 ` Maciej Żenczykowski
2019-12-10 17:31 ` Jakub Kicinski
2019-12-13 0:16 ` Lorenzo Colitti
2019-12-13 0:47 ` Jakub Kicinski
2019-12-13 0:57 ` Lorenzo Colitti
2019-12-13 1:53 ` subashab
2019-12-13 2:04 ` Jakub Kicinski
2019-12-10 19:28 ` David Miller
[not found] ` <0101016eee9bf9b5-f5615781-f0a6-41c4-8e9d-ed694eccf07c-000000@us-west-2.amazonses.com>
2019-12-10 17:12 ` Jakub Kicinski
2019-12-10 18:12 ` subashab
2019-12-13 0:25 ` [PATCH] " Lorenzo Colitti
2019-12-13 11:49 ` Neil Horman
2019-12-19 9:35 ` Lorenzo Colitti
2019-12-19 13:17 ` Neil Horman
2019-12-19 14:02 ` Lorenzo Colitti
2019-12-19 16:57 ` Neil Horman
2019-12-19 17:52 ` David Miller
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=20191127230001.GO388551@localhost.localdomain \
--to=marcelo.leitner@gmail.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=linux-sctp@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=stranche@codeaurora.org \
--cc=subashab@codeaurora.org \
--cc=zenczykowski@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).