Re: Labeled networking packets

[Paul Moore <paul.moore@hp.com>]

Venkat Yekkirala wrote:
>>>You can always have getpeercon return a "domain" by turning out a
>>>domain (a unlabeled_t one?) in the non labeled-ipsec case.
>>
>>The only thing I don't like about this is that it starts giving
>>types/domains implicit meaning that is not defined by policy.
> 
> I don't know what you are talking about here. I was saying you
> could turn out a "true domain" using transitions.

Well, as I understand it right now types/domains have no inherent
meaning; they are given defined through their use in the policy.  Having
the kernel return "unlabeled_t" to signify a special case starts giving
"unlabeled_t" inherent meaning.  Maybe it's not a big deal as I guess
"unlabeled_t" will always have a certain conotation about it but I still
think sending an error is much cleaner.

Applications that depend on getpeercon() could check for the error and
substitute "unlabeled_t".

>> I know we
>>sort of do that already with some of the MLS attributes
> 
> Examples?

Look at all of the "mls*" attributes defined in mls.te and how they are
used in the MLS constraints file.

>>Plus, what if the remote domain was honestly running in "unlabeled_t"?
>>Stupid, yes, but possibile I imagine.
>  
> unlabeled_t anywhere is unlabeled. It doesn't matter how it came to be
> unlabeled_t.

No, not always, see the comments above.

-- 
paul moore
linux security @ hp

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.