On Wednesday 29 November 2006 6:30 pm, James Antill wrote: > On Wed, 2006-11-29 at 17:13 -0500, Paul Moore wrote: > > James Antill wrote: > > > On Wed, 2006-11-29 at 16:32 -0500, Stephen Smalley wrote: > > >>I'm not sure the approach is quite workable yet either - if you > > >>configure xinetd to use labeled networking but the incoming connection > > >>is coming from a host that doesn't support it, getpeercon() will fail > > >>and you need to gracefully deal with it (e.g. fall back to some > > >> default, possibly based on the client machine's address). > > > > > > Isn't this exactly what netlabel is for? Do we really want to > > > duplicate that for each daemon? > > > > NetLabel is a method of explicit labeled networking, i.e. it sends > > security attributes with each packet that both hosts must understand. > > As I understand it, you can say label received packets from host X with > context Y. Is that not so?
Sorry for any confusion, I thought you were implying that NetLabel assigns a context to a packet simply based on the IP address of the remote host. A better explanation of NetLabel/CIPSO is below ... For NetLabel if the incoming packet is labeled by the remote host, i.e. a CIPSO IP option is present in the packet's headers, then NetLabel will create a context for the packet based on the concatenation of the SECINITSID_UNLABELED TE values and the CIPSO option's MLS label. In practice this allows you to say that domain X is allowed to receive packets from remote domains/processes which are running with the same MLS label; if domain X has the right MLS type attributes associated with it then it can receive packets from remote domains/processes that do not match it's own MLS label (see the MLS constraints file to see what I mean). The IP address of the remote host never comes into play. -- paul moore linux security @ hp -- redhat-lspp mailing list [email protected] https://www.redhat.com/mailman/listinfo/redhat-lspp
