Where are directory paths mapped to labels in SE Linux?

Question

1.34M viewsSeptember 10, 2022android android-5.1.1-lollipop android-source google-source-repositories selinux

1

AnV September 7, 2022 0 Comments

I see that Filesystem types and file types are declared in /external/sepolicy/file.te in AOSP.
But each type is representing or mapped to particular directory as mentioned in the comments.

Link: https://android.googlesource.com/platform/external/sepolicy/+/refs/heads/lollipop-release/file.te

Example 1:

#Default type for anything under /system.
type system_file, file_type;

Example 2:

#/data/data subdirectories - app sandboxes
type app_data_file, file_type, data_file_type;

It means we are declaring a type app_data_file and associate this type to the attributes file_type and data_file_type

Note: All attributes are declared in the attributes file.

Link: https://android.googlesource.com/platform/external/sepolicy/+/refs/heads/lollipop-release/attributes

It is mentioned that the type system_file is for the path /system and app_data_file is for /data/data subdirectories. But where are these types and paths mapped or associated explicitly? If they aren’t mapped anywhere, then how will the OS know that system_file is for /system
If I have to create a new type my_app_type and map it to the dir /data/com.my_app/photos/, how do I achieve that?

1 Answer

score 2 · Answer 1 · 2022-09-08T03:52:36+00:00

These are being labeled, eg. with device/manufacturer/device-name/sepolicy/file_contexts and further file_contexts files (as one can see when building AOSP). See Label new services and address denials for a more detailed explanation.

Also see the RHEL documentation (where it comes from), because the second part of the question is difficult to answer; I’d rather wonder if this is even required and why? If I understand the purpose of that directory properly, on Android this might rather be the job for FileProvider, to expose these files to other applications. Lowering the security standards generally is not a good idea, while there is another way available, which would access from an already permitted security context. I mean, even if one can list the labels with ls -laZ (alike a file-system listing), the security context is always the perspective from which the access happens. The AndroidX Camera2Basic example would demonstrate what I mean by that (it’s FileProvider for the app internal storage).