Re: generic fallbacks of getpeercon (Re: [redhat-lspp] Labeling an interface)

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

On Thursday 07 June 2007 3:42:27 am KaiGai Kohei wrote:
> KaiGai Kohei wrote:
> | As I envision it right now this new static external label would be
> | managed via NetLabel (it is a framework after all, not just CIPSO) so we
> | wouldn't need to introduce any more per-packet access checks, similar to
> | how
> | iptables/netfilter manages the SECMARK labels.  The impact to the SELinux
> | kernel code should be quite minimal using this approach.
>
> In my understanding, the next NetLabel-tools enables to store fallbacked
> client's context associated with network addresses/interfaces into the
> kernel space, and those definitions are evaluated to attach a valid
> peer_sid when a connection come from unlabaled network. Is it correct?

Yes, that is correct.

> One more point is here.
> How should be handled a connection come from unlabeled network, without any
> fallbacked context? Two ways are considerable for me. One is that
> getpeercon() really returns -ENOPROTOOPT, the other is returning an initial
> context newly defined for this purpose.

My personal opinion is that the current getpeercon() behavior of 
returning -ENOPROTOOPT when a peer label is not present is probably the best 
solution as it allows per-application handling of this particular case.  
Earlier in the thread Stephen mentioned that Eamon had developed a way to 
handle this for X using a domain specific fallback label and that approach 
seems to make the most sense to me.

-- 
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.