On Wed, Jun 17, 2015 at 5:42 AM, Stephen Smalley <[email protected]> wrote:
> On 06/17/2015 08:37 AM, William Roberts wrote: > > > > > > On Wed, Jun 17, 2015 at 5:24 AM, Stephen Smalley <[email protected] > > <mailto:[email protected]>> wrote: > > > > On 06/17/2015 07:09 AM, William Roberts wrote: > > > I was forgetting that ueventd and watchdogd are just symlinks back > to > > > init, not sure what the best approach is for them. Perhaps we could > > > compute the "seclabel" implicitly from the linkfile label and > > > setexecon() based on that. > > > > No, just keep using seclabel for them, please. > > There are legitimate uses for seclabel; we just want to keep them > > minimal > > > > > > Yes I am not saying those are invalid uses of seclabel. However, to have > > N different ways > > of doing things is less than ideal. It should be either present and used > > in many places, or dead completely. > > If we leave support for it, its one more thing a policy author needs to > > learn and understand. what are the > > problems with computing it, we have the information available to > > properly do so. We would likely want to > > verify that the links resolve within the rootfs. > > If you look further up in the thread, you'll see that Johan and I both > pointed out cases where it is still legitimate and likely required to > use seclabel. I don't believe you can kill it entirely. > Their wasn't a single use case that could be covered with a different approach, such as labeling shell-scripts. > > Relying on a symlink label is perilous and diverges even farther from > normal SELinux behavior than just explicitly specifying the label via > seclabel. > The nice part about this, is that all the context is in the policy and not hard-coded throughout (granted these domains are unlikely to change much). The symlink is already used as the exec path, why not just use it for the context as well? The other option is to pass it as an argument. but that has some of the same limitations as seclabel. I would like to get all the hardcoded labels out of init.rc, which also would include the argument to adbd in the future (the "shell" domain to transition to could be computed on the result of the su binary if present). -- Respectfully, William C Roberts
_______________________________________________ Seandroid-list mailing list [email protected] To unsubscribe, send email to [email protected]. To get help, send an email containing "help" to [email protected].
