On Wed, Jun 17, 2015 at 6:41 AM, Stephen Smalley <[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]>> 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) > > 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].
