[redhat-lspp] Updated NetLabel/CIPSO policy module

Stephen Smalley sds at tycho.nsa.gov
Fri Sep 1 13:27:18 UTC 2006


On Fri, 2006-09-01 at 08:55 -0400, Paul Moore wrote:
> Stephen Smalley wrote:
> > On Thu, 2006-08-31 at 12:20 -0500, Klaus Weidner wrote:
> >>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?
> > 
> > connect is a process-to-socket check handled entirely in the socket
> > layer, i.e. can process A initiate a connection via socket S (where S is
> > its local endpoint, not the peer).  It isn't a check on the peer.
> > 
> > recv_msg is likely the one of interest to you for NetLabel.  You could
> > separate out the mls constraint on tcp_socket to require equivalence for
> > recv_msg in that case (overloading with old net controls is bad though).
> 
> I know we've talked about this before and decided to stick with using
> recv_msg ... does it make sense to introduce a new permission, say
> nlbl_recv?  Or do we just not care because of the secid reconciliation work?

Hmmm...I thought that my guidance had been to use one of the obsoleted
permissions in the socket class that was no longer in use by the kernel,
like recvfrom (in common socket, different from association recvfrom).
Of course, if secmark is enabled, then recv_msg is likewise "obsoleted".

-- 
Stephen Smalley
National Security Agency




More information about the redhat-lspp mailing list