On 06/17/2015 02:21 PM, William Roberts wrote: > > > On Wed, Jun 17, 2015 at 10:24 AM, Nick Kralevich <[email protected] > <mailto:[email protected]>> wrote: > > > On Wed, Jun 17, 2015 at 10:14 AM, William Roberts > <[email protected] <mailto:[email protected]>> wrote: > > I'm more OK with that approach. What about removing all in tree > uses? > > > If we can, sure. > > Not sure how you're going to solve the ueventd/watchdogd symlink > problem - I agree that relying on symlink labeling is error prone > and something we should avoid... > > > Can someone please give me an argument that shows that its error prone? > How is launching ueventd and watchdog from symlink not-error prone but > having an fc entry for it is?
You're using the context of the symlink to make a label computation when that context has nothing to do with the context of the actual executable and the target of the symlink can be changed at any time. I guess either way our entrypoint permission check will at least ensure that you can't replace the target of the symlink with something that is not an authorized entrypoint type. However, for some of these cases, we have to allow entrypoint to all rootfs executables (if not labeling them) or to the shell, and that then obviously means that one could enter the domain via any rootfs executable or run an arbitrary shell script in that domain. Probably won't matter for files in rootfs or /system given our neverallows on writing to either of those locations. I would just be concerned with how it might get abused by OEMs. > As an alternative thought I can get rid of the symlinks to the start > ueventd and watchdogd and replace them with minimal C shims that call > init with an argument for > the mode of operation. Then we can label that executable. I think that was the approach taken in busybox for SELinux. But again I have to ask whether it is worth it versus just continuing to use seclabel. Not convinced it is justified. _______________________________________________ Seandroid-list mailing list [email protected] To unsubscribe, send email to [email protected]. To get help, send an email containing "help" to [email protected].
