On 06/17/2015 10:01 AM, William Roberts wrote: > > > On Wed, Jun 17, 2015 at 6:41 AM, Stephen Smalley <[email protected] > <mailto:[email protected]>> wrote: > > On 06/17/2015 08:52 AM, William Roberts wrote: > > > > > > On Wed, Jun 17, 2015 at 5:42 AM, Stephen Smalley <[email protected] > <mailto:[email protected]> > > <mailto:[email protected] <mailto:[email protected]>>> wrote: > > 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. > > 1. console service or anything else that just executes /system/bin/sh > (Your answer would be to add an automatic transition to shell domain for > console service, but that could easily lead to OEMs adding more and more > permissions to the shell domain for things that are being done by shell > scripts and inline shell commands, which is why we have not done it to > date and previously had a separate init_shell domain.) > > > No my argument would be to have a shell script called "console" and label > it console_exec and transition init: > domain_auto_trans(init, console_exec, shell)
It isn't a script or a shell command. It is just running an interactive console shell. Sure you could probably create a console script containing: #!/system/bin/sh /system/bin/sh But that seems pretty silly, doesn't it? > > > > 2. any shell script invoked via /system/bin/sh /path/to/script > (Your answer would be that they should just replace with direct > execution of /path/to/script and label the script file, and that's fine, > but it is an extra burden on them with no real gain in security compared > to using seclabel, and nothing today ensures it.) > > 3. any inline shell command invoked via /system/bin/sh -c > (Your answer would be that they should move it to a script file and > label it, but that's more work for them for no real gain, and again > nothing today ensures it) > > 4. any executable in a filesystem that does not support per-file > labeling > (You are trying to address this for rootfs by introducing per-file > labeling for executables but it may not be the only such case) > > 5. any shared executable used for many different commands/purposes that > ought to run with different permissions > (Your symlink-based approach is your solution to this one, but I don't > agree with it, see below) > > > 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? > > We do prefer not hardcoding security contexts outside of some kind of > policy configuration file, although there are clearly context > configuration files of varying kinds used by SELinux outside of the > kernel policy. > > Is the init.rc file really any more hardcoded though than the SELinux > kernel policy or other context configuration files? They are all > configuration data, they all live in the rootfs, and they all can only > be changed together by reflashing the boot image. Admittedly, this > ignores the /data/security policy, but it isn't clear that AOSP uses > that or wants to keep it around, and the service domain assignments are > not likely to be changed by a policy update, only the permissions > granted to them (and we don't even have support for restarting services > upon a policy update, so you can't really do that safely anyway). > > Computing the context from the symlink creates an illusion that there is > some binding between the process context and the symlink context, when > no such binding is enforced by the kernel (the entrypoint check will be > applied between the process context and the final executable context, > not the symlink), and further that there is some binding between the > symlink and its target, when no such binding is enforced by the kernel. > Obviously one can have write access to the target context without > having write access to the symlink context, although with the rootfs you > shouldn't have write to either. > > > This boils down to maintainability and ease for many targets and > configurations. > In my case, I want to be able to watch one project in fast moving tree > and be > able to control what others are doing. If someone makes a commit to > policy as > well as N device targets for seclabel updates, its a PITA. Sure, you > could start > declaring common init.rc's but that gets funky as well. From a user > standpoint, > they likely don't care about the details. I am not looking to make this > more-secure, > (def not less secure) Im looking to make it more user-friendly and > maintainable. > 99% of the OEM engineers making policy changes don't understand it to this > level and its trivial to bury the details in macros and attributes so it > just works. > > > > 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). > > I don't mind limited usage of seclabel in init.rc. I just think we > ought to only use it where there is a legitimate use case for it. > > > The only think I could see it being a problem for is filesystems that cannot > support seclabel's. Perhaps this should be a requirement, I know of no > such issues around this as of now. > > -- > 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]. > _______________________________________________ Seandroid-list mailing list [email protected] To unsubscribe, send email to [email protected]. To get help, send an email containing "help" to [email protected].
