On Wed, Jun 17, 2015 at 7:17 AM, Stephen Smalley <[email protected]> wrote:
> 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? > No, because its a consistent way to do something. I'm a fan of their should only ever be one way to do something. This example is the extreme. For others commenting that they need to run a one shot service with an single command, they could make a general purpose shell script that execs whatever the arguments are and transitions to the domain defined in policy. Then they dont need to have 100's of scripts. > > > > > > > > 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]. > > > > -- 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].
