Venkat Yekkirala wrote:
FYI- I have posted the following patches separate from this one.
1. A patch to address the "leask" issue. Once verified, it needs
to be rolled in with James' patch and sent on after verification.
2. A fix for flow_in and flow_out where we were using the unlabeled
init sid. We would now use a new network_t with a range of (s0-s15...)
to allow for mls traffic to flow out/in, in the absence of explicit secmark
rules.
The following is a sample patch for networking using the new controls
in conjunction with secmark.
NOTE FOR JOSHUA: This patch also defines the constraints to force context
equality for association:sendto.
I couldn't readily figure out where to stick these in, but these would
help the system come up without any denials.
Ok, this may be an unpopular email but I was going over how everything
(sans netlabel) was working as of right now (as I understand it) and I
came across some things that seem strange. Maybe my understanding is
wrong...
Basically I was trying the most complex situation (which includes socket
labels that are different from the domain).
spd 1 is ipsec_spd_t.
domain 1 is pms_proxy_t
socket 1 is sysadm_t (via setsockcreatecon)
secmark 1 is pms_c_p_t
spd 2 is ipsec_spd2_t
domain 2 is inetd_t
socket 2 is pms_t
secmark 2 is pms_s_p_t
therefore SA 1 is pms_t and SA 2 is sysadm_t
So here are the rules I came up with
side1:
allow pms_proxy_t pms_c_p_t : packet { send recv }
- straightforward, already how secmark works
allow sysadm_t pms_t : packet { flow_in flow_out }
- don't understand this, pms_t isn't a packet object, why are we using
the packet object class?
allow pms_proxy_t ipsec_spd_t : association { polmatch }
- likewise, an spd isn't an association, maybe this class needs to be
more generic
allow pms_proxy_t pms_t : association { sendto recvfrom }
- Not sure if this one is right, is the source suppose to be the domain
or the socket?
side2:
allow inetd_t pms_s_p_t : packet {send recv }
allow pms_t sysadm_t : packet { flow_in flow_out }
allow inetd_t ipsec_spd2_t : association { polmatch }
allow inetd_t sysadm_t : association { sendto recvfrom }
do these rules seem correct given the scenerio above?
If so there seems to be some object class confusion.
--
redhat-lspp mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/redhat-lspp
