selinux network control question

selinux network control question

[Dominick Grift]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

I am trying to clean up my network policy module but some things are
unclear. Could anyone shine some light (or correct me) on the below:

1.
network interface labels are no longer checked in any scenario (secmark,
netlabel, labeled-ipsec) and the netif isid is no longer used.

So i can remove my netif types and associate the netif isid with a
context reserved for unused isids?

2.
Above also applies to node labels (ie. nodes are no longer checked in
any scenarion (secmark, netlabel, labeled-ipset)

The question is then why is the node isid still working. And why do i
need to allow some processes to bind to nodes with the context
associated with the node isid?

why is the node isid still used?

3. packets are checked with secmark, and you can associate different
packet types with different packets)

4. peers are checked with netlabel, but you only need on peer type
(ie. you can't associate different peer types with different peers)

- -- 
02DFF788
4D30 903A 1CF3 B756 FB48  1514 3148 83A2 02DF F788
https://sks-keyservers.net/pks/lookup?op=get&search=0x314883A202DFF788
Dominick Grift
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQGcBAEBCgAGBQJWBWUbAAoJENAR6kfG5xmciHEL/iRIF1VO4uLwgabP3+YEhw80
exC7tyGPy/qKpYUOB9RWjdzRNVdGYIxj2rYpGRNsTJQXWkdEGcQBkMVsF1YeAJsi
55jtPcyc0R+pcn7abo9FbdeSUtx1Xd99ji6ZajOl0A39PauzMzxYFOE2F6bnVUKn
0C7MgiXCxN2SLya6//v3ZniszwSlEqLrUTkvoaUr92SLbQqUay9xpOhUaGqrwid9
5i6lKnuFihuQEhMuv8OgXfEPjY9WnY/m1MK7LUtU3xvMH6CaQEkuvm/KYwhzwjJG
f+wc4dyOX5Ap7W5o10wAcmpcVM3w11mocBt+dkYLXzZkpYFi3GZK3zI4yzRFUEVf
tWFspmE30PhAbvpzBSA82k3M5EB66pGYr1gja+I6BC0Ali2Booz8uaGp64SpqNOO
8hlinJu2ZLCq/00NVOITOgzVGUCGMeG2f6U2quze7DJvrIGpnQ1QIEJIPCtBiP8K
sY2D4CU+Q587oSueHRf9sxqZmvPUJiNx0zhdIRPnAA==
=uvyT
-----END PGP SIGNATURE-----

Re: selinux network control question

[Stephen Smalley]

On 09/25/2015 11:15 AM, Dominick Grift wrote:
> I am trying to clean up my network policy module but some things are
> unclear. Could anyone shine some light (or correct me) on the below:
> 
> 1.
> network interface labels are no longer checked in any scenario (secmark,
> netlabel, labeled-ipsec) and the netif isid is no longer used.
> 
> So i can remove my netif types and associate the netif isid with a
> context reserved for unused isids?

netif SIDs are used by the egress/ingress permission checks (which are only active if using peer labeling).

> 2.
> Above also applies to node labels (ie. nodes are no longer checked in
> any scenarion (secmark, netlabel, labeled-ipset)
> 
> The question is then why is the node isid still working. And why do i
> need to allow some processes to bind to nodes with the context
> associated with the node isid?
> 
> why is the node isid still used?

node SIDs are used in checks on bind(2) and for sendto/recvfrom checks (also only if using peer labeling).

> 3. packets are checked with secmark, and you can associate different
> packet types with different packets)

secmark allows local/internal labeling of packets via iptables and access control over them based on those labels.

> 4. peers are checked with netlabel, but you only need on peer type
> (ie. you can't associate different peer types with different peers)

peer labeling can be based on labeled IPSEC or netlabel.
NetLabel can only pass MLS labels across the network, although it can convey full contexts locally (see the selinux-testsuite for a configured example under tests/inet_socket or the SELinux Notebook for further examples).
Labeled IPSEC can pass full labels locally or across the network (ditto).

Re: selinux network control question

[Dominick Grift]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On Fri, Sep 25, 2015 at 11:27:48AM -0400, Stephen Smalley wrote:
> On 09/25/2015 11:15 AM, Dominick Grift wrote:
> > I am trying to clean up my network policy module but some things are
> > unclear. Could anyone shine some light (or correct me) on the below:
> > 
> > 1.
> > network interface labels are no longer checked in any scenario (secmark,
> > netlabel, labeled-ipsec) and the netif isid is no longer used.
> > 
> > So i can remove my netif types and associate the netif isid with a
> > context reserved for unused isids?
> 
> netif SIDs are used by the egress/ingress permission checks (which are only active if using peer labeling).

so netifcon is still useful (albeit only with peer labeling) ?

> 
> > 2.
> > Above also applies to node labels (ie. nodes are no longer checked in
> > any scenarion (secmark, netlabel, labeled-ipset)
> > 
> > The question is then why is the node isid still working. And why do i
> > need to allow some processes to bind to nodes with the context
> > associated with the node isid?
> > 
> > why is the node isid still used?
> 
> node SIDs are used in checks on bind(2) and for sendto/recvfrom checks (also only if using peer labeling).
>

so nodecon is still useful (albeit with using peer labeling) ?

What i do not understand and find inconsistent is: why do i need to
allow processes that bind(2) to bind nodes associated with the
context associated with the node isid regardless, but nodecon is not
honored without using peer labeling 

> > 3. packets are checked with secmark, and you can associate different
> > packet types with different packets)
> 
> secmark allows local/internal labeling of packets via iptables and access control over them based on those labels.
>

So only packet labels apply to secmark

> > 4. peers are checked with netlabel, but you only need on peer type
> > (ie. you can't associate different peer types with different peers)
> 
> peer labeling can be based on labeled IPSEC or netlabel.
> NetLabel can only pass MLS labels across the network, although it can convey full contexts locally (see the selinux-testsuite for a configured example under tests/inet_socket or the SELinux Notebook for further examples).
> Labeled IPSEC can pass full labels locally or across the network (ditto).

So i only need a single "peer type" (the one associated with the peer isid)


It is a bit confusing to me, the more because i do not use these
technologies but i want to support them with my policy.

- -- 
02DFF788
4D30 903A 1CF3 B756 FB48  1514 3148 83A2 02DF F788
https://sks-keyservers.net/pks/lookup?op=get&search=0x314883A202DFF788
Dominick Grift
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQGcBAEBCgAGBQJWBWwUAAoJENAR6kfG5xmcQZ8L/20Dua/mYrwNgbdIlKgsD+Hz
5511SyuGQ/Mx1tIXLJYIQsr46W5mpeMB0RqTcvIMAdQsKDE6MXE3omA8TQu+oPRl
VpcKKFSHtOhTouD7MHRny/6KjVEB3YrPZZNOSMB+t8JpAF0s/yfkQf4yNYUY+S/O
8jJMaklYNc7rKldPS8O6dz9WnCM0I00mBLwBuc+x5lhbF50Ja9ByNazepqAi6cOo
Al/shGWiszpfNjaiYMOxuzDE5ErUN54OU6RtJHtcV+BKVhImHO1qFZa1ojJMiWzk
zdQpqSGyhy195gkW0in0MSGX4E8Bp2LmLrD5cO6cJuCMb+n0L5F4sihT4e+2FUJF
de8/jX2jnlAJkaHzu6P+Ubx1+DMmlQUWZ/ZuK0+Y5peJTbGN9fuz1Rt/Zy89cDzg
LkIB2O1VT4DmbovGQfkKLBjvVUU07bijj96HQQTR86hHByRA6JCUwej07Yj51xBE
NciKsz62tJyspKAjX0EF3d2BORY28KAueF11JZFr9Q==
=TwuT
-----END PGP SIGNATURE-----

Re: selinux network control question

[Dominick Grift]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On Fri, Sep 25, 2015 at 11:27:48AM -0400, Stephen Smalley wrote:
> On 09/25/2015 11:15 AM, Dominick Grift wrote:
> > I am trying to clean up my network policy module but some things are
> > unclear. Could anyone shine some light (or correct me) on the below:
> > 
> > 1.
> > network interface labels are no longer checked in any scenario (secmark,
> > netlabel, labeled-ipsec) and the netif isid is no longer used.
> > 
> > So i can remove my netif types and associate the netif isid with a
> > context reserved for unused isids?
> 
> netif SIDs are used by the egress/ingress permission checks (which are only active if using peer labeling).
> 

Thanks, It is clear now. I was not paying attention, and after thinking
about it some more and looking up some things it became clear.

- -- 
02DFF788
4D30 903A 1CF3 B756 FB48  1514 3148 83A2 02DF F788
https://sks-keyservers.net/pks/lookup?op=get&search=0x314883A202DFF788
Dominick Grift
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQGcBAEBCgAGBQJWBXSKAAoJENAR6kfG5xmcZxgL/jGeQBtQmUC2nZQpeZBZROvk
IXfn8eWtrqu1lYX3BFtRs08R8jGYDVeUoWIx0qGwRGPHc+43/k4VJYLzokmRWNN8
HCz0alXakwaM3ArL4O/y7hq2w9hYkVSF9+9wu1lYH8X0n50op9UrUWHLdORYe84m
ib/UeoD7fF5AVLHqcKZQh7+pqcDmTZNLcYfncPX1tq8CtebV08Lk6txwPrG/muH2
BJ0mYko+PUt48SwvV/KiHjcHEDHCuvk8ngik0ccD1Mv65SkNpq0v9uA8j/ZKEBA3
aGwLe1JLFk68Ul5wMCZQzKO0NjUSV1cLpIwc8Dp6aqBIWXjmzzuntEVyLpxvEFMV
x2c0zx55WxwQ7xeHKFaiD4DbHvmCwxuvlm4/IHigmbHFrLELQv/HHt2FTcRh38uQ
17rvo0UNOoYp8ZgK08ysIwEEmmpJHAbl3qJFUFwmlTOkSOUu7xcVPK8Z0J8gG/YK
9SWtEkOqRr2z8f+yQeZzQvfiNkmsY4tqWqWWWr1rGQ==
=bngt
-----END PGP SIGNATURE-----

Re: selinux network control question

[Stephen Smalley]

On 09/25/2015 11:45 AM, Dominick Grift wrote:
> On Fri, Sep 25, 2015 at 11:27:48AM -0400, Stephen Smalley wrote:
>> On 09/25/2015 11:15 AM, Dominick Grift wrote:
>>> I am trying to clean up my network policy module but some things are
>>> unclear. Could anyone shine some light (or correct me) on the below:
>>>
>>> 1.
>>> network interface labels are no longer checked in any scenario (secmark,
>>> netlabel, labeled-ipsec) and the netif isid is no longer used.
>>>
>>> So i can remove my netif types and associate the netif isid with a
>>> context reserved for unused isids?
> 
>> netif SIDs are used by the egress/ingress permission checks (which are only active if using peer labeling).
> 
> so netifcon is still useful (albeit only with peer labeling) ?

Correct.

>>> 2.
>>> Above also applies to node labels (ie. nodes are no longer checked in
>>> any scenarion (secmark, netlabel, labeled-ipset)
>>>
>>> The question is then why is the node isid still working. And why do i
>>> need to allow some processes to bind to nodes with the context
>>> associated with the node isid?
>>>
>>> why is the node isid still used?
> 
>> node SIDs are used in checks on bind(2) and for sendto/recvfrom checks (also only if using peer labeling).
> 
> 
> so nodecon is still useful (albeit with using peer labeling) ?
> 
> What i do not understand and find inconsistent is: why do i need to
> allow processes that bind(2) to bind nodes associated with the
> context associated with the node isid regardless, but nodecon is not
> honored without using peer labeling 

Only the peer-related permission checks are enabled/disabled based on whether you have peer labeling.
The node_bind check, which predates the peer labeling support, is not dependent on that.
The  other node permission checks are between peer labels and the node label, so they are dependent on peer labeling being active.

> 
>>> 3. packets are checked with secmark, and you can associate different
>>> packet types with different packets)
> 
>> secmark allows local/internal labeling of packets via iptables and access control over them based on those labels.
> 
> 
> So only packet labels apply to secmark

The packet class is for secmark-based checks.
That said, a "packet" or sk_buff logically has two labels: a packet/secmark/internal label and a peer/external label.  There can even be a check between the two in the forwarding case.

> 
>>> 4. peers are checked with netlabel, but you only need on peer type
>>> (ie. you can't associate different peer types with different peers)
> 
>> peer labeling can be based on labeled IPSEC or netlabel.
>> NetLabel can only pass MLS labels across the network, although it can convey full contexts locally (see the selinux-testsuite for a configured example under tests/inet_socket or the SELinux Notebook for further examples).
>> Labeled IPSEC can pass full labels locally or across the network (ditto).
> 
> So i only need a single "peer type" (the one associated with the peer isid)

Guessing you mean the netmsg isid here; that's for NetLabel only and only to provide a default user/role/type for CIPSO packets.  netlabelctl can be configured to specify other fallbacks.

Re: selinux network control question

[Dominick Grift]

[-- Attachment #1: Type: text/plain, Size: 1440 bytes --]

On Fri, Sep 25, 2015 at 12:25:03PM -0400, Stephen Smalley wrote:

<snip>

> > 
> >>> 4. peers are checked with netlabel, but you only need on peer type
> >>> (ie. you can't associate different peer types with different peers)
> > 
> >> peer labeling can be based on labeled IPSEC or netlabel.
> >> NetLabel can only pass MLS labels across the network, although it can convey full contexts locally (see the selinux-testsuite for a configured example under tests/inet_socket or the SELinux Notebook for further examples).
> >> Labeled IPSEC can pass full labels locally or across the network (ditto).
> > 
> > So i only need a single "peer type" (the one associated with the peer isid)
> 
> Guessing you mean the netmsg isid here; that's for NetLabel only and only to provide a default user/role/type for CIPSO packets.  netlabelctl can be configured to specify other fallbacks.
> 
>

Thanks a lot. That cleared it up for me. Yes indeed i meant netmsg isid.

I basically exposed a macro that allowed one to create additional "peer
types" earlier. So i removed that. There is now only one peer type
(peer.peer), and that is the one associated with the netmsg isid.

Pretty much everything else seems to be in order. Thanks again for your
patience and guidance

-- 
02DFF788
4D30 903A 1CF3 B756 FB48  1514 3148 83A2 02DF F788
https://sks-keyservers.net/pks/lookup?op=get&search=0x314883A202DFF788
Dominick Grift

[-- Attachment #2: Type: application/pgp-signature, Size: 648 bytes --]