netdev - Enabling SECMARK for mark extension

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [day] [month] [year] [list]

Date:   Fri, 3 Sep 2021 18:28:29 +0000
From:   "SCHAUS, STEVEN" <ss0855@....com>
To:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Enabling SECMARK for mark extension

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