On Thu, 2006-11-30 at 08:06 -0500, Stephen Smalley wrote: > On Wed, 2006-11-29 at 18:30 -0500, 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? > > I think you are confusing netlabel with secmark, and also still thinking > about secid reconciliation (which didn't get accepted). If secid > reconciliation had been accepted, then yes, you could assign a default > label based on client host or other properties of the packet via secmark > and have it returned by getpeercon if there was no explicit label on the > packet. But the final resolution of that lengthy debate was that > secmark would remain separate from labeled networking, and that > getpeercon would only return a context if labeled networking was in use > on the connection (likewise for SCM_SECURITY on datagrams). > > I agree though that replicating the lookup of a default context by host > per daemon wouldn't be desirable, so one might want a general service > provided by libselinux. A topic for selinux list, not here, yet again.
BTW, libsepol and libsemanage already have a notion of node (host) contexts, although those are defined in the policy for certain permission checks (node_bind, compat send/recv per-packet checks). Not sure whether you can leverage the range portion of those contexts for this purpose. -- Stephen Smalley National Security Agency -- redhat-lspp mailing list [email protected] https://www.redhat.com/mailman/listinfo/redhat-lspp
