On 06/10/2014 04:48 PM, Dinesh Garg wrote:
>>>What do you mean by "partition number is not fixed"?
> It is specified in general partition table which can change from time to
> time. For example, partition in question may be /dev/block/mmcblk0p2 in
> one table (or build) while it could be /dev/block/mmcblk0p30 in another.
>
>>> When and how does it get assigned?
> I dont know how it gets decided whether it is going to be
> /dev/block/mmcblk0p2 or /dev/block/mmcblk0p30 or something else. XML
> file mentions all the partitions names and sized required and a tool
> would generate the partition table.
>
> As you explained how a final label is assigned to a file, is it possible
> that a file can have multiple labels, may not be in security.selinux but
> in memory. If a file has associated links (not sure if it is other way
> around), check the rule against rules stored in memory as well.
>
> Example:
>
> /dev/block/mmcblk0pN has a label partitionN_label
> /path/mylink1 has label link1_label
> /path/mylink2 has label link2_label
>
> Assume both link points to /dev/block/mmcblk0pN
>
> mylink1 -> /dev/block/mmcblk0pN
> mylink1 -> /dev/block/mmcblk0pN
>
> Now daemon1.te has following rule
>
> allow daemon1 link1_label:chr_file {read write ...}
>
> In current scenario security.selinux of file would have partitionN_label.
>
> Hence, whenever daemon1 tries to access the file, it does not have
> permission and denial would come. But if for links, we can store rule in
> memory and check as follows:
>
> daemon1 tries to open mylink1:
> if (resource is link type && !match(rule for file_attr)
> check_rules_from_memory(mylink1, current_process)
>
> I am just throwing ideas, not sure about if this is possible.
No, it is by design that SELinux only allows a single security
context/label per file/inode (on storage or in memory). Otherwise you
cannot analyze the policy alone to determine all possible information
flows; you would have to also analyze the object state, which could
change over time.
If you know the partition number at build time, then you can generate a
file_contexts line at build time with the real pathname of the device
node. That is the simplest solution and requires no changes to the
kernel or userspace code. Just requires a change to your .mk files or
other build infrastructure to append a line to
device/<vendor>/<board>/sepolicy/file_contexts and define your
BOARD_SEPOLICY_DIRS and BOARD_SEPOLICY_UNION variables to include that
directory and file into the policy at build time. You can also put it
in your vendor/<vendor>/<board>/sepolicy directory and define the
variables in your device-partial.mk or similar makefile.
If the partition assignment were truly dynamic at runtime (as opposed to
build time), then we could change ueventd and libselinux to try to look
up both the real path and all of the link names and give precedence to
any completely specified name (i.e. no regex). But that will require
code changes and it is unclear it is justified in this scenario if
everything is known at build time.
_______________________________________________
Seandroid-list mailing list
[email protected]
To unsubscribe, send email to [email protected].
To get help, send an email containing "help" to
[email protected].
