On Wed, Jan 31, 2007 at 10:29:55AM +0000, Iain Hibbert wrote:
> On Tue, 30 Jan 2007, David Young wrote:
> 
> > On Wed, Jan 31, 2007 at 01:28:26AM +0100, Joerg Sonnenberger wrote:
> > > On Wed, Jan 31, 2007 at 12:16:15AM +0000, Iain Hibbert wrote:
> > > > 1. specifically allow (PF_BLUETOOTH, SOCK_RAW, BTPROTO_HCI) access to all..
> > > > 2. rewrite the HCI socket code so that its not socket based..

A character device is nice because it can be delegated using a familiar
API and UI: chmod/chown.  It also gives the BT HCI privilege a "name"
in a familiar and highly functional namespace that a lot of programs
already grok.

> > > 3. Make the check honour the domain of the socket?
> >
> > ISTR I had to do that for PF_ROUTE.
> 
> Yeah, I saw that hardcoded exception..

I think the 4.4BSD model may as well get another hard-coded exception.

> > (FWIW, I do not think the BSD security model for raw sockets is standing
> > the test of time, and I am thankful for the opportunity to correct it
> > with kauth.)
> 
> I'm not sure what you mean, can you elaborate which way you think we
> should correct it?

Sorry, I wasn't clear.  It is a general thought that should not impinge
on your solution to this specific problem.

The rule "only root can create a raw socket, PF_ROUTE and PF_BLUETOOTH
sockets excepted" is a blunt instrument for enforcing a policy on
what packets a program can send and receive.  It leads to risky
business like using a setuid program to send and receive innocuous
ICMP Echo packets.  Going forwards, *perhaps* the granularity needs to
be finer---socket(PF_ICMP, SOCK_DGRAM, ICMP_ECHO), anyone?---or else
a different mechanism should enforce the policy (packet filter rules
applied to programs and processes?).

Dave

-- 
David Young             OJC Technologies
dyoung@ojctech.com      Urbana, IL * (217) 278-3933