On 06/17/2015 10:39 AM, William Roberts wrote:
>
>
> On Wed, Jun 17, 2015 at 7:17 AM, Stephen Smalley <[email protected]
> <mailto:[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]>
> > <mailto:[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]>>
> > > <mailto:[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.
I guess we'll just have to agree to disagree. I think there are valid
use cases for seclabel, and don't believe it should be removed
altogether. By all means, add a restorecon_recursive("/sbin") and
eliminate uses of seclabel that were only required due to lack of
per-file labeling there. But otherwise, I don't think we are making
things better by insisting on never using seclabel.
_______________________________________________
Seandroid-list mailing list
[email protected]
To unsubscribe, send email to [email protected].
To get help, send an email containing "help" to
[email protected].
