Date: Tue, 31 Jan 2006 19:09:21 +0000 (GMT) From: Iain Hibbert <plunky@rya-online.net> To: Maksim Yevmenkin <maksim.yevmenkin@savvis.net> Cc: freebsd-bluetooth@FreeBSD.org Subject: Re: bluetooth security Message-ID: <1138734561.599404.4457.nullmailer@galant.ukfsn.org> In-Reply-To: <43DFAACD.5040802@savvis.net> References: <1134598760.901248.1323.nullmailer@galant.ukfsn.org> <43A0AB9E.7060808@savvis.net> <1138708994.303189.24314.nullmailer@galant.ukfsn.org> <43DFAACD.5040802@savvis.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 31 Jan 2006, Maksim Yevmenkin wrote: > > 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. 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() 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 > ng_l2cap_llpi.c 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? regards, iain
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1138734561.599404.4457.nullmailer>