Hide Forgot
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.
(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.
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.
(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?
(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.
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.
(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.
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.
(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.
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.
(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.
(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?
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
(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.
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
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