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:
No, that's what I saw - like I said in my post, I removed some types
from the mlsconstrain statement for clarity (we don't care about the
netlink_socket, etc. at this point).
> # 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?
No, I think everything is working as it should based on the
mlsconstraints above. Perhaps a little NetLabel/socket-labeling
discussion would be a good idea ...
>>>
When a process creates a socket through a call to socket() the socket
takes the SID of the process' domain and the NetLabel is set based on
that SID. Assuming NetLabel/CIPSO is used, all data written to that
socket will be labeled with the socket's MLS label.
When a process creates a socket through a call to accept() when CIPSO
tags are present on the TCP handshake packets the child socket's SID is
a combination of the parent socket's context and the *connection's* MLS
label. All data writeen to the child socket will be labeled with the
socket/connection's MLS label.
When packets are received and a CIPSO tag is present NetLabel generates
a SID for the packet based on the receiving socket's context and the
packet's CIPSO MLS label. The packet's SID is then compared to the
socket's SID with an avc_has_perm() call, the socket's SID is the
subject the packet's SID is the object.
All reads/writes to and from a socket or file descriptor behave as they
always have, the process' SID is checked against the socket/fd's SID,
the process' SID is the subject and the socket/fd's SID is the object.
>>>
Does this make things a bit more clear?
> The enforcement is actually the other way around, a s3-s3 process is not
> permitted to connect(2) to a s2-s2 port.
Which is still correct I believe. Yes?
--
paul moore
linux security @ hp
--
redhat-lspp mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/redhat-lspp
