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

[Rob Landley]

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.

(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. :)

(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