IPSec and netlabel sockets behave differently if the ranges of the two
sides of the connection are not identical. In the netlabel denial
below, InputLog is single level and has no mls attributes, icm is
ranged and has mlsnetread. This works with labeled IPSec.
type=AVC msg=audit(1220880975.110:308): avc: denied { recvfrom }
for pid=2341 comm="InputLog" saddr=192.168.20.247 src=10308
daddr=192.168.20.247 dest=60897 netif=lo
scontext=system_u:system_r:jcdx_ilog_t:s5:c0.c511
tcontext=system_u:system_r:jcdx_icm_t:s0-s15:c0.c1023 tclass=tcp_socket
The source of the difference is in the recvfrom constraint. From
policy/mls:
...
mlsconstrain association { recvfrom }
((( l1 dom l2 ) and ( l1 domby h2 )) or
(( t1 == mlsnetreadtoclr ) and ( h1 dom l2 )) or
( t1 == mlsnetread ) or
( t2 == unlabeled_t ));
...
# used by netlabel to restrict normal domains to same level connections
mlsconstrain { tcp_socket udp_socket rawip_socket } recvfrom
(( l1 eq l2 ) or
(( t1 == mlsnetreadtoclr ) and ( h1 dom l2 )) or
( t1 == mlsnetread ));
...
If I use
# used by netlabel to restrict normal domains to same level connections
mlsconstrain { tcp_socket udp_socket rawip_socket } recvfrom
((( l1 dom l2 ) and ( l1 domby h2 )) or
(( t1 == mlsnetreadtoclr ) and ( h1 dom l2 )) or
( t1 == mlsnetread ));
...
then netlabel sockets behave like their IPSec brethren.
Is the difference intentional?
What purpose does the ( l1 domby h2 ) serve?
Should there be a netlabel constraint on sendto to match the IPSec
sendto constraint?
joe
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with
the words "unsubscribe selinux" without quotes as the message.
