Our BT folks said net/bluetooth create child sockets for each protocol, which
do not call security API, thus, the child socket doesn’t have label.
They suggested the following change for l2cap_sock.c
void l2cap_sock_init(struct sock *sk, struct sock *parent)
{
struct l2cap_pinfo *pi = l2cap_pi(sk);
BT_DBG("sk %p parent %p", sk, parent);
if (parent) {
sk->sk_type = parent->sk_type;
sk->sk_rcvbuf = parent->sk_rcvbuf;
sk->sk_sndbuf = parent->sk_sndbuf;
bt_sk(sk)->defer_setup = bt_sk(parent)->defer_setup;
pi->imtu = l2cap_pi(parent)->imtu;
pi->omtu = l2cap_pi(parent)->omtu;
pi->conf_state = l2cap_pi(parent)->conf_state;
pi->mode = l2cap_pi(parent)->mode;
pi->fcs = l2cap_pi(parent)->fcs;
pi->max_tx = l2cap_pi(parent)->max_tx;
pi->tx_win = l2cap_pi(parent)->tx_win;
pi->sec_level = l2cap_pi(parent)->sec_level;
pi->role_switch = l2cap_pi(parent)->role_switch;
pi->force_reliable = l2cap_pi(parent)->force_reliable;
pi->flushable = l2cap_pi(parent)->flushable;
pi->force_active = l2cap_pi(parent)->force_active;
pi->amp_pref = l2cap_pi(parent)->amp_pref;
security_sk_clone(parent, sk); // <<< Cloning the context from the parent
}
Similar changes also needed for rfcomm/sock.c in function rfcomm_sock_init(sk,
parent).
After applying the patch, I don’t see the unlabeled socket audit messages
anymore. However, I don’t see the same code in the msm kernel in branch 4.4.2.
Thus, I want to check if the msm kernel also has the same issue or the msm
kernel fix the problem differently.
Thanks,
Tai
On 2/19/14, 4:54 PM, "Tai Nguyen (tainguye)"
<[email protected]<mailto:[email protected]>> wrote:
I traced our BlueZ Bluetooth software to the driver at kernel
net/bluetooth. I did a diff between our code and the 4.4.2 branch
kernel/msm/net/bluetooth.
Although there are differences in these 2 versions, nothing stand out that
our version doesn¹t call security_socket_post_create().
In fact, I can¹t find where the kernel/msm/net/bluetooth set the security
context for its sockets.
Thus, I need your help to understand more on how the
kernel/msm/net/bluetooth have their sockets labeled.
Thanks,
Tai
On 2/18/14, 11:06 AM, "Stephen Smalley"
<[email protected]<mailto:[email protected]>> wrote:
On 02/18/2014 10:49 AM, Tai Nguyen (tainguye) wrote:
Hi Stephen,
Do you have any suggestion where and what do I look for in the kernel?
What context should it have in this case?
Sockets should be labeled with the context of the creating process.
So either there is something wrong in your kernel bluetooth code such
that a socket is being created without ever calling the corresponding
security hook to label it or you have a process running in unlabeled
that created the socket (the latter should only happen if you reloaded
policy and invalidated the context of an already running process).
Normally this gets handled by the __sock_create() function in
net/socket.c, called by the various sock_create() functions. Calls
security_socket_create() before creating the socket to check permissions
and then calls security_socket_post_create() after creating the socket
to label it. The SELinux functions are then selinux_socket_create() and
selinux_socket_post_create().
_______________________________________________
Seandroid-list mailing list
[email protected]<mailto:[email protected]>
To unsubscribe, send email to
[email protected]<mailto:[email protected]>.
To get help, send an email containing "help" to
[email protected]<mailto:[email protected]>.
_______________________________________________
Seandroid-list mailing list
[email protected]
To unsubscribe, send email to [email protected].
To get help, send an email containing "help" to
[email protected].
