From owner-freebsd-bluetooth@FreeBSD.ORG Tue Jan 31 19:50:48 2006 Return-Path: X-Original-To: freebsd-bluetooth@FreeBSD.org Delivered-To: freebsd-bluetooth@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8948816A420 for ; Tue, 31 Jan 2006 19:50:48 +0000 (GMT) (envelope-from maksim.yevmenkin@savvis.net) Received: from ismybrain.com (ismybrain.com [64.246.42.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7030643D62 for ; Tue, 31 Jan 2006 19:50:40 +0000 (GMT) (envelope-from maksim.yevmenkin@savvis.net) Received: from [10.254.186.111] (localhost.localdomain [127.0.0.1]) by ismybrain.com (8.11.6/8.11.6) with ESMTP id k0VJoaM17551; Tue, 31 Jan 2006 14:50:36 -0500 Message-ID: <43DFBF8A.7040606@savvis.net> Date: Tue, 31 Jan 2006 11:50:34 -0800 From: Maksim Yevmenkin User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Iain Hibbert 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> In-Reply-To: <1138734561.599404.4457.nullmailer@galant.ukfsn.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-bluetooth@FreeBSD.org Subject: Re: bluetooth security X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2006 19:50:48 -0000 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