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. Br, Johan Redestig -----Original Message----- From: Stephen Smalley [mailto:s...@tycho.nsa.gov] Sent: den 3 juni 2015 15:53 To: Redestig, Johan; 'Roberts, William C'; Nick Kralevich Cc: Seandroid-list@tycho.nsa.gov Subject: Re: killing init seclabel On 06/03/2015 02:56 AM, Redestig, Johan wrote: > When invoking utilities like rmdir from the init scripts it would still > be useful to specify in what domain you want them to be executed. > Alternatively one can wrap all such calls in scripts that are labeled, > though that seems a bit awkward? If it is a built-in command, then it will just run in in-process and thus in init's domain. If it is an exec, then the new exec command supports specifying a seclabel as an option to exec. But that's different than the service seclabel option that he was talking about removing, which is used for services whose executables are in the rootfs or that are shell scripts rather than their own executables. Shell script files can be labeled and cause an automatic transition if they are directly executed but if they are run indirectly via /system/bin/sh then the kernel will only see it as an exec of sh and a read of the script file so no transition will occur automatically. _______________________________________________ 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.
