Venkat, I was wondering if this was a preliminary review before sending upstream to netdev?
Joy On Sat, 2006-06-10 at 17:37 -0400, Venkat Yekkirala wrote: > This patch set adds/enhances support for SELinux/MLS in handling IPSec > xfrm's. It builds on the work by Trent Jaeger, et al, on the labeling of > IPSec SAs. A policy patch is also included for reference. Patch is relative > to the lspp.34 kernel (http://people.redhat.com/sgrubb/files/lspp). > ipsec-tools 0.6.5 src in FC rawhide already has the setkey changes needed to > work with this. A patch to ipsec-tools/racoon will follow later on the > ipsec-tools-devel list. > > The basic idea is to have the IPSec policy specify an MLS range and have > unique SAs generated/used for each of the levels that fall in the range. SAs > for different levels can either be manually loaded (using setkey and such) > or negotiated using IKE (racoon, etc.). > > Example: > > Let's say we have the following in the SPD (Security Policy Database): > > spdadd 9.2.9.15 9.2.9.17 any -ctx 1 1 > "system_u:object_r:zzyzx_t:s0-s9:c0-c127" > -P in ipsec esp/transport//require ; > spdadd 9.2.9.17 9.2.9.15 any -ctx 1 1 > "system_u:object_r:zzyzx_t:s0-s9:c0-c127" > -P out ipsec esp/transport//require ; > > with nothing in the SAD (Security Association Database) initially. When the > kernel runs into the first packet with the label s2:c4 destined for > 9.2.9.17, it will see that there's no SA available to encrypt it with. So, > it will call upon racoon/IKE to generate an SA. Racoon will obtain the label > (s2:c4) from the kernel, do the negotiation with its peer, including the > label (s2:c4) also in the payload/proposals. The negotiation will result in > a dynamically generated SPI that is unique to the label (s2:c4) plus the > other normal parameters involved. It will then insert the SA (along with the > SPI) such as the following into the SAD in the kernel: > > add 9.2.9.15 9.2.9.17 esp 0x123456 > -ctx 1 1 "system_u:object_r:zzyzx_t:s2:c4" > -E des-cbc 0x0000000000000000; > > If the kernel subsequently runs into a packet at a different label (say > s2:c5) for which there's no SA available, it will again call upon racoon > (which will get s2:c5 from the kernel this time) and a different SA (with a > different SPI) will be negotiated. > > Description of changes: > > While the following uses MLS examples and hence may seem MLS-oriented, the > controls would apply equally to SELinux/TE. > > A "sid" member has been added to the flow cache key resulting in the sid > being available at all needed locations and the flow cache lookups > automatically using the sid. The flow sid is derived from the socket on the > outbound and the SAs (unlabeled where an SA was not used) on the inbound. > > Outbound case: > 1. Find policy for the socket. > 2. OLD: Find an SA that matches the policy. > NEW: Find an SA that matches BOTH the policy and the flow/socket. > This is necessary since not every SA that matches the policy > can be used for the flow/socket. Consider policy range Secret-TS, > and SAs each for Secret and TS. We don't want a TS socket to > use the Secret SA. Hence the additional check for the SA Vs. > flow/socket. > 3. NEW: When looking thru bundles for a policy, make sure the flow/socket > can use the bundle. If a bundle is not found, create one, calling for IKE if > necessary. If using IKE, include the security context in the acquire message > to the IKE daemon. > > Inbound case: > 1. OLD: Find policy for the socket. > NEW: Find policy for the incoming packet based on the sid of the SA(s) it > used or the unlabeled sid if no SAs were used. (Consider a case where a > socket is "authorized" for two policies (unclassified-confidential, > secret-top_secret). If the packet has come in using a secret SA, we really > ought to be using the latter policy (secret-top_secret).) > 2. OLD: BUG: No check to see if the SAs used by the packet agree with the > policy sec_ctx-wise. (It was indicated in selinux_xfrm_sock_rcv_skb() that > this was being accomplished by (x->id.spi == tmpl->id.spi || !tmpl->id.spi) > in xfrm_state_ok, but it turns out tmpl->id.spi would normally be zero > (unless xfrm policy rules specify one at the template level, which they > usually don't). > NEW: The socket is checked for access to the SAs used (based on the sid > of the SAs) in selinux_xfrm_sock_rcv_skb(). > > Outstanding issues: > - Timewait acknowledgements and such are generated using a NULL socket > resulting in the any_socket sid (SYSTEM_HIGH) to be used. > > > include/linux/security.h | 97 ++++++++++++-- > include/net/flow.h | 5 > net/core/flow.c | 7 - > net/core/sock.c | 4 > net/key/af_key.c | 24 +++ > net/xfrm/xfrm_policy.c | 28 ++-- > net/xfrm/xfrm_state.c | 12 + > net/xfrm/xfrm_user.c | 2 > security/dummy.c | 23 +++ > security/selinux/hooks.c | 27 +++ > security/selinux/include/av_perm_to_string.h | 1 > security/selinux/include/av_permissions.h | 1 > security/selinux/include/objsec.h | 1 > security/selinux/include/security.h | 2 > security/selinux/include/xfrm.h | 9 + > security/selinux/ss/mls.c | 20 -- > security/selinux/ss/mls.h | 20 ++ > security/selinux/ss/services.c | 48 +++++++ > security/selinux/xfrm.c | 185 > ++++++++++++++++++++++----- > 19 files changed, 423 insertions(+), 93 deletions(-) > -- redhat-lspp mailing list [email protected] https://www.redhat.com/mailman/listinfo/redhat-lspp
