Joshua Brindle wrote:
<snip>
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?
Er, I totally messed this up, it should have been
allow pms_t pms_c_p_t : packet { flow_in flow_out } which has the
correct object class, not sure what I was thinking
allow pms_proxy_t ipsec_spd_t : association { polmatch }
- likewise, an spd isn't an association, maybe this class needs to be
more generic
this one still applies but its an aesthetic thing and I suppose noone is
going to want to rename the object class
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?
This is domain, right?
--
redhat-lspp mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/redhat-lspp
