On Wed, Aug 16, 2023 at 1:08 PM Rob Landley <r...@landley.net> wrote: > > On 8/16/23 14:42, enh wrote: > > On Wed, Aug 16, 2023 at 12:33 PM Rob Landley <r...@landley.net> wrote: > >> > >> On 8/16/23 09:14, enh wrote: > >> > strace other cp implementations? > >> > >> I was hoping someone somewhere would actually have/know rules. :P > >> > >> Alas strace doesn't show you that it checked 3 stat fields and then did > >> this > >> thing, otherwise it would have done that other thing. You just get the one > >> codepath it took. And "I broke it" is way easier to spot than "I opened up > >> a > >> theoretical security hole which somebody will exploit eight years from now > >> in > >> combination with 3 other things." > > > > in part i meant "...and see that they're not doing it either, so > > no-one's cared yet" :-) > > "It's no worse than what glibc does" is not my metric. :) > > >> I understand unix permissions, ownership, and filesystem atomicity: it > >> helps > >> that they're 30-50 years old, simple, and widely used. (And that most > >> systems > >> give each user their own group and leave it at that.) I think I understand > >> at > >> least what containers are trying to accomplish. But I don't understand > >> selinux > >> at all (even the mechanisms, let alone any specific rulesets), and am > >> uncomfortable trying to reason with it. I've seen too many "selinux vetoed > >> setuid and now this code is continuing to run with privileges it thought it > >> dropped" corner cases over the years where selinux's micromanaging of the > >> unix > >> security model went about as well as china's micromanaging of its river > >> systems, > >> and I tend to want to call in a professional when the topic comes up. > > > > i am not a security professional, > > Me neither, for the same reason I'm not a cryptographer or kernel designer. > You > do that _or_ you do everything else. Full time red queen's race staying > current. > > But I like to know what the general issues are... > > > but i'm pretty sure they'd say "why > > do you even have a writable file system? _that's_ your mistake right > > there!" :-) > > https://lists.uclibc.org/pipermail/uclibc/2002-September/004380.html#:~:text=zisofs > > Goddess I'm old. (It was _hard_ to get a compressed read only root filesystem > working on linux back in the year 2000. I had to symlink /etc to /var/etc.) > > The most secure system is unplugged, flattened with a steamroller, burned to > ash > and the ashes mixed in concrete and shot into the sun. Except then you've made > the classic blunder of losing the ability to re-verify they did it to the > right > machine. (Villain is not dead without a body.) > > > if you care, you want an fsverity-protected read-only file system > > anyway. the only people copying files and their xattrs around are > > developers on rooted devices which on boot show you a big red "this > > device is insecure" screen. > > I long ago came to the conclusion I can't make a system secure, all I can do > is > annoy attackers into choosing a less vexing target. But I don't want to the > the > same to users or developers, so it's always a balancing act.
meh, if your selinux labels are wrong, stuff stops working. you can either fix it yourself or `setenforce 0` if you _know_ what you're doing isn't compatible with selinux rules for actual shipping systems and don't care because you're just testing a thing. > (And yes, back when I was doing j-core there were hardware discussions about a > thermal sensor to detect the liquid nitrogen before chip decapping to > discharge > a capacitor to do a thing. There was never NOT a "and here's how you defeat > THAT". Physical custody of the hardware in the hands of state actors on good > terms with the _really_ aspie hobbyists beats pretty much everything.) > > > (that said, i'll forward this to people who do know better, and see if > > they (a) care and/or (b) know what the least worst way to do this is.) > > The current code is setting the xattrs before down the chown and chmod so I'm > going to guess none of the selinux rules android is using go "boing" when > things > are done in that order, at least for regular files. Said rules might be > different for directories, but I guess I'll hear about it if stuff breaks. :) fwiw, i wouldn't assume it's actually ever been tested? i'd imagine most [OS] developers are doing `adb sync` instead anyway. any `cp -r` action is most likely just a quick test in /data/local/tmp --- which is so useful _because_ it's the wild west where many of the usual rules don't apply (but only the root or shell users can do anything with it). > (And half my paranoia mitigations don't _apply_ to opening a block device or > fifo, but I'm willing to say doing that at all pilot error. I would like the > common case not to bite civilians easily/often. And issue 112 just says > "directory", they haven't yet complained about selinux rules not being > propagated when doing "cp -a /dev /blah"...) > > Rob _______________________________________________ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net
