httpd and tcp_connect

[Michael Thomas]

I'm receiving the following avc denial from a game package that's under 
review[1]:

Jan 21 10:55:49 localhost kernel: audit(1169405749.338:3): avc:  denied 
  { name_connect } for  pid=2661 comm="httpd" dest=19382 
scontext=user_u:system_r:httpd_t:s0 tcontext=system_u:object_r:port_t:s0 
tclass=tcp_socket

The package includes a php-based web application and a python daemon 
backend.  The php webapp communicates with the python daemon through tcp 
sockets.

From the avc denial it appears that this communication fails because 
httpd is not allowed to establish tcp connections.  This seems like a 
valid security restriction, except in this case I do want to allow it.

How can I configure the httpd policy to allow tcp connections, but only 
to localhost and only on the python daemon's ports (19380-19383)?

--Wart
[1] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=219972

[Daniel J Walsh]

Wart wrote:
> I'm receiving the following avc denial from a game package that's 
> under review[1]:
>
> Jan 21 10:55:49 localhost kernel: audit(1169405749.338:3): avc:  
> denied  { name_connect } for  pid=2661 comm="httpd" dest=19382 
> scontext=user_u:system_r:httpd_t:s0 
> tcontext=system_u:object_r:port_t:s0 tclass=tcp_socket
>
> The package includes a php-based web application and a python daemon 
> backend.  The php webapp communicates with the python daemon through 
> tcp sockets.
>
> From the avc denial it appears that this communication fails because 
> httpd is not allowed to establish tcp connections.  This seems like a 
> valid security restriction, except in this case I do want to allow it.
>
> How can I configure the httpd policy to allow tcp connections, but 
> only to localhost and only on the python daemon's ports (19380-19383)?
>
> --Wart

Ok this can be fixed in multiple different ways.

One would be to allow httpd to connect to any port
setsebool -P httpd_can_network_connect=1
This would lessen your security, since httpd would now be able to 
connect to any port

Another would be to add the ports to http_port_t via semanage
semanage port -a -t http_port_t -p tcp 19380-19383
This would be better in that http is allowed to connect to http_port_t 
by default, but now it can also bind to these additional ports.

The best solution would be to make a loadable policy module, and define 
a new port,  something like

Create a te file like the following

#cat webapp.te
policy_module(webapp, 1.0);

require {
        type httpd_t;

};

type webapp_port_t;

allow httpd_t webapp_port_t:tcp_socket name_connect;
# make -f /usr/share/selinux/targeted/include/Makefile webapp.pp
# semodule -i webapp.pp
# semanage port -a -t webapp_port_t -p tcp 19380-19383
> [1] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=219972
>
> -- 
> fedora-selinux-list mailing list
> [e-mail]
> https://www.redhat.com/mailman/listinfo/fedora-selinux-list

[Michael Thomas]

Daniel J Walsh wrote:
> The best solution would be to make a loadable policy module, and define 
> a new port,  something like
>
> Create a te file like the following
>
> #cat webapp.te
> policy_module(webapp, 1.0);
>
> require {
>        type httpd_t;
>
> };
>
> type webapp_port_t;
>
> allow httpd_t webapp_port_t:tcp_socket name_connect;
> # make -f /usr/share/selinux/targeted/include/Makefile webapp.pp
> # semodule -i webapp.pp
> # semanage port -a -t webapp_port_t -p tcp 19380-19383

Thanks for the tip.  This worked just fine.  Now that I have a working 
policy for this server + web application, I'm trying to get it all 
packaged up nicely.  I've got a policy that works, but to package it 
properly I'd have to split up rules between the webapp component and the 
server component, with dependencies between them.  I'm sure with some 
more work I could do this, but it starts to become trickier to package. 
  It seems like it would be much easier to manage if it were all part of 
the upstream selinux reference policy instead.

What is the best way to go about submitting new policies to be included 
in the reference policy?

--Mike

[Daniel J Walsh]

Wart wrote:
> Daniel J Walsh wrote:
> > The best solution would be to make a loadable policy module, and 
> > define a new port,  something like
> >
> > Create a te file like the following
> >
> > #cat webapp.te
> > policy_module(webapp, 1.0);
> >
> > require {
> >        type httpd_t;
> >
> > };
> >
> > type webapp_port_t;
> >
> > allow httpd_t webapp_port_t:tcp_socket name_connect;
> > # make -f /usr/share/selinux/targeted/include/Makefile webapp.pp
> > # semodule -i webapp.pp
> > # semanage port -a -t webapp_port_t -p tcp 19380-19383
>
> Thanks for the tip.  This worked just fine.  Now that I have a working 
> policy for this server + web application, I'm trying to get it all 
> packaged up nicely.  I've got a policy that works, but to package it 
> properly I'd have to split up rules between the webapp component and 
> the server component, with dependencies between them.  I'm sure with 
> some more work I could do this, but it starts to become trickier to 
> package.  It seems like it would be much easier to manage if it were 
> all part of the upstream selinux reference policy instead.
>
> What is the best way to go about submitting new policies to be 
> included in the reference policy?
>
> --Mike

Submit it as a patch to the [e-mail] mailing list, and 
request that it get upstreamed.