Bug #7069

Dashboard's default port blocked by default SELinux policy

Added by Scott Merrill about 1 year ago. Updated 2 months ago.

Status:Needs Decision Start date:04/12/2011
Priority:Normal Due date:
Assignee:Michael Stahnke % Done:

0%

Category:-
Target version:-
Keywords:dashboard selinux policy Affected URL:
Branch: Affected Dashboard version:1.0.4
Votes: 0

Description

Trying to run Dashboard on a Red Hat Enterprise Linux 6 server with SELinux enabled does not work. The audit log records the following:

type=AVC msg=audit(1302621346.304:218642): avc:  denied  { name_connect } for  pid=27169 comm="puppetmasterd" dest=3000 scontext=system_u:system_r:puppetmaster_t:s0 tcontext=system_u:object_r:ntop_port_t:s0 tclass=tcp_socket

TCP port 3000 is assigned to ntop, and the default SELinux policy has a rule for the use of that port:

# semanage port -l | grep 3000
ntop_port_t                    tcp      3000, 3001
ntop_port_t                    udp      3000, 3001

I haven’t yet found a simple semanage command that will permit the puppetmasterd user to access the ntop port. An semanage command would be one possible easy fix.

Running audit2allow suggests (among other things) the following local policy:

#============= puppetmaster_t ==============
allow puppetmaster_t ntop_port_t:tcp_socket name_connect;

This requires the construction and compilation of a complete SELinux policy module, though, which seems a little excessive just to get Dashboard running.

Defining a different port for DASHBOARD_PORT in /etc/sysconfig/puppet-dashboard does permit the dashboard to start properly, with no SELinux complaints.

History

Updated by Scott Merrill about 1 year ago

My last sentence was unclear.

I defined DASHBOARD_PORT=3002 in /etc/sysconfig/puppet-dashboard. The dashboard service starts and operates successfully.

The root problem stems from Dashboard’s use of a port assigned to ntop.

Updated by Scott Merrill about 1 year ago

Actually, simply running on a different port is not sufficient to get Dashboard to work on a system with SELinux enforced.

I’m also seeing these in the audit log:

type=AVC msg=audit(1302639566.630:219929): avc:  denied  { name_connect } for  pid=27169 comm="puppetmasterd" dest=3000 scontext=system_u:system_r:puppetmaster_t:s0 tcontext=system_u:object_r:ntop_port_t:s0 tclass=tcp_socket

The full audit2allow output for Puppet is:

#============= puppetmaster_t ==============
allow puppetmaster_t cert_t:dir search;
allow puppetmaster_t cert_t:file { read getattr open };
allow puppetmaster_t cert_t:lnk_file read;
allow puppetmaster_t node_t:udp_socket node_bind;
allow puppetmaster_t ntop_port_t:tcp_socket name_connect;
allow puppetmaster_t port_t:udp_socket name_bind;
allow puppetmaster_t samba_var_t:dir search;
allow puppetmaster_t winbind_t:unix_stream_socket connectto;
allow puppetmaster_t winbind_var_run_t:dir { getattr search };
allow puppetmaster_t winbind_var_run_t:sock_file { write getattr };

Updated by Ben Hughes 12 months ago

  • Status changed from Unreviewed to Needs Decision
  • Assignee set to Nigel Kersten

Updated by Daniel Pittman 12 months ago

The right solution is probably to push the change upstream, or generally recommend people to use an Apache front-end between Dashboard and the world.

Updated by Nigel Kersten 12 months ago

I assume there isn’t an selinux policy that offers a more generic port for use like this?

Updated by Scott Merrill 11 months ago

I’m not aware of an SELinux policy for generic port use. I think the fundamental ideas of SELinux object to anything using a default policy: everything should be explicitly defined as to what is permissible.

We did switch to Apache + Passenger, and that’s been working fine for us.

Updated by Michael Stahnke 9 months ago

  • Target version set to 140

This is something we should be looking into. I think it’s safe to say that port 3000 should be reserved for Rails development, so maybe the SELinux default policy needs to be updated. I can check with the RH guys.

Either way, we should support running with SELinux enabled. I’ll target this in the 1.x series; hopefully in the next version.

Updated by Daniel Walsh 5 months ago

First I have heard about this. I have no problem allowing puppetmaster to connect to port 3000,3001 (ntop_port_t) We just have to hear about it.

It looks like everything in #2 is currently allowed other then ntop access.

Updated by Nigel Kersten 5 months ago

  • Assignee changed from Nigel Kersten to Michael Stahnke

Mike, can you weigh in on what we need to do here?

Updated by Daniel Pittman 2 months ago

  • Target version deleted (140)

Also available in: Atom PDF