Enabling SECMARK for mark extension

Enabling SECMARK for mark extension

[SCHAUS, STEVEN]

Hello,

I am looking into ways of extending the use of the mark field in struct sk_buff because we've exhausted the 32-bit field. In particular, these bits are in some cases used by the route table to determine the output interface.

After looking at secmark and connlabel for this approach, I thought that secmark would be the least intrusive approach. My reasoning is that secmark/secid is already propagated through the network stack (e.g. struct flowi) and that would make it convenient to use for routing without changes to most of the data structures.

I am working on a patch set for my use case. At a high level:
1. Allow setting the raw secmark field via iptables instead of using an LSM label
2. Allow matching on the secmark field via iptables
3. Allow routing on the secmark field via iproute

xt_SECMARK: add new mode SECMARK_MODE_RAW for directly assigning a value to secmark
xt_SECMARK: allow matching on secmark with optional mask
flowi: set flowi secid based on skb->secmark
fib_rule: propagate and rule match on secid
fib_rule: define FRA_SECMARK and FRA_SECMASK for the UAPI
rtnetlink: define RTA_SECMARK for the UAPI

Is this a sane thing to do or is there a better approach? Are there security considerations I am missing with respect to LSM's?

Thank you.

-Steve