SOCK_CAN interface rights

[RazeLighter777]

While it may be less well known outside the automotive and automation industry, CAN or controller area network is a widely used bus-based industrial control protocol used commonly to allow electronic control systems to communicate.

Linux supports CAN through the SocketCAN subsystem.
https://docs.kernel.org/networking/can.html

Today, a process that can create AF_CAN sockets can generally bind to any CAN interface (can0, can1, vcan*, etc.) visible in its namespace. In systems with multiple CAN buses (automotive, robotics, industrial gateways, test setups with vcan), those interfaces often represent distinct trust or safety domains.

While it's less common outside of industry (especially automotive) it seems like landlock could be extended restrict access to certain CAN interfaces, which may be useful on control systems with multiple isolated CAN buses. (it is common in many vehicles, for instance to have CAN buses for safety critical systems like airbags and brakes seperate from air conditioning, entertainment systems etc)

From the linux SocketCAN documentation:

There are two types of CAN sockets:

CAN_RAW

s = socket(PF_CAN, SOCK_RAW, CAN_RAW);

and:

CAN_BCM

s = socket(PF_CAN, SOCK_DGRAM, CAN_BCM);

The technical difference between them is CAN_RAW requires userspace to handle the timeout monitoring, and some of the protocol implementation itself (similar to other raw sockets).

CAN_RAW sockets are used with bind

int s;
struct sockaddr_can addr;
struct ifreq ifr;

s = socket(PF_CAN, SOCK_RAW, CAN_RAW);

strcpy(ifr.ifr_name, "can0" );
ioctl(s, SIOCGIFINDEX, &ifr);

addr.can_family = AF_CAN;
addr.can_ifindex = ifr.ifr_ifindex;

bind(s, (struct sockaddr *)&addr, sizeof(addr));

(..)

and CAN_BCM packets are used with connect()

int s;
struct sockaddr_can addr;
struct ifreq ifr;

s = socket(PF_CAN, SOCK_DGRAM, CAN_BCM);

strcpy(ifr.ifr_name, "can0");
ioctl(s, SIOCGIFINDEX, &ifr);

addr.can_family = AF_CAN;
addr.can_ifindex = ifr.ifr_ifindex;

connect(s, (struct sockaddr *)&addr, sizeof(addr));

(..)

Meaning that both cases would need to be handled differently.

There is no "addressing" in the traditional sense with CAN, only interface IDs. An important case to note is when the interface is in CAM_BCM, you can pass in 0 for the interface number to connect to all interfaces on the system.

While the lookup for the interface is done with IOCTL, we don't currently restrict non-device ioctl calls like this. But it seems possible add support for this with the existing connect/bind/sendmsg/sendto lsm hooks and not have to do ioctl restrictions at all

Could this be something landlock could support?

Edit: As far as I can tell, no LSM currently outside selinux supports SOCK_CAN explicitly.

[RazeLighter777]

If there is interest, I have a prototype implementation

[gnoack]

Maybe a naive question because I am not that familiar with the automotive domain, but if the process is deployed on an embedded system, presumably under some service manager, can't the available network interfaces already be controlled by letting these services run in dedicated network namespaces?

[RazeLighter777]

Maybe a naive question because I am not that familiar with the automotive domain, but if the process is deployed on an embedded system, presumably under some service manager, can't the available network interfaces already be controlled by letting these services run in dedicated network namespaces?

Yes, but this requires CAP_NET_ADMIN to actually move the interface into the new namespace. By default in all network interfaces in a network namespace are invisible and must be moved
manually. So it's not truly unprivileged.

Thinking about it more, it may be useful to add an access right for network interface IDs generally, that would work for CAN but also be useful for other interface types...

[gnoack]

Agreed; the CAN bus idea is quite specific, IMHO.

If we can build something that works for a broader set of use cases, I would find that preferrable.

[RazeLighter777]

I think that if we add more networking rights, it would be nice if they could be used in conjunction with eachother.

Right now we just have ports (tcp and tentatively udp).

But if we start restricting IP addresses / network interfaces etc, it seems policies built on tuples of these properties (like a sockaddr) would be most useful.

Landlock doesn't have an existing way to specify compound access rights (and for good reason; we haven't needed one yet). But if we had a new network access right at the IP or Data-link layer it would be interesting to group that rule with a port (transport layer), for instance. (i.e this process can connect to a specific IP address and port)

This starts blurring the lines between a LSM and something like netfilter. (albiet still useful with landlock being unprivileged and netfilter being a CAP_SYS_ADMIN construct).

Furthermore, I'm not sure if such things within the scope of Landlock, but I'm curious about it nonetheless. I am also not positive that LSM hooks would provide the needed interfaces to allow an LSM to effectively be an application level firewall.