Since partition number is not fixed, following hammerhead example would lead to providing access to all partitions eventually. This would be no better than rule created using denial logs.
Similarly, specifying real path in policy is not possible. I am not sure if xattr supports storing multiple labels for the same file. In that case, labels for symlinks can be stored in the same node. On Tue, Jun 10, 2014 at 10:12 AM, Stephen Smalley <[email protected]> wrote: > 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 [email protected] To unsubscribe, send email to [email protected]. To get help, send an email containing "help" to [email protected].
