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  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

Powered by blists - more mailing lists