On Tue, Aug 27, 2019 at 04:47:04PM -0400, Paul Moore wrote: > > I'm also not a big fan of inserting the hook in rtnl_fill_ifinfo(); as > presented it is way too specific for a LSM hook for me to be happy. > However, I do agree that giving the LSMs some control over netlink > messages makes sense. As others have pointed out, it's all a matter > of where to place the hook. > > If we only care about netlink messages which leverage nlattrs I > suppose one option that I haven't seen mentioned would be to place a > hook in nla_put(). While it is a bit of an odd place for a hook, it > would allow the LSM easy access to the skb and attribute type to make > decisions, and all of the callers should already be checking the > return code (although we would need to verify this). One notable > drawback (not the only one) is that the hook is going to get hit > multiple times for each message. For most messages, "multiple times" would mean tens, for many even hundreds of calls. For each, you would have to check corresponding socket (and possibly also genetlink header) to see which netlink based protocol it is and often even parse existing part of the message to get the context (because the same numeric attribute type can mean something completely different if it appears in a nested attribute). Also, nla_put() (or rather __nla_put()) is not used for all attributes, one may also use nla_reserve() and then compose the attribute date in place. Michal Kubecek
