RE: [PATCH 3/3] mlsxfrm: Various fixes
Such duplication can occur among the initial SIDs. For some reason I thought that could happen between an initial SID and a non-initial SID. Not sure though when that would apply here, It could apply to xfrms if they happen to be using the context represented by any of the initial SIDs. and it would only apply if both SIDs were initial SIDs. OK. Will narrow the full context comparison to just this case. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 3/3] mlsxfrm: Various fixes
On Wed, 2006-11-08 at 08:34 -0600, Venkat Yekkirala wrote: Such duplication can occur among the initial SIDs. For some reason I thought that could happen between an initial SID and a non-initial SID. I think only in the case where a non-initial SID has been invalidated by policy reload that renders its context illegal and is thus remapped to the unlabeled SID. Not sure though when that would apply here, It could apply to xfrms if they happen to be using the context represented by any of the initial SIDs. Which would happen when? and it would only apply if both SIDs were initial SIDs. OK. Will narrow the full context comparison to just this case. What's the harm from just using the SID comparison and allowing for the possibility that there might be a few duplicates in rare circumstances? Does it break any assumptions in the rest of the logic? -- Stephen Smalley National Security Agency - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 3/3] mlsxfrm: Various fixes
Not sure though when that would apply here, It could apply to xfrms if they happen to be using the context represented by any of the initial SIDs. Which would happen when? If one were attempting to use a context pertaining to the unlabeled init sid in the SPD and/or the SAD. But would I be correct in assuming that the same sid (unlabeled init sid in all likelyhood) would end up being returned when the context is turned into a sid, resulting in the SPD and the SAD using the same init sid, thus making a full-context compare unnecessary? and it would only apply if both SIDs were initial SIDs. OK. Will narrow the full context comparison to just this case. What's the harm from just using the SID comparison and allowing for the possibility that there might be a few duplicates in rare circumstances? Does it break any assumptions in the rest of the logic? The best I can think of is if the SA's sid doesn't match the socket's SID, IKE would come into play, if it's configured. I also wanted to conversely ask what harm exists if we did a full-context compare in the event the sids didn't match? Are we just trying to generally avoid extra code? - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] mlsxfrm: Various fixes
On Tue, 2006-11-07 at 15:29 -0500, Paul Moore wrote:
Venkat Yekkirala wrote:
+/*
+ * security_sid_compare() - compares two given sid contexts.
+ * Returns 1 if they are equal, 0 otherwise.
+ */
+int security_sid_compare(u32 sid1, u32 sid2)
+{
+ struct context *context1;
+ struct context *context2;
+ int rc;
+
+ if (!ss_initialized)
+ return 1;
+
+ if (sid1 == sid2)
+ return 1;
+ else if (sid1 SECINITSID_NUM sid2 SECINITSID_NUM)
+ return 0;
+
+ /* explicit comparison in order */
+
+ POLICY_RDLOCK;
+ context1 = sidtab_search(sidtab, sid1);
+ if (!context1) {
+ printk(KERN_ERR security_sid_compare: unrecognized SID
+ %u\n, sid1);
+ rc = 0;
+ goto out_unlock;
+ }
+
+ context2 = sidtab_search(sidtab, sid2);
+ if (!context2) {
+ printk(KERN_ERR security_sid_compare: unrecognized SID
+ %u\n, sid2);
+ rc = 0;
+ goto out_unlock;
+ }
+
+ rc = context_cmp(context1, context2);
+
+out_unlock:
+ POLICY_RDUNLOCK;
+ return rc;
+}
I understand wanting a generic LSM interface to do secid token comparisons,
but
in the SELinux implementation of this function I think we can get away with
only
a simple sid1 == sid2 since the security server shouldn't be creating
duplicate SID/secid values for identical contexts, I think. Did you run into
something in testing that would indicate otherwise?
Such duplication can occur among the initial SIDs. Not sure though when
that would apply here, and it would only apply if both SIDs were initial
SIDs.
--
Stephen Smalley
National Security Agency
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
