netdev - Re: [PATCH 3/7] CAN: Add raw protocol

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	21 Sep 2007 23:05:25 +0200
From:	Urs Thuermann <urs@...ogud.escape.de>
To:	Patrick McHardy <kaber@...sh.net>
Cc:	netdev@...r.kernel.org, David Miller <davem@...emloft.net>,
	Thomas Gleixner <tglx@...utronix.de>,
	Oliver Hartkopp <oliver@...tkopp.net>,
	Oliver Hartkopp <oliver.hartkopp@...kswagen.de>
Subject: Re: [PATCH 3/7] CAN: Add raw protocol

Patrick McHardy <kaber@...sh.net> writes:

> Urs Thuermann wrote:
> > +config CAN_RAW_USER
> > +	bool "Allow non-root users to access Raw CAN Protocol sockets"
> 
> 
> If you plan to remove this option, it should happen before merging
> since it affects userspace visible behaviour.

We have discussed this and have come to the conclusion that we should
remove permission checks completely, i.e. any user can open any CAN
socket (raw, bcm, or whatever will be implemented in the future).
This is because CAN is a pure broadcast network with no addresses.
CAN frames can't be directed to only one machine or a group or to only
one process (say one port).  There is no communication between only
two (or some number) of stations which must be protected from other
stations.

On the other hand, requiring a process to have CAP_NET_RAW to open a
CAN socket would mean that such process would also be able to sniff on
your ethernet or WLAN interfaces, which one probably wouldn't want.

We have added that check when we still allowed the CAN raw socket to
bind to any interface and we didn't want an unprivileged process to be
able to read all e.g. TCP/IP traffic.  Now binding is restricted to
ARPHRD_CAN interfaces.  But even without this restriction the check is
not necessary, since all CAN sockets can only receive and send
ETH_P_CAN packets.  So even if there would be an encapsulation of CAN
frames over ethernet or some other type of network, a normal user
process opening a CAN socket would only be able to read/write CAN
traffic, which should be OK without any special capability.

So what do you think about this?

urs
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html