New BlueZ Security Manager

New BlueZ Security Manager

[Stephen Crane]

Hi Marcel, Max,
On Marcel's German slides (for which I've lost the link) I noticed a
revamped security manager on the TODO list. However I don't ever
remember seeing a discussion about it here on the list. I'd like to
kick-start this discussion if possible.

The main thing wrong with hcid (in my opinion) is what the security
white-paper (http://www.bluetooth.com/upload/24Security_Paper.PDF)
defines as support for security mode 2. This is where the
owning-application enforces the security requirements for a service.

The difference between this and the current setup (security modes 1 and
3 in the whitepaper's terminology) is (I think) that hcid enforces
permissions at the ACL level whereas service-level security takes place
/after/ the ACL link is already up. It should be possible to allow SDP
searches for example, but deny access to services discovered through
SDP.

I don't think that the current kernel API is rich enough to permit this.
It ought to be possible for a server listening on a socket to discover
the BDADDR of the connecting peer and either accept() or reject access
--- probably through an ioctl(). On the client-side, a special error
return from (or argument to) connect() could indicate that a PIN was
required to connect.

Thoughts?
Steve
-- 
Stephen Crane, Rococo Software Ltd. http://www.rococosoft.com
steve.crane@rococosoft.com +353-1-6601315 (ext 209)

[Bluez-devel] Re: New BlueZ Security Manager

[Marcel Holtmann]

Hi Stephen,

> On Marcel's German slides (for which I've lost the link) I noticed a
> revamped security manager on the TODO list. However I don't ever
> remember seeing a discussion about it here on the list. I'd like to
> kick-start this discussion if possible.

here is the link to me slides

	http://www.holtmann.org/papers/bluetooth/

There was no real discussion about this topic, but some problems have
raised from time to time. And it is clear that the device up/down
functionaltiy of hcid will be removed and placed as bluetooth.agent in
the hotplug scripts. If you remove this from hcid the only thing which
is left is the security manager and it should be named like this ;)

> The main thing wrong with hcid (in my opinion) is what the security
> white-paper (http://www.bluetooth.com/upload/24Security_Paper.PDF)
> defines as support for security mode 2. This is where the
> owning-application enforces the security requirements for a service.
> 
> The difference between this and the current setup (security modes 1 and
> 3 in the whitepaper's terminology) is (I think) that hcid enforces
> permissions at the ACL level whereas service-level security takes place
> /after/ the ACL link is already up. It should be possible to allow SDP
> searches for example, but deny access to services discovered through
> SDP.

I never used it, but if I remember correclty this can be done through
the L2CAP_LM option with setsockopt(), but it can't be done for RFCOMM
at the moment. Max told me that he have this on his todo list.

> I don't think that the current kernel API is rich enough to permit this.
> It ought to be possible for a server listening on a socket to discover
> the BDADDR of the connecting peer and either accept() or reject access
> --- probably through an ioctl(). On the client-side, a special error
> return from (or argument to) connect() could indicate that a PIN was
> required to connect.

It would be great to know the IP before doing a accept(), but as I know
the socket API didn't provide this. If you don't like the BDADDR you can
close the connection right after connect. Maybe it is possible to extend
shutdown() to return a request denied option to the other end.

I also have this idea with the connect() return with an error to request
a PIN. This can be set through a setsockopt() or can be a paramter of
sockaddr. But the problem is that you don't have a PIN or pairing for
one L2CAP or RFCOMM connection. You only have it at HCI layer and what
if two applications on the same host request some services on the same
device. Which PIN has to be entered? Should one connect() be delayed
until the first finished his authentication?

>From my point I think the application which establish the connection has
to handle the PIN code. If a device is already paired, the link key
exchange and request should be handled global. I also have played a
little bit with in-kernel (HCI core) handling of the link notification
and response to link requests. But the keys have to stored on shutdown
and restored on the boot.

And a question for the brave ;) How do we handle authentication with a
Bluetooth keyboard?

Regards

Marcel




-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Re: New BlueZ Security Manager

[Max Krasnyansky]

At 07:52 AM 3/5/2003, Marcel Holtmann wrote:
>I never used it, but if I remember correclty this can be done through
>the L2CAP_LM option with setsockopt(). 
Yep. pand --encrypt uses that features.

>But it can't be done for RFCOMM at the moment. Max told me that he have 
>this on his todo list.
Yep.

>> I don't think that the current kernel API is rich enough to permit this.
>> It ought to be possible for a server listening on a socket to discover
>> the BDADDR of the connecting peer and either accept() or reject access
>> --- probably through an ioctl(). On the client-side, a special error
>> return from (or argument to) connect() could indicate that a PIN was
>> required to connect.
>
>It would be great to know the IP before doing a accept(), but as I know
>the socket API didn't provide this. If you don't like the BDADDR you can
>close the connection right after connect. Maybe it is possible to extend
>shutdown() to return a request denied option to the other end.
>
>I also have this idea with the connect() return with an error to request
>a PIN. This can be set through a setsockopt() or can be a paramter of
>sockaddr. But the problem is that you don't have a PIN or pairing for
>one L2CAP or RFCOMM connection. You only have it at HCI layer and what
>if two applications on the same host request some services on the same
>device. Which PIN has to be entered? Should one connect() be delayed
>until the first finished his authentication?
Like I said application doesn't have to be involved in this. All it has 
to do is say "this socket needs authenticated (or encrypted) connection".

>>>From my point I think the application which establish the connection has
>to handle the PIN code. 
>If a device is already paired, the link key exchange and request should be 
>handled global. I also have played a little bit with in-kernel (HCI core) 
>handling of the link notification and response to link requests. But the keys 
>have to stored on shutdown and restored on the boot.
We talked about that. PIN code is not a per application or per user level thing.
Current implementation is fine. We just need a database that can be easily updated.

>And a question for the brave ;) How do we handle authentication with a
>Bluetooth keyboard?
Good one. Voice recognition ? ;-)

Max



-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] New BlueZ Security Manager

[Max Krasnyansky]

At 05:46 AM 3/5/2003, Stephen Crane wrote:
>Hi Marcel, Max,
>On Marcel's German slides (for which I've lost the link) I noticed a
>revamped security manager on the TODO list. However I don't ever
>remember seeing a discussion about it here on the list. I'd like to
>kick-start this discussion if possible.
Sure. 
The idea is to have a device database (names, PINs, keys, etc).
The database will be updated by hcid (or what ever new name will be) 
and user tools that can add/delete/display PIN code and stuff.

>The main thing wrong with hcid (in my opinion) is what the security
>white-paper (http://www.bluetooth.com/upload/24Security_Paper.PDF)
>defines as support for security mode 2. This is where the
>owning-application enforces the security requirements for a service.
>
>The difference between this and the current setup (security modes 1 and
>3 in the whitepaper's terminology) is (I think) that hcid enforces
>permissions at the ACL level whereas service-level security takes place
>/after/ the ACL link is already up. It should be possible to allow SDP
>searches for example, but deny access to services discovered through
>SDP.
HCID (or any other daemon) need not be involved here. And it is possible. 
Our L2CAP layer already support this. RFCOMM support is in my todo list.

>I don't think that the current kernel API is rich enough to permit this.
>It ought to be possible for a server listening on a socket to discover
>the BDADDR of the connecting peer and either accept() or reject access
>--- probably through an ioctl(). On the client-side, a special error
>return from (or argument to) connect() could indicate that a PIN was
>required to connect.
That's one way to do it. The other way (which is simpler) is for the server 
to tell the kernel that the socket requires secure connection before doing
accept. And that's how current L2CAP sockets work. 

Looks like it's time to start working on utils-3.x. Let's wrap up 
minor pending fixes for current utils and libs, release stable version
and start working on new stuff.

Max