Bug 1650909 - tangd.socket cannot bind to port 5910
Summary: tangd.socket cannot bind to port 5910
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: selinux-policy
Version: 7.6
Hardware: All
OS: Linux
high
medium
Target Milestone: rc
: ---
Assignee: Lukas Vrabec
QA Contact: Milos Malik
Mirek Jahoda
URL:
Whiteboard:
Depends On:
Blocks: 1664345
TreeView+ depends on / blocked
 
Reported: 2018-11-17 14:16 UTC by Tomasz Kepczynski
Modified: 2019-08-06 12:53 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
.`tangd_port_t` allows changes of the default port for Tang This update introduces the `tangd_port_t` SELinux type that allows the `tangd` service run as confined with SELinux enforcing mode. That change helps to simplify configuring a Tang server to listen on a user-defined port and it also preserves the security level provided by SELinux in enforcing mode.
Clone Of:
: 1664345 (view as bug list)
Environment:
Last Closed: 2019-08-06 12:52:54 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2019:2127 None None None 2019-08-06 12:53:18 UTC

Description Tomasz Kepczynski 2018-11-17 14:16:02 UTC
Description of problem:
RHEL-7.6 update to tang and systemd broke ability to bind tangd to port other than default http port 80. This severly restricts possibility to run both httpd and tang on single server.

Version-Release number of selected component (if applicable):
tang-6-1.el7.x86_64

How reproducible:
always

Steps to Reproduce:
1. cp /usr/lib/systemd/system/tangd.socket /etc/systemd/system/tangd.socket
2. edit ListenStream=80 line to ListenStream=5910
3. systemctl reload-daemon
4. systemctl start tangd.socket

Actual results:
tangd.socket does not start

Expected results:
tangd.socket starts

Additional info:

This is caused by changes in selinux policies (apparently tangd_t type has been added). ausearch -c systemd reveals:

type=AVC msg=audit(1542409016.163:310): avc:  denied  { name_bind } for  pid=1 comm="systemd" src=5910 scontext=system_u:system_r:tangd_t:s0 tcontext=system_u:object_r:vnc_port_t:s0 tclass=tcp_socket permissive=0

sesearch -A -s tangd_t | grep name_bind shows:
allow tangd_t http_port_t : tcp_socket name_bind ; 

This apparently restricts tangd ability to bind only to http_port_t ports.

The problem with that is that adding whatever port is selected for tang to http_port_t will also open it to any other apps which are bound by http_port_t type and this is something I would like to avoid.

I see the need to create tang_port_t to be exclusively used by tang.

Comment 2 Daniel Kopeček 2018-11-19 09:45:53 UTC
(In reply to Tomasz Kepczynski from comment #0)
> Description of problem:
> RHEL-7.6 update to tang and systemd broke ability to bind tangd to port
> other than default http port 80. This severly restricts possibility to run
> both httpd and tang on single server.
> 
> Version-Release number of selected component (if applicable):
> tang-6-1.el7.x86_64
> 
> How reproducible:
> always
> 
> Steps to Reproduce:
> 1. cp /usr/lib/systemd/system/tangd.socket /etc/systemd/system/tangd.socket
> 2. edit ListenStream=80 line to ListenStream=5910
> 3. systemctl reload-daemon
> 4. systemctl start tangd.socket
> 
> Actual results:
> tangd.socket does not start
> 
> Expected results:
> tangd.socket starts
> 
> Additional info:
> 
> This is caused by changes in selinux policies (apparently tangd_t type has
> been added). ausearch -c systemd reveals:
> 
> type=AVC msg=audit(1542409016.163:310): avc:  denied  { name_bind } for 
> pid=1 comm="systemd" src=5910 scontext=system_u:system_r:tangd_t:s0
> tcontext=system_u:object_r:vnc_port_t:s0 tclass=tcp_socket permissive=0
> 
> sesearch -A -s tangd_t | grep name_bind shows:
> allow tangd_t http_port_t : tcp_socket name_bind ; 
> 
> This apparently restricts tangd ability to bind only to http_port_t ports.
> 
> The problem with that is that adding whatever port is selected for tang to
> http_port_t will also open it to any other apps which are bound by
> http_port_t type and this is something I would like to avoid.
> 
> I see the need to create tang_port_t to be exclusively used by tang.

If there's a need to bind to other port that those allowed by the active SELinux policy, then this needs to be consulted with SELinux policy maintainers. Lukas, what do you think about this? I'd say this a feature request rather than a bug.

Comment 4 Lukas Vrabec 2019-01-07 11:45:03 UTC
After discussion with tang maintainer, there should be new default port for tang different than port 80. After this change, I'll update selinux-policy for tang and create new label for default tang port. 

Thanks,
Lukas.

Comment 5 Daniel Kopeček 2019-01-07 12:01:53 UTC
(In reply to Lukas Vrabec from comment #4)
> After discussion with tang maintainer, there should be new default port for
> tang different than port 80. After this change, I'll update selinux-policy
> for tang and create new label for default tang port. 

Martin, do you think that things will break if we move to a different port?
I wonder if there are places not under our control, that expect tang on 80/tcp.
We can update clevis docs and tang just fine, but existing bindings will break, won't they?

Comment 6 Daniel Kopeček 2019-01-07 12:26:25 UTC
(In reply to Daniel Kopeček from comment #5)
> (In reply to Lukas Vrabec from comment #4)
> > After discussion with tang maintainer, there should be new default port for
> > tang different than port 80. After this change, I'll update selinux-policy
> > for tang and create new label for default tang port. 
> 
> Martin, do you think that things will break if we move to a different port?
> I wonder if there are places not under our control, that expect tang on
> 80/tcp.
> We can update clevis docs and tang just fine, but existing bindings will
> break, won't they?

After discussion with Martin we decided to propose this as a documentation enhancement bug.
Changing the port would break existing installations and there's no simple way to move to a new port that would leave existing installation in a working state.
The idea is to include an example on how to update the policy so that is allows tang to bind to the custom port.
A good idea would be to also show an example on how to create a reverse proxy in httpd for redirecting tang requests from httpd to a backend tangd instance.

Comment 7 Daniel Kopeček 2019-01-07 12:30:58 UTC
An additional question for Lukas: Is is possible to have two selinux types for the same port number? i.e. tang_port_t would be 80 by default.
This would allow users to diverge from the default configuration by manually changing their tang_port_t definition but leave other apps that use 80 via http_port_t untouched.

Comment 8 Dalibor Pospíšil 2019-01-07 12:46:01 UTC
(In reply to Daniel Kopeček from comment #7)
> An additional question for Lukas: Is is possible to have two selinux types
> for the same port number? i.e. tang_port_t would be 80 by default.
> This would allow users to diverge from the default configuration by manually
> changing their tang_port_t definition but leave other apps that use 80 via
> http_port_t untouched.

AFAIK this is not possible, port is just like a file, it can have one type assigned only. Therefore the new type is conditioned by the default port change.

Comment 9 Lukas Vrabec 2019-01-07 14:10:57 UTC
Dalibor is right. It's not possible. But, what we can do is to allow tangd_t SELinux domain to bind on default http_port_t (tcp/80) and also binding on tangd_port_t and user will be able to assign this label to custom port. 

Thanks,
Lukas.

Comment 10 Dalibor Pospíšil 2019-01-07 16:48:20 UTC
(In reply to Lukas Vrabec from comment #9)
> Dalibor is right. It's not possible. But, what we can do is to allow tangd_t
> SELinux domain to bind on default http_port_t (tcp/80) and also binding on
> tangd_port_t and user will be able to assign this label to custom port. 
This is great idea. This way user would not allow apache (httpd_t) to bind to other port, while tangd would be able to do that. And we can put simple steps how to achieve it to the documentation.

Comment 11 Tomasz Kepczynski 2019-01-07 20:42:24 UTC
This also allows the possibility to remove reliance on the http port in the future (given enought notice).

On a side note - have you considered querying SRV records in clevis? This may allow easier transition off the default http port.

Comment 12 Daniel Kopeček 2019-01-14 09:27:45 UTC
(In reply to Lukas Vrabec from comment #9)
> Dalibor is right. It's not possible. But, what we can do is to allow tangd_t
> SELinux domain to bind on default http_port_t (tcp/80) and also binding on
> tangd_port_t and user will be able to assign this label to custom port. 
> 
> Thanks,
> Lukas.

Ok, let's use the http_port_t + tangd_port_t + documentation solution.

Comment 13 Daniel Kopeček 2019-01-14 14:10:44 UTC
(In reply to Tomasz Kepczynski from comment #11)
> This also allows the possibility to remove reliance on the http port in the
> future (given enought notice).
> 
> On a side note - have you considered querying SRV records in clevis? This
> may allow easier transition off the default http port.

That seems like a good idea. For now, the default additional port behind tangd_port_t
will be tcp/7406.

Do you have an idea what would be the best approach to support DNS SRV based discovery
from a bash program? probably via the dig(1) utility?

Comment 14 Tomasz Kepczynski 2019-01-14 19:04:16 UTC
I use wrapsrv from https://github.com/farsightsec/wrapsrv for similar purposes (ssh proxy for hosts behind NAT, DNATed from non-standard ports). For what its worth, I've prepared rpm here: https://copr.fedorainfracloud.org/coprs/tomkep/epel-extras/build/580456/.

It will attempt to run a program through SRV targets, according to priority and weight, until it succeeds or exhausts the list. Empty records (indicating service disablement) may require extra handling in the app...

Please note that you should carefully consider how the service should be named (_tang?, _http?) and its relation with URL protocol (for now you use http:// for tang URLs, I wouldn't name service _http for this, and _tang doesn't seem to correlate with URL...).

For a quick starter try:

wrapsrv _imaps._tcp.gmail.com echo %h:%p # for exposed service

and

wrapsrv _imap._tcp.gmail.com echo %h:%p # for disabled/nonexisting one

Comment 15 Daniel Kopeček 2019-01-21 09:43:54 UTC
(In reply to Tomasz Kepczynski from comment #14)
> I use wrapsrv from https://github.com/farsightsec/wrapsrv for similar
> purposes (ssh proxy for hosts behind NAT, DNATed from non-standard ports).
> For what its worth, I've prepared rpm here:
> https://copr.fedorainfracloud.org/coprs/tomkep/epel-extras/build/580456/.
> 
> It will attempt to run a program through SRV targets, according to priority
> and weight, until it succeeds or exhausts the list. Empty records
> (indicating service disablement) may require extra handling in the app...
> 
> Please note that you should carefully consider how the service should be
> named (_tang?, _http?) and its relation with URL protocol (for now you use
> http:// for tang URLs, I wouldn't name service _http for this, and _tang
> doesn't seem to correlate with URL...).
> 
> For a quick starter try:
> 
> wrapsrv _imaps._tcp.gmail.com echo %h:%p # for exposed service
> 
> and
> 
> wrapsrv _imap._tcp.gmail.com echo %h:%p # for disabled/nonexisting one

Thanks! For RHEL we would have to look for some supportable solution.
That means to either include that utility in RHEL or find a solution based on existing RHEL pieces.

Comment 18 Lukas Vrabec 2019-03-12 11:47:12 UTC
commit 94c71713306f53478bde027f99e5e0911cab97af (HEAD -> rhel7.7-contrib, origin/rhel7.7-contrib)
Author: Lukas Vrabec <lvrabec@redhat.com>
Date:   Mon Jan 14 12:51:23 2019 +0100

    Allow tangd_t domain to bind on tcp ports labeled as tangd_port_t
    Resolves: rhbz#1650909

commit fd6639ddecbc06fb0bfefbb5b0bbd31f07362bd0 (HEAD -> rhel7.7-base, origin/rhel7.7-base)
Author: Lukas Vrabec <lvrabec@redhat.com>
Date:   Mon Jan 14 12:48:01 2019 +0100

    Create tangd_port_t with default label tcp/7406
    Resolves: rhbz#1650909

Comment 30 errata-xmlrpc 2019-08-06 12:52:54 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2019:2127


Note You need to log in before you can comment on or make changes to this bug.