On Mon, Jul 27, 2020 at 11:39 AM Dominick Grift <dominick.grift@xxxxxxxxxxx> wrote: > Topi Miettinen <toiwoton@xxxxxxxxx> writes: > > I'm no expert, but the only netif ingress rules which I have are > > rather generic: > > > > allow internet_peer_t external_if_t:netif ingress; > > allow link_local_peer_t external_if_t:netif ingress; > > allow localnet_peer_t external_if_t:netif ingress; > > allow multicast_peer_t external_if_t:netif ingress; > > allow loopback_peer_t loopback_if_t:netif ingress; > > > > `peer` types above have been added with NetLabel rules like: > > > > netlabelctl unlbl add default address:2000::/3 > > label:system_u:object_r:internet_peer_t:s0 > > > > Perhaps this would be better: > > > > Note that reception for application domains can't be controlled with > > `netif` class. > > > > I look at it this way: peers *are* processes, You seem to > essentually use peers as nodes above. Peer labels are essentially process labels (that isn't 100% correct, but it is close enough for this particular discussion). In the netif/ingress access control, the subject is the peer label of the *remote* peer, not the receiving process on the local system. If you were running a web server on your system under httpd_t and a remote node connected to your web server with firefox running under firefox_t, you would need the following netif/ingress rule: allow firefox_t external_if_t:netif ingress; You will note that it is firefox_t and *not* httpd_t as the subject. > It would become more clear if you would try this out with labeled ipsec. > A peer, in my experience is kind of the same as an association in the > labeled ipsec scenario (the classes actually overlap). That is also why > you should probably disable the netlabel_peer_controls polcap if you use > labeled ipsec. -- paul moore www.paul-moore.com
