> This seems problematic in that it's not a general solution > and depends > always on hooking in at all of the right places in every > protocol. Adding > a bunch of hooks to protocol-specific code is what got us in > trouble with > the initial LSM submission. > > What about using secmark and connection tracking for this, instead?
1. By the time we are in secmark (outbound), the xfrm(s) will already been chosen and the ip packet labeled (NetLabel). 2. Secmark can't be used for the multi-level process case since data at different levels can be written onto the same socket by a trusted/privileged process. Secmark serves primarily as a flow control point in our new design (both inbound and outbound) and secondarily as a labeling mechanism for the inbound packets in the absence of an explicit label coming in with the packet. As for the "right places" in the protocol code, there's only one "standard and intuitive" place, which is where a flow is defined. We are just asking that they "label" the flow, that too, only if they desire to use multi-labeled communication using that protocol. Hopefully the flow_sid.txt doc will aid in this. Typically, I suspect the developers will just ignore the sid (which is OK; it would then be just a matter of having the right policy for the single-labeled communication). It would then fall to one of us to label the flows as and when we desire to use those protos for multi-labeled communication. > > I'd also suggest moving this discussion to netdev, so other network > developers & maintainers can participate, or just keep track of the > discussion. > As soon as I get the patches rebased and posted there; please trigger the discussion again (or feel free to take this to netdev if you think it would be ok as is). Thanks. -- redhat-lspp mailing list [email protected] https://www.redhat.com/mailman/listinfo/redhat-lspp
