1224195 - [Shinano L] Label bluetooth related files with their proper SELinux domain

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: GonkIntegration, defect)

Description

[Julian Hector [:tedd] [:jhector]]

On the Shinano platform, bluetooth related files are not labeled with their proper SELinux domain, which leads to denials when the bluetooth domain tries to access those files.

Because the bluetooth domain doesn't have any rules for the generic file type applied to those files.

For example, /dev/ttyHS0 (the bluetooth device) is labeled with 'serial_device':

> adb shell ls -laZ /dev/ttyHS0 
> crw------- bluetooth net_bt_stack          u:object_r:serial_device:s0 ttyHS0

instead it should be labeled with 'hci_attach_dev'.

Based on the init.shinano.rc [1] and logged denials on my device, the following files need to be labeled:

> /dev/ttyHS0

with hci_attach_dev

> /sys/class/rfkill/rfkill0/state

with sysfs_bluetooth_writable

> /proc/bluetooth/sleep/btwrite
> /proc/bluetooth/sleep/lpm
> /proc/bluetooth/sleep/proto

with proc_bluetooth_writable

[1] https://github.com/mozilla-b2g/device-sony-shinano/blob/9dbabde0103cec11ab6fb93f8ff48170806548e7/rootdir/init.shinano.rc#L196

Comment 1

[:gerard-majax]

Is that something B2G specific or that we should fix upstream?

Comment 2

[Julian Hector [:tedd] [:jhector]]

As far as I can tell, this is nothing B2G specific, and I think it would make sense to fix it upstream as well.

For example the /dev/ttyHS0 device, Android has a domain defined for hci devices [1] but as the comment said those devices are device specific, I believe it is called 'hci_attach_dev' because they have a 'hci_attach' service.

Either way I believe it makes sense for us/them to use hci_attach_dev, because for example the default 'bluetooth' domain provided by Android [2], which is used by apps that have bluetooth access, uses the 'hci_attach_dev' to grant access to the bluetooth device [3]

I think by labeling the device according to the "Android way", it would be a win-win situation for them because it would also allow for the Android rules to apply.

The same goes with the rest of the files. 

Should I make a PR to the upstream repo? And we would then simply fast-forward?

[1] https://github.com/mozilla-b2g/platform_external_sepolicy/blob/b2g-5.1.0_r1/device.te#L55
[2] https://github.com/mozilla-b2g/platform_external_sepolicy/blob/b2g-5.1.0_r1/bluetooth.te
[3] https://github.com/mozilla-b2g/platform_external_sepolicy/blob/b2g-5.1.0_r1/bluetooth.te#L18

Comment 3

[Julian Hector [:tedd] [:jhector]]

Oh and btw :gerard-majax, do you have access to the rest of the Shinano devices?

If so, could you check what the destination of the '/sys/class/rfkill/rfkill0' link is?
On my Aries it is '/sys/devices/bluesleep.89/rfkill/rfkill0'.

I ask because in the policy we can't use the link to label the file.

Comment 4

[:gerard-majax]

Do PR against the Sony repos on https://github.com/sonyxperiadev/

Comment 5

[:gerard-majax]

(In reply to Julian Hector [:tedd] [:jhector] from comment #3)
> Oh and btw :gerard-majax, do you have access to the rest of the Shinano
> devices?
> 
> If so, could you check what the destination of the
> '/sys/class/rfkill/rfkill0' link is?
> On my Aries it is '/sys/devices/bluesleep.89/rfkill/rfkill0'.
> 
> I ask because in the policy we can't use the link to label the file.

All shinano share the same platform so there should be no difference on that. Yukon and Rhine devices might be different.

Comment 6

[:gerard-majax]

On rhine platform with amami device (Z1 Compcat),
> root@amami:/ # ll /sys/class/rfkill/rfkill0                                    
> lrwxrwxrwx root     root              2015-11-12 08:17 rfkill0 -> ../../devices/fb000000.qcom,wcnss-wlan/ieee80211/phy0/rfkill0

Comment 7

[:gerard-majax]

Even after enabling Bluetooth there is no other rfkill on that device. And that one obviously refers to WiFi

Comment 8

[:gerard-majax]

And no rfkill class at all on Yukon Eagle device (Xperia M2)

Comment 9

[Julian Hector [:tedd] [:jhector]]

Thanks :gerard-majax, I mean the full path has to be labeled anyways, and if it doesn't exist it is no big deal, so we should be good for the Shinano platform.

Upstream PR was merged:
https://github.com/sonyxperiadev/device-sony-shinano/commit/7ab3ac0da81a9f6c32f6707f4555006879fb5583

But I think we need to cherry-pick it since sony-aosp-l differs quite some bit compared to l-mr1.

Comment 10

[Julian Hector [:tedd] [:jhector]]

Attachment: PR device-sony-shinano - Merge upstream changes

Comment 11

[:gerard-majax]

https://github.com/mozilla-b2g/device-sony-shinano/pull/27

Comment 12

[:gerard-majax]

Julian, do we need the same work for Yukon and Rhine devices ?

Comment 13

[Julian Hector [:tedd] [:jhector]]

Probably yes, but it depends, it will probably be different. I assume those platforms have a bluethooth chip as well, but the device name might be different.

Having a quick look at the init.rc from yukon says that the bluetooth device is /dev/ttyHSL0.