Restricting permissions to CAN sockets

Restricting permissions to CAN sockets

[Doug Zobel]

Is there a way to restrict permissions to the socket interface
provided by socketcan?  Perhaps something like iptables but for CAN?
I'd like to restrict access to the CAN bus to a single application on
the system.

Re: Restricting permissions to CAN sockets

[Oliver Hartkopp]

On 05/09/2017 04:53 PM, Doug Zobel wrote:
> On Tue, May 9, 2017 at 12:43 AM, Oliver Hartkopp <socketcan@hartkopp.net> wrote:

>>> Perhaps something like iptables but for CAN?
>>
>> Yes. You can use the can-gw module for filtering, routing and modifying CAN
>> frames.
>
> Thanks, I will look into the can-gw module.
>
>>> I'd like to restrict access to the CAN bus to a single application on
>>> the system.
>>
>> 1. don't you trust other applications on the host?
>> 2. don't you trust the mentioned single application, so that you would need
>> some filtering?
>>
>>
>> Whom do you want to restrict?
>
> I don't trust other applications (users) on the system.  If a person
> were to gain access to the system through an exploit, I'd like to make
> sure they can't inject CAN messages.  I'd like to be able to restrict
> access to the PF_CAN socket to root or to a single process.

I would see two different ideas for your requirement:

1. use network namespaces (which is new in Linux 4.12+)
2. implement capabilities in your modified Linux kernel

For the first idea you can move your application into a separate 
namespace and move the (real) CAN interface there too.

http://marc.info/?l=linux-can&m=149330893417415&w=2

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/net/can?id=c2701b370e6b4d0022043691b5ac7adad015e4fc

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=a8f820a380a2a06fc4fe1a54159067958f800929

For the second idea you might integrate a ns_capable() check when 
accessing CAN sockets. So this has to be added in raw.c and bcm.c .

Try 'git grep -C10 ns_capable' to find examples.
(This applies to the latest kernel tree with namespace support)

Or you can check for 'git grep -C10 capable' for Linux 4.11 and older.

Adding some

	if (!capable(CAP_NET_ADMIN))
		return -EPERM;

checks at socket functions would restrict the use to admin users.

There are even more capabilities than CAP_NET_ADMIN in
linux/include/uapi/linux/capability.h

So you can check what fits best for your case.

Regards,
Oliver

Re: Restricting permissions to CAN sockets

[Oliver Hartkopp]

Hi Doug,

On 05/09/2017 11:31 PM, Doug Zobel wrote:
> Thanks for the suggestions.
>
> Namespaces look like a simple clean solution, however it may be
> difficult for us to use until it makes it into an LTS kernel.

I don't know about other securing techniques that may fit here too.
E.g. probably selinux or some other stuff granting specific applications 
to use specific syscalls could be interesting ...

Regards,
Oliver

>
> I'll look into adding a system capability check on my current kernel.
>
> -Doug
>
> On Tue, May 9, 2017 at 11:52 AM, Oliver Hartkopp <socketcan@hartkopp.net> wrote:
>> On 05/09/2017 04:53 PM, Doug Zobel wrote:
>>>
>>> On Tue, May 9, 2017 at 12:43 AM, Oliver Hartkopp <socketcan@hartkopp.net>
>>> wrote:
>>
>>
>>>>> Perhaps something like iptables but for CAN?
>>>>
>>>>
>>>> Yes. You can use the can-gw module for filtering, routing and modifying
>>>> CAN
>>>> frames.
>>>
>>>
>>> Thanks, I will look into the can-gw module.
>>>
>>>>> I'd like to restrict access to the CAN bus to a single application on
>>>>> the system.
>>>>
>>>>
>>>> 1. don't you trust other applications on the host?
>>>> 2. don't you trust the mentioned single application, so that you would
>>>> need
>>>> some filtering?
>>>>
>>>>
>>>> Whom do you want to restrict?
>>>
>>>
>>> I don't trust other applications (users) on the system.  If a person
>>> were to gain access to the system through an exploit, I'd like to make
>>> sure they can't inject CAN messages.  I'd like to be able to restrict
>>> access to the PF_CAN socket to root or to a single process.
>>
>>
>> I would see two different ideas for your requirement:
>>
>> 1. use network namespaces (which is new in Linux 4.12+)
>> 2. implement capabilities in your modified Linux kernel
>>
>> For the first idea you can move your application into a separate namespace
>> and move the (real) CAN interface there too.
>>
>> http://marc.info/?l=linux-can&m=149330893417415&w=2
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/net/can?id=c2701b370e6b4d0022043691b5ac7adad015e4fc
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=a8f820a380a2a06fc4fe1a54159067958f800929
>>
>> For the second idea you might integrate a ns_capable() check when accessing
>> CAN sockets. So this has to be added in raw.c and bcm.c .
>>
>> Try 'git grep -C10 ns_capable' to find examples.
>> (This applies to the latest kernel tree with namespace support)
>>
>> Or you can check for 'git grep -C10 capable' for Linux 4.11 and older.
>>
>> Adding some
>>
>>         if (!capable(CAP_NET_ADMIN))
>>                 return -EPERM;
>>
>> checks at socket functions would restrict the use to admin users.
>>
>> There are even more capabilities than CAP_NET_ADMIN in
>> linux/include/uapi/linux/capability.h
>>
>> So you can check what fits best for your case.
>>
>> Regards,
>> Oliver
>>