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." 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. *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 _______________________________________________ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net