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.) 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. > 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. _______________________________________________ Seandroid-list mailing list [email protected] To unsubscribe, send email to [email protected]. To get help, send an email containing "help" to [email protected].
