I'd like to control who can send commands to the robot, ideally through a group...
I spent a little bit of time looking at this today. I can prevent members of a group from sending traffic to a CAN interface using an nftables ruleset like this:
table netdev canfilter {
chain can1egress {
type filter hook egress device can1 priority filter; policy accept;
skgid 1000 counter drop;
}
}
(The counter in the above ruleset isn't necessary; it just adds a packet count to the output of nft list ruleset.)
This prevents members of group 1000 from sending via the can1 interface. If I try running cangen can1 as a user with gid 1000, I see:
$ sudo -u testuser cangen can1
write: No buffer space available
Whereas if I do the same thing as a user not in that group, it works without errors (and I can receive the traffic using candump on another link).
I think that accomplishes your goal.
I don't think it's possible to limit reception by uid; looking at the logs produced using something like:
table netdev canfilter {
chain can0ingress {
type filter hook ingress device can0 priority filter; policy accept;
log group 0;
}
}
It looks like on the receiving side we don't have access to the uid/gid metadata (which makes sense, because packets may be arriving from other than the local system).
For testing this out, I used the cangen and candump utilities from the can-utils project, and ulogd for logging since I was using isolated namespaces for the CAN interfaces (so regular kernel logging wasn't an option).
I've streamlined my test and put everything online here.
ipiniptablessuggests that it won't be particularly useful for CAN networks.ipcommand is used to configure the CAN interfaces, so it doesn't seem too unlikely. I'm just not very familiar with iptables, otherwise I would simply give it a try.cangenandcandumpfrom thecan-utilsproject to generate and listen to traffic for testing purposes.