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 23:00:01 +0000 [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. :-)
WARNING: multiple messages have this Message-ID (diff)
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: 59+ 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 0:13 ` Maciej Żenczykowski
2019-11-27 2:10 ` subashab
2019-11-27 13:14 ` Marcelo Ricardo Leitner
2019-11-27 13:14 ` Marcelo Ricardo Leitner
2019-11-27 20:50 ` Maciej Żenczykowski
2019-11-27 20:50 ` Maciej Żenczykowski
2019-11-27 22:33 ` David Miller
2019-11-27 22:33 ` David Miller
2019-11-27 23:00 ` Marcelo Ricardo Leitner [this message]
2019-11-27 23:00 ` Marcelo Ricardo Leitner
2019-11-29 20:00 ` Maciej Żenczykowski
2019-11-29 20:00 ` Maciej Żenczykowski
2019-12-04 18:27 ` Marcelo Ricardo Leitner
2019-12-04 18:27 ` Marcelo Ricardo Leitner
2019-12-09 22:43 ` Maciej Żenczykowski
2019-12-09 22:43 ` Maciej Żenczykowski
2019-12-09 22:45 ` [PATCH v2] " Maciej Żenczykowski
2019-12-09 22:45 ` Maciej Żenczykowski
2019-12-09 23:42 ` Jakub Kicinski
2019-12-09 23:42 ` Jakub Kicinski
2019-12-10 0:02 ` Maciej Żenczykowski
2019-12-10 0:02 ` Maciej Żenczykowski
2019-12-10 0:18 ` Jakub Kicinski
2019-12-10 0:18 ` Jakub Kicinski
2019-12-10 7:00 ` subashab
2019-12-10 11:46 ` Maciej Żenczykowski
2019-12-10 11:46 ` Maciej Żenczykowski
2019-12-10 17:31 ` Jakub Kicinski
2019-12-10 17:31 ` Jakub Kicinski
2019-12-13 0:16 ` Lorenzo Colitti
2019-12-13 0:16 ` Lorenzo Colitti
2019-12-13 0:47 ` Jakub Kicinski
2019-12-13 0:47 ` Jakub Kicinski
2019-12-13 0:57 ` Lorenzo Colitti
2019-12-13 0:57 ` Lorenzo Colitti
2019-12-13 1:53 ` subashab
2019-12-13 1:53 ` subashab
2019-12-13 2:04 ` Jakub Kicinski
2019-12-13 2:04 ` Jakub Kicinski
2019-12-10 19:28 ` David Miller
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 17:12 ` Jakub Kicinski
2019-12-10 18:12 ` subashab
2019-12-13 0:25 ` [PATCH] " Lorenzo Colitti
2019-12-13 0:25 ` Lorenzo Colitti
2019-12-13 11:49 ` Neil Horman
2019-12-13 11:49 ` Neil Horman
2019-12-19 9:35 ` Lorenzo Colitti
2019-12-19 9:35 ` Lorenzo Colitti
2019-12-19 13:17 ` Neil Horman
2019-12-19 13:17 ` Neil Horman
2019-12-19 14:02 ` Lorenzo Colitti
2019-12-19 14:02 ` Lorenzo Colitti
2019-12-19 16:57 ` Neil Horman
2019-12-19 16:57 ` Neil Horman
2019-12-19 17:52 ` David Miller
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 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.