binding and listening to port work with SELinux, but the process is unable receive data from clients
Dear Members,
Sorry for bothering you with my questions but I am kind of stuck with my problem, that's why I turn to you now.
I am in the process of creating a SELinux policy for a software module, of a larger application. The module is simply a server, that listens on a port, and forwards the received information through a Unix domain socket to the main application. I got most parts of the policy right by now, in the sense that the module can start, and I don't see any AVC denied entries in the SELinux audit log.
The relevant parts of my policy are the following (I have substituted the module's name with ABCD):
type ABCD_t; type ABCD_port_t;
corenet_port(ABCD_port_t);
corenet_tcp_bind_generic_node(ABCD_t); corenet_tcp_sendrecv_generic_node(ABCD_t); corenet_tcp_sendrecv_generic_if(ABCD_t); allow ABCD_t ABCD_port_t:tcp_socket { name_bind };
allow ABCD_t self:unix_dgram_socket { create connect getattr setopt }; allow ABCD_t self:tcp_socket { accept bind create getattr listen setopt };
In the policy builder script also use
semanage port -a -t ABCD_port_t -p tcp 1234 2>/dev/null || semanage port -m -t ABCD_port_t -p tcp 1234 2>/dev/null
What I see with my current policy (with SELinux in Enforcing mode), is that the module starts up seemingly okay, it binds to the appropriate port, but see errors like this:
2019-03-19T16:08:14.314+0100 ERROR HTTP server error when serving connection "172.16.0.90:5986"<->"172.16.0.92:53952": error when reading request headers: read tcp4 172.16.0.90:5986->172.16.0.92:53952: read: permission denied 2019-03-19T16:08:14.315+0100 ERROR HTTP server error when serving connection "172.16.0.90:5986"<->"172.16.0.92:53953": error when reading request headers: read tcp4 172.16.0.90:5986->172.16.0.92:53953: read: permission denied
In addition to this, I see nothing in the SELinux audit log, and when I put SELinux in permissive mode, things start working again. I am puzzled at this point why I'm not seeing anything in audit.log. If it is in deed SELinux that's blocking the read attempts, then there should be some information about that. Right?
Thank you for your help!
Best Regards, János Szigetvári -- Janos SZIGETVARI RHCE, License no. 150-053-692 https://www.redhat.com/rhtapps/verify/?certId=150-053-692
LinkedIn: linkedin.com/in/janosszigetvari E-mail: janos@szigetvari.com, jszigetvari@gmail.com Phone: +36209440412 (Hungary)
__@__˚V˚ Make the switch to open (source) applications, protocols, formats now: - windows -> Linux, iexplore -> Firefox, msoffice -> LibreOffice - msn -> jabber protocol (Pidgin, Google Talk) - mp3 -> ogg, wmv -> ogg, jpg -> png, doc/xls/ppt -> odt/ods/odp
On 19.03.2019 21:23, SZIGETVÁRI János wrote:
Dear Members,
Sorry for bothering you with my questions but I am kind of stuck with my problem, that's why I turn to you now.
I am in the process of creating a SELinux policy for a software module, of a larger application. The module is simply a server, that listens on a port, and forwards the received information through a Unix domain socket to the main application. I got most parts of the policy right by now, in the sense that the module can start, and I don't see any AVC denied entries in the SELinux audit log.
The relevant parts of my policy are the following (I have substituted the module's name with ABCD):
type ABCD_t; type ABCD_port_t;
corenet_port(ABCD_port_t);
corenet_tcp_bind_generic_node(ABCD_t); corenet_tcp_sendrecv_generic_node(ABCD_t); corenet_tcp_sendrecv_generic_if(ABCD_t); allow ABCD_t ABCD_port_t:tcp_socket { name_bind };
allow ABCD_t self:unix_dgram_socket { create connect getattr setopt }; allow ABCD_t self:tcp_socket { accept bind create getattr listen setopt };
In the policy builder script also use
semanage port -a -t ABCD_port_t -p tcp 1234 2>/dev/null || semanage port -m -t ABCD_port_t -p tcp 1234 2>/dev/null
What I see with my current policy (with SELinux in Enforcing mode), is that the module starts up seemingly okay, it binds to the appropriate port, but see errors like this:
2019-03-19T16:08:14.314+0100 ERROR HTTP server error when serving connection "172.16.0.90:5986 http://172.16.0.90:5986"<->"172.16.0.92:53952 http://172.16.0.92:53952": error when reading request headers: read tcp4 172.16.0.90:5986->172.16.0.92:53952 http://172.16.0.92:53952: read: permission denied 2019-03-19T16:08:14.315+0100 ERROR HTTP server error when serving connection "172.16.0.90:5986 http://172.16.0.90:5986"<->"172.16.0.92:53953 http://172.16.0.92:53953": error when reading request headers: read tcp4 172.16.0.90:5986->172.16.0.92:53953 http://172.16.0.92:53953: read: permission denied
In addition to this, I see nothing in the SELinux audit log, and when I put SELinux in permissive mode, things start working again. I am puzzled at this point why I'm not seeing anything in audit.log. If it is in deed SELinux that's blocking the read attempts, then there should be some information about that. Right?
You may try to disable DONTAUDIT rules temporarily and see if you receive any clues in the audit log:
semodule -DB
Then you are done turn it off:
semodule -B
Dear Oleg,
Thank you, that seems to have done the trick. The necessary modifications for the policy were the following:
allow ABCD_t self:unix_dgram_socket { create connect getattr setopt read write }; allow ABCD_t self:tcp_socket { accept bind create getattr listen setopt read write };
Thanks again!
Best Regards, János Szigetvári -- Janos SZIGETVARI RHCE, License no. 150-053-692 https://www.redhat.com/rhtapps/verify/?certId=150-053-692
LinkedIn: linkedin.com/in/janosszigetvari E-mail: janos@szigetvari.com, jszigetvari@gmail.com Phone: +36209440412 (Hungary)
__@__˚V˚ Make the switch to open (source) applications, protocols, formats now: - windows -> Linux, iexplore -> Firefox, msoffice -> LibreOffice - msn -> jabber protocol (Pidgin, Google Talk) - mp3 -> ogg, wmv -> ogg, jpg -> png, doc/xls/ppt -> odt/ods/odp
Oleg Cherkasov o1e9.cherkasov@yandex.com ezt írta (időpont: 2019. márc. 19., K, 21:37):
On 19.03.2019 21:23, SZIGETVÁRI János wrote:
Dear Members,
Sorry for bothering you with my questions but I am kind of stuck with my problem, that's why I turn to you now.
I am in the process of creating a SELinux policy for a software module, of a larger application. The module is simply a server, that listens on a port, and forwards the received information through a Unix domain socket to the main
application.
I got most parts of the policy right by now, in the sense that the module can start, and I don't see any AVC denied entries in the SELinux audit log.
The relevant parts of my policy are the following (I have substituted the module's name with ABCD):
type ABCD_t; type ABCD_port_t;
corenet_port(ABCD_port_t);
corenet_tcp_bind_generic_node(ABCD_t); corenet_tcp_sendrecv_generic_node(ABCD_t); corenet_tcp_sendrecv_generic_if(ABCD_t); allow ABCD_t ABCD_port_t:tcp_socket { name_bind };
allow ABCD_t self:unix_dgram_socket { create connect getattr setopt }; allow ABCD_t self:tcp_socket { accept bind create getattr listen setopt
};
In the policy builder script also use
semanage port -a -t ABCD_port_t -p tcp 1234 2>/dev/null || semanage port -m -t ABCD_port_t -p tcp 1234 2>/dev/null
What I see with my current policy (with SELinux in Enforcing mode), is that the module starts up seemingly okay, it binds to the appropriate port, but see errors like this:
2019-03-19T16:08:14.314+0100 ERROR HTTP server error when serving connection "172.16.0.90:5986 http://172.16.0.90:5986"<->"172.16.0.92:53952 http://172.16.0.92:53952": error when reading request headers: read tcp4 172.16.0.90:5986->172.16.0.92:53952 http://172.16.0.92:53952: read: permission denied 2019-03-19T16:08:14.315+0100 ERROR HTTP server error when serving connection "172.16.0.90:5986 http://172.16.0.90:5986"<->"172.16.0.92:53953 http://172.16.0.92:53953": error when reading request headers: read tcp4 172.16.0.90:5986->172.16.0.92:53953 http://172.16.0.92:53953: read: permission denied
In addition to this, I see nothing in the SELinux audit log, and when I put SELinux in permissive mode, things start working again. I am puzzled at this point why I'm not seeing anything in audit.log. If it is in deed SELinux that's blocking the read attempts, then there should be some information about that. Right?
You may try to disable DONTAUDIT rules temporarily and see if you receive any clues in the audit log:
semodule -DB
Then you are done turn it off:
semodule -B _______________________________________________ selinux mailing list -- selinux@lists.fedoraproject.org To unsubscribe send an email to selinux-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/selinux@lists.fedoraproject.or...
On 3/20/19 7:10 AM, SZIGETVÁRI János wrote:
Dear Oleg,
Thank you, that seems to have done the trick. The necessary modifications for the policy were the following:
allow ABCD_t self:unix_dgram_socket { create connect getattr setopt read write}; allow ABCD_t self:tcp_socket { accept bind create getattr listen setopt read write };
Thanks again!
Obvious question is why are these being dontaudit'd by Fedora policy.
Best Regards, János Szigetvári -- Janos SZIGETVARI RHCE, License no. 150-053-692 https://www.redhat.com/rhtapps/verify/?certId=150-053-692
LinkedIn: linkedin.com/in/janosszigetvari http://linkedin.com/in/janosszigetvari E-mail: janos@szigetvari.com mailto:janos@szigetvari.com, jszigetvari@gmail.com mailto:jszigetvari@gmail.com Phone: +36209440412 (Hungary)
__@__˚V˚ Make the switch to open (source) applications, protocols, formats now:
- windows -> Linux, iexplore -> Firefox, msoffice -> LibreOffice
- msn -> jabber protocol (Pidgin, Google Talk)
- mp3 -> ogg, wmv -> ogg, jpg -> png, doc/xls/ppt -> odt/ods/odp
Oleg Cherkasov <o1e9.cherkasov@yandex.com mailto:o1e9.cherkasov@yandex.com> ezt írta (időpont: 2019. márc. 19., K, 21:37):
On 19.03.2019 21:23, SZIGETVÁRI János wrote: > Dear Members, > > Sorry for bothering you with my questions but I am kind of stuck with my > problem, that's why I turn to you now. > > I am in the process of creating a SELinux policy for a software module, > of a larger application. > The module is simply a server, that listens on a port, and forwards the > received information through a Unix domain socket to the main application. > I got most parts of the policy right by now, in the sense that the > module can start, and I don't see any AVC denied entries in the SELinux > audit log. > > The relevant parts of my policy are the following (I have substituted > the module's name with ABCD): > > type ABCD_t; > type ABCD_port_t; > > corenet_port(ABCD_port_t); > > corenet_tcp_bind_generic_node(ABCD_t); > corenet_tcp_sendrecv_generic_node(ABCD_t); > corenet_tcp_sendrecv_generic_if(ABCD_t); > allow ABCD_t ABCD_port_t:tcp_socket { name_bind }; > > allow ABCD_t self:unix_dgram_socket { create connect getattr setopt }; > allow ABCD_t self:tcp_socket { accept bind create getattr listen setopt }; > > > In the policy builder script also use > > semanage port -a -t ABCD_port_t -p tcp 1234 2>/dev/null || semanage port > -m -t ABCD_port_t -p tcp 1234 2>/dev/null > > > What I see with my current policy (with SELinux in Enforcing mode), is > that the module starts up seemingly okay, it binds to the appropriate > port, but see errors like this: > > 2019-03-19T16:08:14.314+0100 ERROR HTTP server error when > serving connection "172.16.0.90:5986 <http://172.16.0.90:5986> > <http://172.16.0.90:5986>"<->"172.16.0.92:53952 <http://172.16.0.92:53952> > <http://172.16.0.92:53952>": error when reading request headers: read > tcp4 172.16.0.90:5986->172.16.0.92:53952 <http://172.16.0.92:53952> <http://172.16.0.92:53952>: > read: permission denied > 2019-03-19T16:08:14.315+0100 ERROR HTTP server error when > serving connection "172.16.0.90:5986 <http://172.16.0.90:5986> > <http://172.16.0.90:5986>"<->"172.16.0.92:53953 <http://172.16.0.92:53953> > <http://172.16.0.92:53953>": error when reading request headers: read > tcp4 172.16.0.90:5986->172.16.0.92:53953 <http://172.16.0.92:53953> <http://172.16.0.92:53953>: > read: permission denied > > > In addition to this, I see nothing in the SELinux audit log, and when I > put SELinux in permissive mode, things start working again. > I am puzzled at this point why I'm not seeing anything in audit.log. If > it is in deed SELinux that's blocking the read attempts, then there > should be some information about that. Right? > You may try to disable DONTAUDIT rules temporarily and see if you receive any clues in the audit log: semodule -DB Then you are done turn it off: semodule -B _______________________________________________ selinux mailing list -- selinux@lists.fedoraproject.org <mailto:selinux@lists.fedoraproject.org> To unsubscribe send an email to selinux-leave@lists.fedoraproject.org <mailto:selinux-leave@lists.fedoraproject.org> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/selinux@lists.fedoraproject.org
selinux mailing list -- selinux@lists.fedoraproject.org To unsubscribe send an email to selinux-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/selinux@lists.fedoraproject.or...
Hi Stephen,
I have to admit, I forgot to mention, that I was creating the policy on RHEL 7.5, not Fedora.
Sorry about that! János
Stephen Smalley sds@tycho.nsa.gov ezt írta (időpont: 2019. márc. 20., Sze, 15:45):
Obvious question is why are these being dontaudit'd by Fedora policy.
On 3/20/19 10:56 AM, SZIGETVÁRI János wrote:
Hi Stephen,
I have to admit, I forgot to mention, that I was creating the policy on RHEL 7.5, not Fedora.
Nonetheless, the same appears to be true on Fedora. dontaudit rules for all domains obviously make it harder to debug and develop policies for new domains. They should be kept to a minimum.
I suspect these rules were to silence "noisy" denials when sockets are created without SOCK_CLOEXEC and then the process execs into a different domain. But a) in some of those cases, we probably do need/want to allow inheritance, so we need to see those denials, and b) we shouldn't silence the self case. Unfortunately we don't have a way to write rules that exclude self currently.
Sorry about that! János
Stephen Smalley <sds@tycho.nsa.gov mailto:sds@tycho.nsa.gov> ezt írta (időpont: 2019. márc. 20., Sze, 15:45):
Obvious question is why are these being dontaudit'd by Fedora policy.
Hi Stephen,
The rule is there for almost 9 years.
https://github.com/fedora-selinux/selinux-policy/commit/54f9ea9e7ccf243b0fbd...
I have no problem to remove it.
Lukas.
On 3/20/19 4:10 PM, Stephen Smalley wrote:
On 3/20/19 10:56 AM, SZIGETVÁRI János wrote:
Hi Stephen,
I have to admit, I forgot to mention, that I was creating the policy on RHEL 7.5, not Fedora.
Nonetheless, the same appears to be true on Fedora. dontaudit rules for all domains obviously make it harder to debug and develop policies for new domains. They should be kept to a minimum.
I suspect these rules were to silence "noisy" denials when sockets are created without SOCK_CLOEXEC and then the process execs into a different domain. But a) in some of those cases, we probably do need/want to allow inheritance, so we need to see those denials, and b) we shouldn't silence the self case. Unfortunately we don't have a way to write rules that exclude self currently.
Sorry about that! János
Stephen Smalley <sds@tycho.nsa.gov mailto:sds@tycho.nsa.gov> ezt írta (időpont: 2019. márc. 20., Sze, 15:45):
Obvious question is why are these being dontaudit'd by Fedora policy.
selinux mailing list -- selinux@lists.fedoraproject.org To unsubscribe send an email to selinux-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/selinux@lists.fedoraproject.or...
selinux@lists.fedoraproject.org
-
Lukas Vrabec -
Oleg Cherkasov -
Stephen Smalley -
SZIGETVÁRI János