On Wed, Jun 17, 2015 at 1:12 PM, Nick Kralevich <[email protected]> wrote:
> > > On Wed, Jun 17, 2015 at 1:03 PM, William Roberts <[email protected] > > wrote: > >> > 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. >>> >> >> That I could agree with more than the other arguments presented. Is the >> work vs tradeoff worth it. However, IMHO presenting a single way of >> doing something is the right choice. >> >> > One way I judge complexity is number of lines required to perform a > certain operation. With seclabel, we only require 1 line of code. Moving > seclabel to file_contexts is still only one line of code. But if we're > talking about creating minimal C shims, then even though the same result > may be achieved, the number of lines goes up substantially. > seclabel might only be one line, but what about all the supporting code in init. It takes aprox 40 (very quick aproximation of my patch to drop it) lines and additional branches to support seclabel. The shim file is only be a few lines and we can use the same code for each executable. Then we add the fc entries (which is null since were subtracting from init.rc) and one line for restorecon_recursive(). So from a LOC standpoint, its about the same or less, and excercising the existing SELinux functionality. Sample Shim: #include <string.h> #include <unistd.h> int main(int argc, char *argv[]) { char *args[argc + 1]; argc++; memset(args, 0, sizeof(argv) * argc); memcpy(args, argv, sizeof(argv) * argc); return execvp(argv[1], args); } Example usage: ueventd /init <args> watchdogd /init <args> > > Also problematic with any change is the confusion and learning curve in > introducing the change. Getting rid of seclabel would break other devices > out there, and would require people to learn a new way to interact with > SELinux. I'm OK with breaking something, but only if the gain justifies the > short term pain. For seclabel, I'm not seeing the benefit outweigh the > pain. Yet. > Agree there somewhat. However their have been substantial changes made on the AOSP side that were very disruptive (not just in selinux, its part of being downstream), people adapt. Since I have been at various OEM shops, I see the misuse of seclabel often. My only recourse is to attempt to scan all of the device trees regulary to make sure its used properly. The pain for me is maintenence, both from being downstream and having to port. Killing seclabel would save condierable resources and allow SELinux controls on services to be expressed purely in policy. One of the strengths of SELinux is central policy, however thats not always the case (labeling is spread out). Getting it out of init scripts minimizes this spread-outness. > > Perhaps one day it will get there, but a prerequisite is that we're able > to ship devices for a few releases without having the need to use seclabel, > ever. > Agreed 100%.
_______________________________________________ Seandroid-list mailing list [email protected] To unsubscribe, send email to [email protected]. To get help, send an email containing "help" to [email protected].
