2

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

  1. 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

  2. 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?

Martin Zeitler
  • 1
  • 19
  • 155
  • 216
AnV
  • 2,794
  • 3
  • 32
  • 43

1 Answers1

2

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).

Martin Zeitler
  • 1
  • 19
  • 155
  • 216
  • I see mapping for `system_file` in file_contexts as `/system(/.*)? u:object_r:system_file:s0` But where is the mapping for `app_data_file`? Is there any other file where file contexts are mapped? How to achieve #2 in my question? – AnV Apr 14 '20 at 09:21
  • The build merges several of them. And it's either platform[`public`](https://android.googlesource.com/platform/system/sepolicy/+/master/public/) or platform [`private`](https://android.googlesource.com/platform/system/sepolicy/+/master/private) or in `vendor/device` (which is for device-specific custom policies). It just won't build, when any of these overlap (as it seems to be the case with your intention; it's hierarchical). – Martin Zeitler Apr 14 '20 at 09:33
  • " I'd rather wonder if this is even required and why?" - Yes,because we have one third party app which we are starting from init.rc (yes, we modify AOSP code). So, it is has root access & is able to access TelephonyManager, PowerManager and other system services in our device without we knowing it. We want to restrict its access not just to directories but other services as well. Our goal is a create a separate security context (policy, process domain, label) to restrict it. [Check this out](https://pierrchen.blogspot.com/2017/02/android-security-walk-through-of-selinux.html) – AnV Apr 27 '20 at 09:41