1190927 - Create Selinux policies for Shinano, Yukon and Rhine Lollipop devices

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: General, defect)

Description

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

The aries-l and shinano-l need selinux policies as well.

Comment 1

[:gerard-majax]

This should not be limited to those two devices.

Comment 2

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

:gerard-majax when you develop for those devices and perform testing, it would be very helpful for generating the allow rules if you could dump the denies from dmesg, like this: "adb shell dmesg | grep denied"

Because initially we create the allows with audit2allow and once everything works we can then go through the list and tighten the rules.

Thanks.

Comment 3

[:gerard-majax]

Julian, I had a look at the output and I have noticed it will highly depend also on what I am doing with the device. For example, using Bluetooth or NFC will trigger some policies. I can provide but I cannot guarantee anything sound and complete.

Comment 4

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

Yes that is correct, and that is the reason why I asked you for the logs, because initially the rules are generated based on the denials in the logs, so that we can later on go through the list and tighten it.

And the more "tests" are performed on the device the more things will be covered. It would be nice if you could from time to time dump dmesg/logcat and grep for 'denied' and save that somewhere and I will do the rest. Ideally dump the logs after doing stuff with the device and before you reboot.

Comment 5

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

Attachment: Policy files checksums

:seinlin, I have been looking at the Aries device in the last couple of days, and I am wondering how we should manage the policies there.

In Bug 1180216, we moved the sepolicy files from the qcom directory into the ./device/flame/sepolicy directory to keep them all in one place, now with the sony devices I saw that there are 3 different sepolicy locations.

Those are the locations I found:
> ./device/sony/shinano/sepolicy
> ./device/sony/yukon/sepolicy
> ./device/qcom/sepolicy

Furthermore the files located in ./device/sony/yukon/sepolicy and ./device/sony/shinano/sepolicy are mostly identical (see attachment)

Only one file differs from both directories (file_contexts):

> $ diff ./device/sony/shinano/sepolicy/file_contexts ./device/sony/yukon/sepolicy/file_contexts
> 20a21,28
> > # QCOM Blobs moved from /system/bin to /system/vendor/bin
> > /system/vendor/bin/irsc_util                  u:object_r:irsc_util_exec:s0
> > /system/vendor/bin/netmgrd                    u:object_r:netmgrd_exec:s0
> > /system/vendor/bin/qmuxd                      u:object_r:qmuxd_exec:s0
> > /system/vendor/bin/rmt_storage                u:object_r:rmt_storage_exec:s0
> > /system/vendor/bin/sensors.qcom               u:object_r:sensors_exec:s0
> > /system/vendor/bin/wcnss_service              u:object_r:wcnss_service_exec:s0
> >

Currently for all sony devices, we use the same manifest (L based):

> "leo-l"|"aries-l"|"scorpion-l"|"sirius-l"|"tianchi-l"|"flamingo-l")
>	echo PRODUCT_NAME=$1 | sed 's/..$//' >> .tmp-config &&
>	repo_sync sony-aosp-l
>	;;

It seems that all devices use the qcom policies, additionally either the shinano or the yukon policies are used (depending on the device), for Aries-L, the shinano policies are used.

Given the fact that the files in /device/sony/yukon/sepolicy and ./device/sony/shinano/sepolicy are mostly identical, I would suggest to move them into a single location along with the qcom policies, for instance into: device/sony/sepolicy/

And then let ./device/sony/yukon/sepolicy/file_contexts contain the additional labels (see above diff)

I don't know if we could run into more problems when more sony devices are added, but for know this seems like a good approach to me, what do you think?

Comment 6

[:gerard-majax]

I think it's a question Adam might be able to answer

Comment 7

[Adam Farden [:adfad666]]

I strongly suggest against moving policy files out of the platform repos. The current policies come from upstream, moving them will will probably cause headaches later as we merge upstream changes (for example when we get camera blobs).

Deduplication of files is nearly always a good thing, but in the case of Sony repos we made a conscious decision to keep each platform self contained. Experience from maintaining devices at CyanogenMod proves that deduplication can go too far, and you end up with ifdef spaghetti.

qcom/sepolicy is just a fork of CAF with a patch to ensure the policies are loaded in the correct order. IT was necessary for us to do this on AOSP as it lacks a common sepolicy repo (each nexus devices has highly specific policies in its own repo).

It may be possible for us to grab the same thing directly from CAF if that is easier, there's nothing of significance added here.

Also the policies are not comprehensive, just enough to prevent denials on first boot. I'm pretty sure there will be more policies needed that we can contribute back upstream.

Comment 8

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

Thank you very much Adam. I agree that it is easier to stay up to date with upstream changes if we don't move those policies around. It may be worth reconsidering the decision to move them out of the platform repos in Bug 1180216 (I will raise the question later).

The problem on Bug 1180216 was that device/qcom/sepolicy/Android.mk didn't append to the variables BOARD_SEPOLICY_UNION and BOARD_SEPOLICY_DIRS which lead to previous content being overwritten.

Anyways, this problem doesn't exist here since the fork already made the necessary changes.

Alright, so just to be on the same page: ./device/qcom/sepolicy should be left alone, and unifying ./device/sony/shinano/sepolicy and ./device/sony/yukon/sepolicy could lead to problems (previous experience)?

What is required here is that we create rules that allow the interaction between the device domains (created in ./device/sony/shinano/sepolicy etc) and the b2g common domains (created in ./gonk-misc/sepolicy/).

As far as I can see it right now, those rules would be the same for yukon and shinano based devices so theoretically it should be possible to use the same policy files for both. But it may also be possible that in the future yukon gets domains that shinano doesn't get (different blobs for example) which brings us back to the deduplication problem.

So I would suggest the following approach (based on the previous discussion):

Create the rules that grant the interaction between b2g common domains and device specific domains and store them in, ./device/sony/yukon/sepolicy/ and ./device/sony/shinano/sepolicy along with the other device specific rules. This way we will probably have redundant data between those two (same as with the currently existing files) but it will probably save us some headaches in the long run.

What do you think Adam?

Comment 9

[Adam Farden [:adfad666]]

(In reply to Julian Hector [:tedd] [:jhector] from comment #8)
> So I would suggest the following approach (based on the previous discussion):
> 
> Create the rules that grant the interaction between b2g common domains and
> device specific domains and store them in, ./device/sony/yukon/sepolicy/ and
> ./device/sony/shinano/sepolicy along with the other device specific rules.
> This way we will probably have redundant data between those two (same as
> with the currently existing files) but it will probably save us some
> headaches in the long run.

Yes that's exactly what I had in mind. The structure is almost identical, so if we do it correctly then we shouldn't have any problems to commit on shinano then cherry-pick the same to the other platform repos.

Comment 10

[Kai-Zhen Li [:seinlin][:kli]]

:teed, Sorry for late reply. Adam and you already got some discussion. I also think to keep the repos close to upstream is a point. And the situation of sony devices is also different to Flame bug 1180216.