[Toybox] ls -l / doesn't work on pie.

[Rob Landley]

On 6/6/19 12:12 PM, enh wrote:
> On Thu, May 30, 2019 at 4:29 PM Rob Landley <rob at landley.net> wrote:
>> What exactly did this selinux addition defend against, anyway?
> 
> so the _shell_ isn't useless --- terminal apps are useless^Wless
> useful.

Only on a non-rooted phone. You're giving developers an incentive to develop on
rooted systems, and then "clean it up to work unrooted" at the last minute.

(At the very least, you're making it much harder to learn on a non-rooted device.)

> shell as in `adb shell` runs as the shell user (or root if you
> [can] `adb root`), and that's a much weaker SELinux domain meant for
> debugging/testing.

Yeah, I figured that out a couple hours later. It would be really nice if there
was an official Google shell app that could run as the shell user.

(What I'm trying to do here is build toybox binaries with the NDK and test them
on my phone. Trying to ls was "where is a good place to put the file", and it
made it unnecesssarily hard. I installed adb to do USB file transfers because
the "mount it as a disk" option went away years ago, and the funky windows
transfer client that replaced it never worked for me from Linux. I should fiddle
with the bluetooth options maybe, but adb shove works...)

> terminal apps are (unsurprisingly) apps, so they
> have all the usual restrictions from an untrusted_app SELinux domain.
> (these days there are several of these, for different target API
> levels, but the big picture is that apps can do a lot less than a
> [typically `adb shell`] user in the SELinux shell domain.)

The "simple text editor" app I use to take notes on my phone has decided that
its home directory is /storage/emulated/0 for some reason, and it can list it.
The problem with the terminal app is if you start in / and can't ls there, you
can't see where else to go. (I searched for "terminal app" and it was the first
hit, 10M+ downloads, 4.4 stars. Worked fine last phone.)

An on-screen keyboard with cursor keys would be nice, but I need to plug a usb
keyboard into a hub. I should buy a chromecast...

> this isn't actually a security think. SELinux just happened to be a
> useful hammer here. this is actually about app compatibility. there's
> a subset of apps that assume that a certain directory layout exists,
> and depend on that layout.

There should be a way to make minijail set up containers for this.

I used to do a truly horrible thing in my old Firmware Linux build (predated
Aboriginal Linux, https://landley.net/aboriginal/old) where I ran User Mode
Linux with a hostfs mount of the host's / (think "crappy network filesystem"),
then loopback mounted an ext2 image out of the hostfs and also mounted a tmpfs
to create a bunch of symlinks in pointing to directories in the hostfs and the
ext2 image, and then did a pivot-root so the tmpfs full of symlinks was the root
filesystem now and the hostfs and ext2 image were in subdirectories where the
symlinks pointed to.

It was DISGUSTING but the problem it solved was the UML processes couldn't
chown/chmod files in the hostfs (because the hostfs thought it was root but only
had write permissions as the normal user UML was running as), and this confused
the hell out of things like tar extract, so building and installing more
packages into the virtual system didn't work unless I Took Steps.

Then the kernel guys invented the --bind mount (and extended it so you could
bind mount directories rather than just mount points, and then individual
files!) and my life got easier, and shortly after that QEMU got invented and I
started using that instead of UML circa 2005 and added cross compiling to
different architectures to the todo heap (didn't have the hostfs shortcut
anymore and virtfs didn't get invented for YEARS)...

Anyway, my instincts here are "I've seen worse, I've done worse, hand me a
blowtorch". But I haven't been struggling with the problem day-to-day and you
have...

> this slows down development, as we then
> have backwards compatibility requirements we need to maintain. (random
> example: you'd be surprised how many [more than zero] apps made
> assumptions about where libc.so lives on the file system. they broke
> in Q.)

Some of this is unavoidable. If it's dynamically linked they'll be hardwired to
care about where the dynamic linker lives. (Looks like /system/bin/linker64 in a
hello world built with the current ndk...)

Sigh. I miss the days when the Linux Filesystem Hierarchy Standard mattered.
(Which was before OSDL and the FSG merged to form the Linux Foundation and
suddenly started needing a lot more money to support itself.)

> everything in / is an implementation detail, and we don't want apps
> assuming our implementation can never change. philosophically, the
> only thing apps should have visibility into is their personal
> /data/data directory. we're not enforcing a security guarantee here:
> the goal is just to enforce architectural separation of concerns, so
> that Android can iterate independent of Android's apps.

So now people have to list the root filesystem with adb shell and write it down,
look at a web page listing where things are, examine the AOSP build output, root
their phone, or look at an older android version (or older app, or ask an older
developer, out of date youtube tutorial) and check to see if backwards
compatibility still works for whatever it is on the new one?

*shrug* I can root my phone if that's what I need to do.

> for me the `adb shell ls -l /` case on a non-rooted device is more
> interesting. something like:
> 
> $ adb shell ls -l /
> total 52
> dr-xr-xr-x  29 root   root       0 1970-08-02 16:18 acct
> drwxr-xr-x  10 root   root     200 2019-05-09 21:45 apex
> lrw-r--r--   1 root   root      11 2019-05-09 20:36 bin -> /system/bin
> ...
> drwxr-xr-x  13 root   root    4096 2019-06-03 15:23 system
> drwxr-xr-x  16 root   shell   4096 2019-05-23 01:49 vendor
> ls: //init.zygote32.rc: Permission denied
> ls: //init.rc: Permission denied
> ls: //metadata: Permission denied
> ls: //init.recovery.blueline.rc: Permission denied
> ls: //init.recovery.crosshatch.rc: Permission denied
> ls: //init.usb.rc: Permission denied
> ls: //init.environ.rc: Permission denied
> ls: //init.usb.configfs.rc: Permission denied
> ls: //init.recovery.sdm845.rc: Permission denied
> ls: //ueventd.rc: Permission denied
> ls: //postinstall: Permission denied
> ls: //init: Permission denied
> ls: //cache: Permission denied
> ls: //adb_keys: Permission denied
> ls: //init.zygote64_32.rc: Permission denied
> $

I got that working the day after I sent the email. (Not the ndk, not the
sdk-tools, not the debian "apt-get install adb" that segfaults immediately when
you try to do anything with it, I needed the "platform-tools" zip. Of course, I
should have remembered.)

That's still way too many warnings, but we're arguing about what cosmetic
band-aid to put on the damage.

> that seems odd, and we've talked about GNU's use of ??? before, but i
> could also see an argument that the current output would be fine too
> _if_ the errors were sorted in with the successes.

I can implement ??? but what you probably want is to run apps in a container
where you construct a view of the system that only contains stuff you want them
to be able to see and/or rely upon. (Need access to photos, bind mount
/data/photos into the container before launching the app.) And if _this_
container needs compatibility hacks you can enumerate what they are and require
the apk be annotated with its need for them, which means you can track and
deprecate them.

I honestly thought this is what minijail was for. Doing an "it's there but not
there" thing with selinux is never going to be clean. And my own use case of "I
wanna send a new toybox binary to my phone and see what return values I get from
these system calls" wouldn't have gotten sidetracked by "where do I write the
binary to, I don't want to put it in the root directory that's icky, why can't I
see any subdirectories..."

> iirc your counterpoint at the time was that removing the `-l` should
> put us back in a situation that just works but we'd still get
> (pointless) "Permission denied" errors, and that's the argument why
> GNU-style ??? is better for data you don't have.

*shrug* I can make the cosmetic change to make the broken less obvious, but that
doesn't fix the underlying problem.

Remember many moons ago we talked about an installable "posix container"? I'm
still interested in making an android device usable as a development
workstation, and a posix container seems to be the viable approach to this,
while _also_ allowing the base OS to complicate itself into uselessness and be
replaced by a restart every 15 years as most projects seem to experience. Linux
survived as long as it has because it's _modular_. Even the long-lived projects
with continuity of code tend to fork and get redone, ala
glibc->libc5->glibc2->eglibc->glibc, gcc->pgcc->egcs->gcc, xfree86->x.org,
Mozilla->galleon->firefox... Having "an api" provided by some sort of interface
lets the implementation get swapped out. That sounds like the goal here?

Oh well, added ls ??? to the todo heap...

Rob