Daemon News Ezine BSD News BSD Mall BSD Support Forum BSD Advocacy BSD Updates

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: bluetooth security


changes though which is saving me lots of work (thanks :)

sure. common bluetooth api for all bsd's would be ideal. i'm willing to work
in this area. if you have any suggestions to that would make it easier to
share the code please let me know.

One of the first issues that I found was that when you wrote the include
files, you used NG_ and ng_ prefixes on all the HCI and L2CAP definitions
and structures. This seemed unnecessary since HCI and L2CAP defs are not
really NetGraph related - I have used your include files hci.h and l2cap.h
more or less directly apart from this.

yes, i was thinking about moving most of the includes into include/bluetooth or something like that. the naming convention is an artifact of very early stage of development (when the code was developed outside of the freebsd source tree)

The biggest choice I made that intentionaly breaks compatibility is that I
chose to have bluetooth address family socket address consistent through
the family (ie a single struct sockaddr_bt for all AF_BLUETOOTH sockets) -
this means so far that HCI sockets use the bdaddr instead of device name
and that L2CAP sockets must set the PSM via setsockopt()

may i ask why did you make this decision?

but I have to say, that converting the FreeBSD userland libs & utilities
was pretty much a noop even after those differences. I haven't especially
looked at anything more, am starting work on a RFCOMM layer soon.


Partly for this reason, I have chosen to have ACL connections for NetBSD
accepted via the hcsecd userland daemon as while it does not currently
have the capability, some kind of hosts allow/deny capability can be added
and thus anybody concerned about security could lock out unknown devices.

well, you could do that, but, frankly, i do not think this is required. i was
thinking about the same too. that is why i put the following comment in the

That may be where I got the idea from, it just seemed logical to have the
functionality in a single security guard at the gate (who are you? ok -
have you a pass? no! whats the code? ok in you come..)

how many people use bluetooth for incoming connections and do not enable
the hcsecd daemon?

i *always* recommend to run hcsecd(8) if bluetooth is used. changes are that hcsecd(8) will be required. even though authentication is off by default in freebsd, it still may be required. _either_ device may request authentication. even if accepting device has authentication off, but remote device has authentication on the authentication sequence will be performed anyway.