Bluetooth: Introduce new HCI socket channel for user operation

PATCH In review Marcel Holtmann 2 participants 4 messages Aug 27, 2013 – Sep 1, 2013

Subsystems (2)

Bluetooth drivers Bluetooth

lore

Share & tools

lore

Marcel Holtmann

author maintainer

2013-08-27 04:40 UTC #0 lore raw

PATCH 2/2 Bluetooth: Introduce new HCI socket channel for user operation

This patch introcuces a new HCI socket channel that allows user applications to take control over a specific HCI device. The application gains exclusive access to this device and forces the kernel to stay away and not manage it. In case of the management interface it will actually hide the device.

Such operation is useful for security testing tools that need to operate underneath the Bluetooth stack and need full control over a device. The advantage here is that the kernel still provides the service of hardware abstraction and HCI level access. The use of Bluetooth drivers for hardware access also means that sniffing tools like btmon or hcidump are still working and the whole set of transaction can be traced with existing tools.

With the new channel it is possible to send HCI commands, ACL and SCO data packets and receive HCI events, ACL and SCO packets from the device. The format follows the well established H:4 protocol.

The new HCI user channel can only be established when a device has been through its setup routine and is currently powered down. This is enforced to not cause any problems with current operations. In addition only one user channel per HCI device is allowed. It is exclusive access for one user application. Access to this channel is limited to process with CAP_NET_RAW capability.

Using this new facility does not require any external library or special ioctl or socket filters. Just create the socket and bind it. After that the file descriptor is ready to speak H:4 protocol.

        struct sockaddr_hci addr;
        int fd;

        fd = socket(AF_BLUETOOTH, SOCK_RAW, BTPROTO_HCI);

        memset(&addr, 0, sizeof(addr));
        addr.hci_family = AF_BLUETOOTH;
        addr.hci_dev = 0;
        addr.hci_channel = HCI_CHANNEL_USER;

        bind(fd, (struct sockaddr *) &addr, sizeof(addr));

The example shows on how to create a user channel for hci0 device. Error handling has been left out of the example. However with the limitations mentioned above it is advised to handle errors. Binding of the user cahnnel socket can fail for various reasons. Specifically if the device is currently activated by BlueZ or if the access permissions are not present.

Signed-off-by Marcel Holtmann <[email protected]>

---
 include/net/bluetooth/hci.h |  1 +
 net/bluetooth/hci_sock.c    | 86 ++++++++++++++++++++++++++++++++++++++++++---
 2 files changed, 82 insertions(+), 5 deletions(-)

include/net/bluetooth/hci.h +1 -0

index 128157d..30c88b5 100644
@@ -1571,6 +1571,7 @@ struct sockaddr_hci {
 #define HCI_DEV_NONE	0xffff
 
 #define HCI_CHANNEL_RAW		0
+#define HCI_CHANNEL_USER	1
 #define HCI_CHANNEL_MONITOR	2
 #define HCI_CHANNEL_CONTROL	3

net/bluetooth/hci_sock.c +81 -5

129 lines not on this page · raw message

Signature · 1 line

1.8.3.1

Gustavo Padovan

2013-09-01 16:45 UTC #1 lore raw

Hi Marcel,

2013-08-26 Marcel Holtmann <[email protected]>:

Quoted 59 lines

This patch introcuces a new HCI socket channel that allows user applications to take control over a specific HCI device. The application gains exclusive access to this device and forces the kernel to stay away and not manage it. In case of the management interface it will actually hide the device.
Such operation is useful for security testing tools that need to operate underneath the Bluetooth stack and need full control over a device. The advantage here is that the kernel still provides the service of hardware abstraction and HCI level access. The use of Bluetooth drivers for hardware access also means that sniffing tools like btmon or hcidump are still working and the whole set of transaction can be traced with existing tools.
With the new channel it is possible to send HCI commands, ACL and SCO data packets and receive HCI events, ACL and SCO packets from the device. The format follows the well established H:4 protocol.
The new HCI user channel can only be established when a device has been through its setup routine and is currently powered down. This is enforced to not cause any problems with current operations. In addition only one user channel per HCI device is allowed. It is exclusive access for one user application. Access to this channel is limited to process with CAP_NET_RAW capability.
Using this new facility does not require any external library or special ioctl or socket filters. Just create the socket and bind it. After that the file descriptor is ready to speak H:4 protocol.
        struct sockaddr_hci addr;
        int fd;

        fd = socket(AF_BLUETOOTH, SOCK_RAW, BTPROTO_HCI);

        memset(&addr, 0, sizeof(addr));
        addr.hci_family = AF_BLUETOOTH;
        addr.hci_dev = 0;
        addr.hci_channel = HCI_CHANNEL_USER;

        bind(fd, (struct sockaddr *) &addr, sizeof(addr));
The example shows on how to create a user channel for hci0 device. Error handling has been left out of the example. However with the limitations mentioned above it is advised to handle errors. Binding of the user cahnnel socket can fail for various reasons. Specifically if the device is currently activated by BlueZ or if the access permissions are not present.
Signed-off-by Marcel Holtmann <[email protected]>
---
 include/net/bluetooth/hci.h |  1 +
 net/bluetooth/hci_sock.c    | 86 ++++++++++++++++++++++++++++++++++++++++++---
 2 files changed, 82 insertions(+), 5 deletions(-)
include/net/bluetooth/hci.h +0 -0
index 128157d..30c88b5 100644

include/net/bluetooth/hci.h struct sockaddr_hci { · line 1576

Quoted 6 lines

include/net/bluetooth/hci.h +1 -0

@@ -1571,6 +1571,7 @@ struct sockaddr_hci {
 #define HCI_DEV_NONE	0xffff
 
 #define HCI_CHANNEL_RAW		0
+#define HCI_CHANNEL_USER	1
 #define HCI_CHANNEL_MONITOR	2
 #define HCI_CHANNEL_CONTROL	3

Wouldn't this break BlueZ 4.101? It would open the channel 1 thinking it is the CONTROL one but it is not. I think we need to redefine this to 4. I can do this when applying the patch if you are okay with it.

Gustavo

Marcel Holtmann

author maintainer

2013-09-01 17:27 UTC #2 lore raw

Hi Gustavo,

Quoted 61 lines

Quoted 61 lines
This patch introcuces a new HCI socket channel that allows user applications to take control over a specific HCI device. The application gains exclusive access to this device and forces the kernel to stay away and not manage it. In case of the management interface it will actually hide the device.
Such operation is useful for security testing tools that need to operate underneath the Bluetooth stack and need full control over a device. The advantage here is that the kernel still provides the service of hardware abstraction and HCI level access. The use of Bluetooth drivers for hardware access also means that sniffing tools like btmon or hcidump are still working and the whole set of transaction can be traced with existing tools.
With the new channel it is possible to send HCI commands, ACL and SCO data packets and receive HCI events, ACL and SCO packets from the device. The format follows the well established H:4 protocol.
The new HCI user channel can only be established when a device has been through its setup routine and is currently powered down. This is enforced to not cause any problems with current operations. In addition only one user channel per HCI device is allowed. It is exclusive access for one user application. Access to this channel is limited to process with CAP_NET_RAW capability.
Using this new facility does not require any external library or special ioctl or socket filters. Just create the socket and bind it. After that the file descriptor is ready to speak H:4 protocol.
       struct sockaddr_hci addr;
       int fd;

       fd = socket(AF_BLUETOOTH, SOCK_RAW, BTPROTO_HCI);

       memset(&addr, 0, sizeof(addr));
       addr.hci_family = AF_BLUETOOTH;
       addr.hci_dev = 0;
       addr.hci_channel = HCI_CHANNEL_USER;

       bind(fd, (struct sockaddr *) &addr, sizeof(addr));
The example shows on how to create a user channel for hci0 device. Error handling has been left out of the example. However with the limitations mentioned above it is advised to handle errors. Binding of the user cahnnel socket can fail for various reasons. Specifically if the device is currently activated by BlueZ or if the access permissions are not present.
Signed-off-by Marcel Holtmann <[email protected]>
---
include/net/bluetooth/hci.h | 1 +
net/bluetooth/hci_sock.c | 86 ++++++++++++++++++++++++++++++++++++++++++---
2 files changed, 82 insertions(+), 5 deletions(-)
include/net/bluetooth/hci.h +0 -0
index 128157d..30c88b5 100644
@@ -1571,6 +1571,7 @@ struct sockaddr_hci {
 #define HCI_DEV_NONE	0xffff
 

Quoted 8 lines

include/net/bluetooth/hci.h struct sockaddr_hci { · line 1576
Quoted 4 lines
include/net/bluetooth/hci.h +1 -0
 #define HCI_CHANNEL_RAW		0
+#define HCI_CHANNEL_USER	1
 #define HCI_CHANNEL_MONITOR	2
 #define HCI_CHANNEL_CONTROL	3
Wouldn't this break BlueZ 4.101? It would open the channel 1 thinking it is the CONTROL one but it is not. I think we need to redefine this to 4. I can do this when applying the patch if you are okay with it.

it would not break it since I am explicitly returning EINVAL when you try to establish a user channel with HCI_DEV_NONE.

Regards

Marcel

Gustavo Padovan

2013-09-01 17:44 UTC #3 lore raw

Hi Marcel,

2013-09-01 Marcel Holtmann <[email protected]>:

Quoted 72 lines

Hi Gustavo,
Quoted 61 lines
Quoted 61 lines
This patch introcuces a new HCI socket channel that allows user applications to take control over a specific HCI device. The application gains exclusive access to this device and forces the kernel to stay away and not manage it. In case of the management interface it will actually hide the device.
Such operation is useful for security testing tools that need to operate underneath the Bluetooth stack and need full control over a device. The advantage here is that the kernel still provides the service of hardware abstraction and HCI level access. The use of Bluetooth drivers for hardware access also means that sniffing tools like btmon or hcidump are still working and the whole set of transaction can be traced with existing tools.
With the new channel it is possible to send HCI commands, ACL and SCO data packets and receive HCI events, ACL and SCO packets from the device. The format follows the well established H:4 protocol.
The new HCI user channel can only be established when a device has been through its setup routine and is currently powered down. This is enforced to not cause any problems with current operations. In addition only one user channel per HCI device is allowed. It is exclusive access for one user application. Access to this channel is limited to process with CAP_NET_RAW capability.
Using this new facility does not require any external library or special ioctl or socket filters. Just create the socket and bind it. After that the file descriptor is ready to speak H:4 protocol.
       struct sockaddr_hci addr;
       int fd;

       fd = socket(AF_BLUETOOTH, SOCK_RAW, BTPROTO_HCI);

       memset(&addr, 0, sizeof(addr));
       addr.hci_family = AF_BLUETOOTH;
       addr.hci_dev = 0;
       addr.hci_channel = HCI_CHANNEL_USER;

       bind(fd, (struct sockaddr *) &addr, sizeof(addr));
The example shows on how to create a user channel for hci0 device. Error handling has been left out of the example. However with the limitations mentioned above it is advised to handle errors. Binding of the user cahnnel socket can fail for various reasons. Specifically if the device is currently activated by BlueZ or if the access permissions are not present.
Signed-off-by Marcel Holtmann <[email protected]>
---
include/net/bluetooth/hci.h | 1 +
net/bluetooth/hci_sock.c | 86 ++++++++++++++++++++++++++++++++++++++++++---
2 files changed, 82 insertions(+), 5 deletions(-)
include/net/bluetooth/hci.h +0 -0
index 128157d..30c88b5 100644
@@ -1571,6 +1571,7 @@ struct sockaddr_hci {
 #define HCI_DEV_NONE	0xffff
 
Quoted 8 lines
include/net/bluetooth/hci.h struct sockaddr_hci { · line 1576
Quoted 4 lines
include/net/bluetooth/hci.h +1 -0
 #define HCI_CHANNEL_RAW		0
+#define HCI_CHANNEL_USER	1
 #define HCI_CHANNEL_MONITOR	2
 #define HCI_CHANNEL_CONTROL	3
Wouldn't this break BlueZ 4.101? It would open the channel 1 thinking it is the CONTROL one but it is not. I think we need to redefine this to 4. I can do this when applying the patch if you are okay with it.

Quoted 1 line

it would not break it since I am explicitly returning EINVAL when you try to establish a user channel with HCI_DEV_NONE.

Fair enough. Both patches have been applied to bluetooth-next. Thanks.

Gustavo