Klaus Weidner wrote:
> On Mon, Aug 07, 2006 at 03:37:00PM -0400, Paul Moore wrote:
>
>>I spent an hour this afternoon with the latest NetLabel patch and Klaus'
>>original "toy" policy module trying to "flesh it out a bit". The
>>resulting policy file is attached (as well as a simple Makefile to build
>>and install the module). I will caution people that I haven't done much
>>testing with this new policy module yet but what I have done, mostly
>>running 'netlabelctl' seems to work well enough.
>
> I've updated this to work with current kernel + policy - it needs
> additional permissions for port_t and name_bind. Diff (plus patched files
> for reference) attached.
Thanks for the update as well as the help testing.
> 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.
> Select will tell it when the s3 process sent data, and when it tries to
> read that data read(2) will return 0 which the program interprets as EOF.
> I was expecting the connect to fail. This way it permits "write up"
> operations (which are compatible with LSPP but frowned upon), and it
> looks like a covert channel.
>
> 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):
>>>
# the socket "read" ops (note the check is dominance of the low level)
mlsconstrain { tcp_socket udp_socket } { read getattr listen accept
getopt recvfrom recv_msg }
(( l1 dom l2 ) or
(( t1 == mlsnetreadtoclr ) and ( h1 dom l2 )) or
( t1 == mlsnetread ));
>>>
If I understand this correctly it means that as long as the domain's MLS
level, 'l1', dominates the object's MLS level, 'l2', the access is
allowed. In the case of a 's2-s2' process connecting to a 's3-s3'
daemon, the daemon's MLS level, 's3', would dominate the packet's MLS
level, 's2', so the connection would be allowed.
Perhaps the policy guru's could weigh in on the issue ...
--
paul moore
linux security @ hp
--
redhat-lspp mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/redhat-lspp
