binding and listening to port work with SELinux, but the process is unable receive data from clients

[SZIGETVÁRI János]

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(a)szigetvari.com, jszigetvari(a)gmail.com
Phone: [phone] (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]

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

[SZIGETVÁRI János]

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(a)szigetvari.com, jszigetvari(a)gmail.com
Phone: [phone] (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(a)yandex.com&gt; 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(a)lists.fedoraproject.org
>  To unsubscribe send an email to selinux-leave(a)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/[e-mail]...
>

[Stephen Smalley]

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(a)szigetvari.com <mailto:[e-mail]>, 
>  jszigetvari(a)gmail.com <mailto:[e-mail]>
>  Phone: [phone] (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(a)yandex.com 
>  <mailto:[e-mail]>> 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(a)lists.fedoraproject.org
>      <mailto:[e-mail]>
>      To unsubscribe send an email to
>      selinux-leave(a)lists.fedoraproject.org
>      <mailto:[e-mail]>
>      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/[e-mail]...
>  
>  
>  _______________________________________________
>  selinux mailing list -- selinux(a)lists.fedoraproject.org
>  To unsubscribe send an email to selinux-leave(a)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/[e-mail]...
>

[SZIGETVÁRI János]

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(a)tycho.nsa.gov&gt; ezt írta (időpont: 2019. márc. 20.,
Sze, 15:45):

>  Obvious question is why are these being dontaudit'd by Fedora policy.
>

[Stephen Smalley]

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(a)tycho.nsa.gov <mailto:[e-mail]>> ezt írta 
>  (időpont: 2019. márc. 20., Sze, 15:45):
>  
>  
>      Obvious question is why are these being dontaudit'd by Fedora policy.
>

[Lukas Vrabec]

Hi Stephen,

The rule is there for almost 9 years.

https://github.com/fedora-selinux/selinux-policy/commit/54f9ea9e7ccf243b0...

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(a)tycho.nsa.gov <mailto:[e-mail]>> 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(a)lists.fedoraproject.org
>  To unsubscribe send an email to selinux-leave(a)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/[e-mail]...
>   

-- 
Lukas Vrabec
Senior Software Engineer, Security Technologies
Red Hat, Inc.