2009-02-12 21:15:26

by Paul Moore

[permalink] [raw]
Subject: [refpolicy] [PATCH] refpolicy: Add missing network related MLS constraints

An embedded and charset-unspecified text was scrubbed...
Name: netpeer-constraints
Url: http://oss.tresys.com/pipermail/refpolicy/attachments/20090212/5b32db6c/attachment.pl


2009-02-21 01:37:30

by joe

[permalink] [raw]
Subject: [refpolicy] [PATCH] refpolicy: Add missing network related MLS constraints


On Feb 12, 2009, at 3:15 PM, Paul Moore wrote:

> Add MLS constraints for several network related access controls
> including
> the new ingress/egress controls and the older Secmark controls.
> Based on
> the following post to the SELinux Reference Policy mailing list:
>
> * http://oss.tresys.com/pipermail/refpolicy/2009-February/000579.html
>
> Signed-off-by: Paul Moore <[email protected]>
>
> ---
> policy/mls | 51 +++++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 51 insertions(+)
>
> Index: refpolicy_svn_repo/policy/mls
> ===================================================================
> --- refpolicy_svn_repo.orig/policy/mls
> +++ refpolicy_svn_repo/policy/mls
> @@ -295,8 +295,59 @@ mlsconstrain { netif node } { tcp_send u
> # these access vectors have no MLS restrictions
> # node enforce_dest
>
> +#
> +# MLS policy for the network ingress/egress controls
> +#
>
> +# the netif ingress/egress ops, the ingress permission is a "write"
> operation
> +# because the subject in this particular case is the remote domain
> which is
> +# writing data out the network interface which is acting as the
> object
> +mlsconstrain { netif } { ingress }
> + (( l1 eq l2 ) or
> + (( t1 == mlsnetwriteranged ) and ( l1 dom l2 ) and ( l1 domby
> h2 )) or
> + (( t1 == mlsnetwritetoclr ) and ( h1 dom l2 ) and ( l1 domby
> l2 )) or
> + ( t1 == mlsnetwrite ) or
> + ( t1 == unlabeled_t ));
> +mlsconstrain { netif } { egress }
> + (( l1 eq l2 ) or
> + (( t1 == mlsnetwriteranged ) and ( l1 dom l2 ) and ( l1 domby
> h2 )) or
> + (( t1 == mlsnetwritetoclr ) and ( h1 dom l2 ) and ( l1 domby
> l2 )) or
> + ( t1 == mlsnetwrite ));

How do processes talk to each other on local netlabel interfaces? lo
for example is s0-s15:c1.c1023, any process above s0 would fail the
test above communicating on localhost. I don't think that was the
intent.

type=AVC msg=audit(1235141104.160:134): avc: denied { egress } for
pid=2980 comm="InputLog" saddr=172.16.142.134 src=10308
daddr=172.16.142.134 dest=52831 netif=lo
scontext=system_u:system_r:jcdx_icm_t:s6:c0.c511
tcontext=system_u:object_r:lo_netif_t:s0-s15:c0.c1023 tclass=netif
type=AVC msg=audit(1235141104.160:134): avc: denied { sendto } for
pid=2980 comm="InputLog" saddr=172.16.142.134 src=10308
daddr=172.16.142.134 dest=52831 netif=lo
scontext=system_u:system_r:jcdx_icm_t:s6:c0.c511
tcontext=system_u:object_r:node_t:s0-s15:c0.c1023 tclass=node

type=AVC msg=audit(1235177156.260:499): avc: denied { ingress } for
pid=2923 comm="QManager" saddr=172.16.142.134 src=8998
daddr=172.16.142.134 dest=34245 netif=lo
scontext=system_u:system_r:jcdx_qm_t:s15:c0.c1023
tcontext=system_u:object_r:lo_netif_t:s0-s15:c0.c1023 tclass=netif
type=AVC msg=audit(1235177156.260:499): avc: denied { recvfrom }
for pid=2923 comm="QManager" saddr=172.16.142.134 src=8998
daddr=172.16.142.134 dest=34245 netif=lo
scontext=system_u:system_r:jcdx_qm_t:s15:c0.c1023
tcontext=system_u:object_r:node_t:s0-s15:c0.c1023 tclass=node

I have avcs like the ones above for every pair of processes that are
using IP to connect to each other after applying the patch.

where 172.16.142.134 is:
# netlabelctl -p map list
Configured NetLabel domain mappings (1)
domain: DEFAULT
address: 127.0.0.1/32
protocol: CIPSOv4, DOI = 2
address: 172.16.142.134/32
protocol: CIPSOv4, DOI = 2
address: 0.0.0.0/0
protocol: UNLABELED

joe


>
>
> +# the node recvfrom/sendto ops, the recvfrom permission is a
> "write" operation
> +# because the subject in this particular case is the remote domain
> which is
> +# writing data out the network node which is acting as the object
> +mlsconstrain { node } { recvfrom }
> + (( l1 eq l2 ) or
> + (( t1 == mlsnetwriteranged ) and ( l1 dom l2 ) and ( l1 domby
> h2 )) or
> + (( t1 == mlsnetwritetoclr ) and ( h1 dom l2 ) and ( l1 domby
> l2 )) or
> + ( t1 == mlsnetwrite ) or
> + ( t1 == unlabeled_t ));
> +mlsconstrain { node } { sendto }
> + (( l1 eq l2 ) or
> + (( t1 == mlsnetwriteranged ) and ( l1 dom l2 ) and ( l1 domby
> h2 )) or
> + (( t1 == mlsnetwritetoclr ) and ( h1 dom l2 ) and ( l1 domby
> l2 )) or
> + ( t1 == mlsnetwrite ));
> +
> +# the forward ops, the forward_in permission is a "write" operation
> because the
> +# subject in this particular case is the remote domain which is
> writing data
> +# to the network with a secmark label, the object in this case
> +mlsconstrain { packet } { forward_in forward_out }
> + (( l1 eq l2 ) or
> + (( t1 == mlsnetwriteranged ) and ( l1 dom l2 ) and ( l1 domby
> h2 )) or
> + (( t1 == mlsnetwritetoclr ) and ( h1 dom l2 ) and ( l1 domby
> l2 )) or
> + ( t1 == mlsnetwrite ) or
> + ( t1 == unlabeled_t ));
> +
> +#
> +# MLS policy for the secmark and peer controls
> +#
> +
> +# the peer/packet recv op
> +mlsconstrain { peer packet } { recv }
> + (( l1 dom l2 ) or
> + (( t1 == mlsnetreadtoclr ) and ( h1 dom l2 )) or
> + ( t1 == mlsnetread ));
>
> #
> # MLS policy for the process class
>
> --
> paul moore
> linux @ hp
>
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy

2009-02-23 17:37:51

by Paul Moore

[permalink] [raw]
Subject: [refpolicy] [PATCH] refpolicy: Add missing network related MLS constraints

On Friday 20 February 2009 08:37:30 pm Joe Nall wrote:
> How do processes talk to each other on local netlabel interfaces? lo
> for example is s0-s15:c1.c1023, any process above s0 would fail the
> test above communicating on localhost. I don't think that was the
> intent.

I suppose first things first: did you see the new patch posted on Friday
(February 20th)? It changed the constraints quite a bit based on feedback on
the lists. Please take a look at that patch and see if it looks okay to you,
if not please yell loudly :)

--
paul moore
linux @ hp