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]

Message-ID: <46F4F655.5000009@trash.net>
Date:	Sat, 22 Sep 2007 13:02:45 +0200
From:	Patrick McHardy <kaber@...sh.net>
To:	Urs Thuermann <urs@...ogud.escape.de>
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

Urs Thuermann wrote:
> Patrick McHardy <kaber@...sh.net> writes:
>>
>>>+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?


I believe that should be fine.
-
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