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