On Wed, April 1, 2015 16:09, Andrew Holway wrote:> I used the command: semanage port -m -t http_port_t -p tcp 8000 > to relabel a port. perhaps you could try: > "semanage port -m -t unconfined_t -p tcp 8000" > Failing that; would it work to run your application in the httpd_t > domain? >I ended up having to create a custom policy to allow the other application to have access to the http_port_t context. Which is not an issue given that no httpd service is, or will ever be, installed on that host. However, it seems a rather dangerous hole in the logical design of SELinux that one cannot explicitly remove and reassign contexts to ports. In order to accomplish this on a system running httpd but attached to non-standard ports one perforce is required to cross link permissions between all of the affected processes. Which I cannot conceive as a security enhancement. -- *** E-Mail is NOT a SECURE channel *** James B. Byrne mailto:ByrneJB at Harte-Lyne.ca Harte & Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3
File a bug!!! On 2 April 2015 at 16:20, James B. Byrne <byrnejb at harte-lyne.ca> wrote:> > On Wed, April 1, 2015 16:09, Andrew Holway wrote: > > I used the command: semanage port -m -t http_port_t -p tcp 8000 > > to relabel a port. perhaps you could try: > > "semanage port -m -t unconfined_t -p tcp 8000" > > Failing that; would it work to run your application in the httpd_t > > domain? > > > > I ended up having to create a custom policy to allow the other > application to have access to the http_port_t context. Which is not > an issue given that no httpd service is, or will ever be, installed on > that host. > > However, it seems a rather dangerous hole in the logical design of > SELinux that one cannot explicitly remove and reassign contexts to > ports. In order to accomplish this on a system running httpd but > attached to non-standard ports one perforce is required to cross link > permissions between all of the affected processes. Which I cannot > conceive as a security enhancement. > > > -- > *** E-Mail is NOT a SECURE channel *** > James B. Byrne mailto:ByrneJB at Harte-Lyne.ca > Harte & Lyne Limited http://www.harte-lyne.ca > 9 Brockley Drive vox: +1 905 561 1241 > Hamilton, Ontario fax: +1 905 561 0757 > Canada L8E 3C3 > > _______________________________________________ > CentOS mailing list > CentOS at centos.org > http://lists.centos.org/mailman/listinfo/centos >
You should be able to modify the definition of a port. Or create a new port type and modify the existing port to use it. http_port_t is just a name (type) that we can use to group a number of ports together. Sadly we do not separate the port types of incoming and outgoing connections. So if you confined httpd and firefox on the same machine it gets difficult to say firefox is allowed to connect to port 80,8080,8000 while your httpd service is only able to bind to port 8000, without defining new types and installing custom policy modules. On 04/02/2015 11:03 AM, Andrew Holway wrote:> File a bug!!! > > On 2 April 2015 at 16:20, James B. Byrne <byrnejb at harte-lyne.ca> wrote: > >> On Wed, April 1, 2015 16:09, Andrew Holway wrote: >>> I used the command: semanage port -m -t http_port_t -p tcp 8000 >>> to relabel a port. perhaps you could try: >>> "semanage port -m -t unconfined_t -p tcp 8000" >>> Failing that; would it work to run your application in the httpd_t >>> domain? >>> >> I ended up having to create a custom policy to allow the other >> application to have access to the http_port_t context. Which is not >> an issue given that no httpd service is, or will ever be, installed on >> that host. >> >> However, it seems a rather dangerous hole in the logical design of >> SELinux that one cannot explicitly remove and reassign contexts to >> ports. In order to accomplish this on a system running httpd but >> attached to non-standard ports one perforce is required to cross link >> permissions between all of the affected processes. Which I cannot >> conceive as a security enhancement. >> >> >> -- >> *** E-Mail is NOT a SECURE channel *** >> James B. Byrne mailto:ByrneJB at Harte-Lyne.ca >> Harte & Lyne Limited http://www.harte-lyne.ca >> 9 Brockley Drive vox: +1 905 561 1241 >> Hamilton, Ontario fax: +1 905 561 0757 >> Canada L8E 3C3 >> >> _______________________________________________ >> CentOS mailing list >> CentOS at centos.org >> http://lists.centos.org/mailman/listinfo/centos >> > _______________________________________________ > CentOS mailing list > CentOS at centos.org > http://lists.centos.org/mailman/listinfo/centos