On Fri, 2006-09-01 at 09:27 -0400, Stephen Smalley wrote:
> 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".
I suggest recvfrom, as it has been unused since 2003, whereas recv_msg
is just starting on its way out.
--
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150
--
redhat-lspp mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/redhat-lspp
