On 06/10/2014 12:42 PM, Dinesh Garg wrote:
> Hi,
> I have a scenario where daemon has to read the whole partition. There is
> no filesystem on partition. So I can't provide access to specific files.
> When I generate the rule from denial logs, it comes as follows:
> 
> allow daemon1 block_device:blk_file { read write getattr open ioctl };
> 
> It is not good idea to provide access to block device to any daemon. I
> want to do as follows:
> 
> Suppose my partition is /dev/block/mmcblk0N
> There is symlink that points to it, say mylink
> 
> mylink->/dev/block/mmcblk0N
> 
> Would it be possible to apply a label to symlink
> 
> /path/mylink <mylabel>
> 
> and then write the rule
> 
> allow daemon1 mylabel:blk_file { read write getattr open ioctl };
> 
> Could there be any issue with this?

A similar problem and its solution is described in slides 46-47 of my
Android Builders Summit 2014 presentation at:
http://events.linuxfoundation.org/sites/events/files/slides/abs2014_seforandroid_smalley.pdf

The resulting policy changes are included in the
device/lge/hammerhead/sepolicy files in AOSP master.

With regard to labeling by symlink, that is not presently supported; you
have to specify:
/dev/block/mmcblk0N    u:object_r:<yourtype>:s0
in your device/<vendor>/<board>/sepolicy/file_contexts configuration as
was done for hammerhead.

We could possibly look at changing ueventd to support label by symlink
but I'm not entirely clear on how that would work.
system/core/init/devices.c:handle_device() creates the device node via
make_device(), which presently is instrumented to look up the
file_contexts entry that matches the device node path and label the
device file accordingly, similarly to the handling for uid/gid/mode
based on ueventd.*.rc, and then handle_device() calls make_link() to
create the links to the device node.  But there may be 0, 1, or many
such links so labeling by link name could be ambiguous.  Also, by
default, all files under /dev will match the /dev(/.*)?
u:object_r:device:s0 entry in file_contexts if there is no more specific
match, so the link names will always match something even if they are
not specified in file_contexts explicitly, so we cannot merely use the
selabel_lookup() return value to determine whether there was an entry
for the link name.  Open to suggestions but I think your best path at
present is to specify the real path...
_______________________________________________
Seandroid-list mailing list
Seandroid-list@tycho.nsa.gov
To unsubscribe, send email to seandroid-list-le...@tycho.nsa.gov.
To get help, send an email containing "help" to 
seandroid-list-requ...@tycho.nsa.gov.

Reply via email to