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] [day] [month] [year] [list]
Date:	Sat, 1 Aug 2015 10:00:11 +0800
From:	cee1 <fykcee1@...il.com>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	Greg KH <gregkh@...uxfoundation.org>,
	Lennart Poettering <lennart@...ttering.net>,
	David Herrmann <dh.herrmann@...il.com>,
	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>
Subject: Re: Revisit AF_BUS: is it a better way to implement KDBUS?

2015-08-01 5:15 GMT+08:00 Andy Lutomirski <luto@...capital.net>:
> On Fri, Jul 31, 2015 at 9:25 AM, cee1 <fykcee1@...il.com> wrote:
>> 2015-07-31 2:12 GMT+08:00 Andy Lutomirski <luto@...capital.net>:
>>>
>>> I find myself wondering whether an in-kernel *bus* is a good idea at
>>> all.  Creating a bus that unprivileged programs are allowed to
>>> broadcast on (which is kind of the point) opens up big cans of worms.
>>
>> This can be solved in this AF_BUS like this:
>> * Becoming a bus master needs a proper CAP.
>> * Impose a bus endpoint to join multicast address "maddr1" first, if
>> it wants to send to multicast address "maddr2".
>>
>> The bus endpoint sends the request of joining maddr1, and the bus
>> master grants it with replying a cmsg(control message) and setting up
>> a proper eBPF.
>>
>> Next time, the bus endpoint sends to maddr2, the kernel will allow this if:
>> 1) maddr1 & maddr2 == maddr1
>> And 2) the eBPF allows it.
>>  (i.e. the same multicast match logic in this AF_BUS)
>>
>
> I don't understand.
>
> If the endpoint is unprivileged (i.e. random untrusted things can send
> multicast), then you have the scaling problem.  If the endpoint is
> privileged, then it's much less clear to me that this thing is useful.

That means an endpoint has to request the ability of sending to a
specific multicast address(aka join a multicast group), and it's up to
bus master whether grants it or not.



-- 
Regards,

- cee1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ