On 06/03/2015 01:37 PM, Stephen Smalley wrote: > On 06/03/2015 10:17 AM, Redestig, Johan wrote: >> For built in commands seclabel obviously is not a factor (I was referencing >> rmdir because that is something we usually invoke as an external command >> since the internal implementation of it does not make any sense). >> >> There have recently been a couple of new exec users that explicitly set the >> seclabel. It may just become a pattern others follow. I shared the concern >> of not unnecessarily specifying the seclabel in the init files, just >> pointing out that there are legitimate uses of besides the ramdisk >> limitation, so killing it entirely would have other consequences. And from >> this point of view exec/service is identical, just difference syntax. > > Looking at system/core/rootdir/init.rc, I see these two exec calls: > 324: exec u:r:tzdatacheck:s0 system system -- /system/bin/tzdatacheck > /system/usr/share/zoneinfo /data/misc/zoneinfo > 657: exec - logd log -- /system/bin/logcat -L -b all -v threadtime -v > usec -v printable -D -f /data/misc/logd/logcat -r 64 -n 256 > > Not clear that the first one needs a seclabel or could just use "-" to > indicate use of the default since policy defines a transition for > tzdatacheck? > > Second one is already using the - notation to indicate the default. > > We only need a seclabel if we cannot assign the executable a unique file > context that will trigger an automatic domain transition upon exec, as > with rootfs binaries or commands that share a common binary but require > different domains (e.g. if you wanted to run different toybox/toolbox > commands in different domains). > > I wouldn't suggest removing seclabel support altogether, but we should > try to minimize its usage to only the cases where it is truly required.
Oh, I see - the support for specifying the default via - was only just added to AOSP master yesterday, https://android-review.googlesource.com/#/c/153011/ So when the tzdatacheck entry was added that was not yet supported. _______________________________________________ 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.
