Date: Tue, 31 Jan 2006 11:50:34 -0800 From: Maksim Yevmenkin <maksim.yevmenkin@savvis.net> To: Iain Hibbert <plunky@rya-online.net> Cc: freebsd-bluetooth@FreeBSD.org Subject: Re: bluetooth security Message-ID: <43DFBF8A.7040606@savvis.net> In-Reply-To: <1138734561.599404.4457.nullmailer@galant.ukfsn.org> References: <1134598760.901248.1323.nullmailer@galant.ukfsn.org> <43A0AB9E.7060808@savvis.net> <1138708994.303189.24314.nullmailer@galant.ukfsn.org> <43DFAACD.5040802@savvis.net> <1138734561.599404.4457.nullmailer@galant.ukfsn.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Iain, >>>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. ok >>>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? 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. thanks, max
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?43DFBF8A.7040606>