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

[enh]

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" :-)

> 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, but i'm pretty sure they'd say "why
do you even have a writable file system? _that's_ your mistake right
there!" :-)

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.

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

> *shrug* Comfort thing, really. Changing the directory permissions during
> traversal is in the easy to stop "I broke it" bucket if that goes wrong, but I
> still need the paranoia checks at the top level so might as well do them for all
> directories, with failure just meaning "don't apply selinux labels".
>
> (Modulo NOT applying selinux labels to a directory _being_ the potential attack
> surface, failing closed is still failing. But in the absence of a syscall that
> can do dirfd = mkdiratopen(fdcwd, name) I'm just "managing suck", it moves the
> potential exploits around. If the object got switched in the gap with a perfect
> replica... I mean I can also check that the timestamp is between when I called
> mkdir and when I called open() but they can set that, and the filesystem could
> round the granularity putting it outside the window...)
>
> (Don't get me started on capability bits. I am not a fan of capability bits.
> "You have authority to set fire to the living room. YOU have authority to set
> fire to the kitchen. YOU have authority to set fire to the bathroom. Now we're
> much safer.")
>
> > (if you've never looked at the source of
> > https://github.com/SELinuxProject/selinux/tree/main/libselinux/src
> > it's probably not the kind of code you're imagining/hoping code whose
> > whole purpose is security should look like.)
>
> I went through a chunk of selinux source when trying to figure out what xattrs
> it actually sets, I think for adding xattr support to tar without pulling in a
> shared library?
>
> To quote Miracle Max, "I've seen worse", but that is very much not an endorsement.
>
> Rob