[Toybox] cp --preserve=a doesn't preserve security context of directories.

[enh]

On Wed, Aug 16, 2023 at 1:08 PM Rob Landley <rob at landley.net> wrote:
>
> On 8/16/23 14:42, enh wrote:
> > On Wed, Aug 16, 2023 at 12:33 PM Rob Landley <rob at 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