On 6/6/19 12:12 PM, enh wrote: > On Thu, May 30, 2019 at 4:29 PM Rob Landley <[email protected]> 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 _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
