[redhat-lspp] Re: Networking policy patch
Joshua Brindle
jbrindle at tresys.com
Thu Oct 5 18:40:50 UTC 2006
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.
More information about the redhat-lspp
mailing list