[redhat-lspp] Updated NetLabel/CIPSO policy module

Klaus Weidner klaus at atsec.com
Thu Aug 31 17:20:29 UTC 2006


On Thu, Aug 31, 2006 at 08:57:05AM -0400, Paul Moore wrote:
> Klaus Weidner wrote:
> > I was a bit surprised that a "s2-s2" process can connect successfully to
> > a "s3-s3" process, send it data, and select/poll(2) waiting for data.
[...]
> > It works as expected the other way around, the s3 process gets an
> > immediate "connection refused" when trying to connect to the s2 process.
> 
> This smells like a policy issue to me.  Taking a quick look at the
> reference policy mls constraints (this is from a svn snapshot which is
> probably a month or two old, so it may have changed) I see the following
> constraint (unrelated types removed for clarity):

It's a bit more complex now:

# the socket "read" ops (note the check is dominance of the low level)
mlsconstrain { socket tcp_socket udp_socket rawip_socket netlink_socket packet_socket key_socket unix_stream_socket unix_dgram_socket netlink_route_socket netlink_firewall_socket netlink_tcpdiag_socket netlink_nflog_socket netlink_xfrm_socket netlink_selinux_socket netlink_audit_socket netlink_ip6fw_socket netlink_dnrt_socket } { read getattr listen accept getopt recvfrom recv_msg }
        (( l1 dom l2 ) or
         (( t1 == mlsnetreadtoclr ) and ( h1 dom l2 )) or
         ( t1 == mlsnetread ));

# the socket "write" ops
mlsconstrain { socket tcp_socket udp_socket rawip_socket netlink_socket packet_socket key_socket unix_stream_socket unix_dgram_socket netlink_route_socket netlink_firewall_socket netlink_tcpdiag_socket netlink_nflog_socket netlink_xfrm_socket netlink_selinux_socket netlink_audit_socket netlink_ip6fw_socket netlink_dnrt_socket } { write setattr relabelfrom connect setopt shutdown }
        ((( l1 dom l2 ) and ( l1 domby h2 )) or
         (( t1 == mlsnetwritetoclr ) and ( h1 dom l2 ) and ( l1 domby l2 )) or
         ( t1 == mlsnetwrite ));

Based on that policy, I'd expect the constraint on "connect" to prevent a
l1=s2,h1=s2 process from connecting to a l2=s2,h2=s2 port. Am I
misunderstanding something or is the check mixed up?

The enforcement is actually the other way around, a s3-s3 process is not
permitted to connect(2) to a s2-s2 port.

-Klaus




More information about the redhat-lspp mailing list