On Thu, 2006-05-04 at 11:20 -0400, Paul Moore wrote: > Regardless, I agree this is something that needs to be discussed as > there are a lot of different approaches that will need to be reconciled. > Do you have a suggestion of the right place to discuss this - the > netdev list, the SELinux list, here?
selinux list. > I don't. The NetLabel module treats the SID as an opaque value and just > returns the value that SELinux gives to it via the call to > netlbl_cache_add() further down in this function (the cache is > invalidated on policy loads/reloads). In the future the NetLabel code > made provide a SID when Selopt is used but that code still only exists > in my head. > > Is there a SID verification function I should be calling? I always > thought that invalid SIDs were just mapped to an unlabled context, so > even if something went wrong and the SID was garbage/incorrect the worst > that would happen would be the packet would be "unlabeled", no? True. Not clear whether this is adequate for error reporting to the caller if the SID is ever provided from another source. > Hmmm, good point. I made the mistake of thinking that the > sidtab_context_to_sid() function would verify the context like > security_context_to_sid(), but now that I am looking at it a bit closer > I realize I was wrong. Sorry about that. > > I'll add the following before the call to sidtab_context_to_sid(): > > ret_val = mls_context_isvalid(policydb, &ctx_new); > if (ret_val != 0) > goto netlbl_sid_failure; The function has a boolean result rather than traditional -errno or 0 upon success, so you want the opposite test above. > Basically I was trying to be a bit more informative in case somebody > ever wants to know the different between a failed IPsec authorization, > -EPERM, and a packet that didn't even pass though IPsec, -EIDRM. At > least that is how I understand the code to work, please correct me if > I'm wrong. I figured it was cheap to provide more information so why > not do it? Current code falls through to the unlabeled check in either case. The first case isn't really a failed authorization; it is just the lack of a SELinux context for the association, in which case it is treated in the same manner as an unprotected packet, i.e. check for unlabeled status. EIDRM is a System V IPC-specific error, right? In any event, if you aren't going to make use of the distinction yourself, then I'd not make it in the code. It can always be added later if a caller does need the distinction. -- Stephen Smalley National Security Agency -- redhat-lspp mailing list [email protected] https://www.redhat.com/mailman/listinfo/redhat-lspp
