Re: [Toybox] cp --preserve=a doesn't preserve security context of directories.
On Sat, Aug 19, 2023 at 10:48 AM Rob Landley wrote:
>
> On 8/18/23 13:54, enh wrote:
> > On Fri, Aug 18, 2023 at 11:45 AM Rob Landley wrote:
> >>
> >> On 8/16/23 15:26, enh wrote:
> >> >> 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.
>
> Wasn't that deprecated? https://lwn.net/Articles/831748/ Hmmm... ok, there are
> multiple mechanisms to disable different amounts of it. And one of them was
> being used too much, so they took it away.
>
> >> ...> 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).
>
> In theory tar extract is also doing some variant of this dance, and they
> should
> probably agree. It's all DIRTREE_COMEAGAIN to set the directory after the
> contents.
>
> The problem is I don't have this domain expertise, it's nontrivial to _build_
> this domain expertise, and non-obvious how to _borrow_ this domain expertise.
> Which is why it's stayed on the todo list for so long, but gotta tackle it at
> some point.
>
> (The correct answer is "do it wrong and wait for people to complain, because
> then they BRING TEST CASES". But it's now heavily used enough that move fast
> and
> break things is... less obviously appropriate?)
>
> >> Speaking of tested, what does a good selinux test _look_ like here? The ls
> >> -Z
> >> stuff is using regexes. I have a Fedora 36 ISO image that says:
> >>
> >> $ ls -Z .
> >> unconfined_u:object_r:user_home_t:s0 Desktop
> >> unconfined_u:object_r:user_home_t:s0 Documents
> >> unconfined_u:object_r:user_home_t:s0 Downloads
> >> unconfined_u:object_r:audio_home_t:s0 Music
> >> unconfined_u:object_r:user_home_t:s0 Pictures
> >> unconfined_u:object_r:user_home_t:s0 Public
> >> unconfined_u:object_r:user_home_t:s0 Templates
> >> unconfined_u:object_r:user_home_t:s0 Videos
> >>
> >> And I don't know what any of that means? (I always delete all the
> >> directories
> >> except "Downloads" immediately on any new install, and only keep that one
> >> because every web browser uses it.)
> >
> > selinux labels are [insert usual disclaimer about my level of
> > knowledge/understanding here] basically just arbitrary strings. i
> > don't think they "mean" anything more than "enh" or the corresponding
> > integer uid "means" anything. they're useful because you can then say
> > things like "this process can read but not write files with this
> > label" or whatever.
>
> The labels don't, the rules do. The labels just say which rules trigger on
> each
> filesystem object. If I set the labels last, it may drop the suid bit on an
> object. If I set the label earlier, they may trigger an selinux rule that
> vetoes
> a later change I try to make to the filesystem object. (In _theory_ your
> selinux
> rules could default forbid and have labels _grant_ access, but that's now how
> the Red Hat guys wrote their ruleset back before I gave up on them.)
>
> I _think_ the right order is to set the label and then chown to apply the suid
> bit last, but my devuan laptop hasn't got this plumbing, and I don't think my
> root filesystem even supports xattrs, so I can't currently test that outside
> of
> mkroot or a KVM instance (and Fedora's livecd is... awkward).
that order certainly matches what we do in adbd for a push/sync of a
file to the device (note also the explicit mention of setuid):
if (fchown(fd.get(), uid, gid) == -1) {
struct stat st;
std::string real_path;
// Only return failure if parent directory does not
have S_ISGID bit set,
// if S_ISGID is set then file will inherit groupid
from directory
if (!Realpath(path, _path) ||
lstat(Dirname(real_path).c_str(), ) == -1 ||
(S_ISDIR(st.st_mode) && (st.st_mode & S_ISGID) == 0)) {
SendSyncFailErrno(s, "fchown failed");
goto fail;
}
}
#if defined(__ANDROID__)
// Not all filesystems support setting SELinux labels.
http://b/23530370.
selinux_android_restorecon(path, 0);
#endif
// fchown clears the setuid bit - restore it if present.
// Ignore the result of calling fchmod. It's not
Re: [Toybox] cp --preserve=a doesn't preserve security context of directories.
On 8/18/23 13:54, enh wrote: > On Fri, Aug 18, 2023 at 11:45 AM Rob Landley wrote: >> >> On 8/16/23 15:26, enh wrote: >> >> 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. Wasn't that deprecated? https://lwn.net/Articles/831748/ Hmmm... ok, there are multiple mechanisms to disable different amounts of it. And one of them was being used too much, so they took it away. >> ...> 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). In theory tar extract is also doing some variant of this dance, and they should probably agree. It's all DIRTREE_COMEAGAIN to set the directory after the contents. The problem is I don't have this domain expertise, it's nontrivial to _build_ this domain expertise, and non-obvious how to _borrow_ this domain expertise. Which is why it's stayed on the todo list for so long, but gotta tackle it at some point. (The correct answer is "do it wrong and wait for people to complain, because then they BRING TEST CASES". But it's now heavily used enough that move fast and break things is... less obviously appropriate?) >> Speaking of tested, what does a good selinux test _look_ like here? The ls -Z >> stuff is using regexes. I have a Fedora 36 ISO image that says: >> >> $ ls -Z . >> unconfined_u:object_r:user_home_t:s0 Desktop >> unconfined_u:object_r:user_home_t:s0 Documents >> unconfined_u:object_r:user_home_t:s0 Downloads >> unconfined_u:object_r:audio_home_t:s0 Music >> unconfined_u:object_r:user_home_t:s0 Pictures >> unconfined_u:object_r:user_home_t:s0 Public >> unconfined_u:object_r:user_home_t:s0 Templates >> unconfined_u:object_r:user_home_t:s0 Videos >> >> And I don't know what any of that means? (I always delete all the directories >> except "Downloads" immediately on any new install, and only keep that one >> because every web browser uses it.) > > selinux labels are [insert usual disclaimer about my level of > knowledge/understanding here] basically just arbitrary strings. i > don't think they "mean" anything more than "enh" or the corresponding > integer uid "means" anything. they're useful because you can then say > things like "this process can read but not write files with this > label" or whatever. The labels don't, the rules do. The labels just say which rules trigger on each filesystem object. If I set the labels last, it may drop the suid bit on an object. If I set the label earlier, they may trigger an selinux rule that vetoes a later change I try to make to the filesystem object. (In _theory_ your selinux rules could default forbid and have labels _grant_ access, but that's now how the Red Hat guys wrote their ruleset back before I gave up on them.) I _think_ the right order is to set the label and then chown to apply the suid bit last, but my devuan laptop hasn't got this plumbing, and I don't think my root filesystem even supports xattrs, so I can't currently test that outside of mkroot or a KVM instance (and Fedora's livecd is... awkward). I don't know how big Android's selinux policy ruleset is (I kinda noped out of selinux conceptually when Fedora passed 50k rules active in the default install) or how many different policies (selectable rulesets) it runs in various contexts, so I have no idea what any of the labels I'd be copying _DO_. What little I know is that it's a programming language complicated enough that people built an IDE for it 15 years ago: https://lwn.net/Articles/221112/ And it has not gotten simpler since: > the policies typically are comprised of thousands of policy statements; this > makes policy development and analysis very difficult. The complexity of > resulting SELinux policies means that for example, safety guarantees cannot be > given, defeating the main purpose for SELinux in the first place https://www.site.uottawa.ca/~afelty/dist/mcetech17.pdf It's a pity Dan Walsh's blog was on livejournal. I'm not voluntarily linking to Russian servers in 2023. But he did a lot of "ruleset reduction" work some years back. One problem with getting old is I'm never quite sure if something that was a big deal 10 years ago ever got fixed (like the btrfs guys just merged the fix for the directory loop stuff). Memorials to old long-fixed problems
Re: [Toybox] cp --preserve=a doesn't preserve security context of directories.
On Fri, Aug 18, 2023 at 11:45 AM Rob Landley wrote: > > On 8/16/23 15:26, enh wrote: > >> 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. > ...> 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). > > Speaking of tested, what does a good selinux test _look_ like here? The ls -Z > stuff is using regexes. I have a Fedora 36 ISO image that says: > > $ ls -Z . > unconfined_u:object_r:user_home_t:s0 Desktop > unconfined_u:object_r:user_home_t:s0 Documents > unconfined_u:object_r:user_home_t:s0 Downloads > unconfined_u:object_r:audio_home_t:s0 Music > unconfined_u:object_r:user_home_t:s0 Pictures > unconfined_u:object_r:user_home_t:s0 Public > unconfined_u:object_r:user_home_t:s0 Templates > unconfined_u:object_r:user_home_t:s0 Videos > > And I don't know what any of that means? (I always delete all the directories > except "Downloads" immediately on any new install, and only keep that one > because every web browser uses it.) selinux labels are [insert usual disclaimer about my level of knowledge/understanding here] basically just arbitrary strings. i don't think they "mean" anything more than "enh" or the corresponding integer uid "means" anything. they're useful because you can then say things like "this process can read but not write files with this label" or whatever. > (I still haven't managed to build a vanilla Android system that boots under > vanilla kvm. Did > https://www.xda-developers.com/microdroid-stripped-down-android-virtual-machines/ > ever turn into a thing?) https://source.android.com/docs/core/virtualization/microdroid "cuttlefish" is probably what you want though? i run the riscv64 cuttlefish, and you can see instructions at https://github.com/google/android-riscv64/#can-i-try-it --- the x86-64 cuttlefish is probably a lot more useful for you (and definitely a lot faster!). > Anyway, I've been poking at the whole tests-under-mkroot thing so I can run > tests as root under a known environment for things like "yes the host system > and > this filesystem are capable of doing selinux but haven't got any weird rules > that make stuff go 'boing' by themselves", but setting up a hand-crafted test > environment doesn't help if I don't know what success looks like. > > I'm hoping I can "setprop" something, cp -a, and then "getprop" to see that it > got propagated successfully? I suppose I can just copy one of the Fedora > labels... i think you mean chcon(1)? but otherwise, "yes". (though i don't have a good trick for "give me two distinct labels" in the same way we grep /etc/passwd or whatever...) > Rob ___ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net
Re: [Toybox] cp --preserve=a doesn't preserve security context of directories.
On 8/16/23 15:26, enh wrote: >> 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. ...> 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). Speaking of tested, what does a good selinux test _look_ like here? The ls -Z stuff is using regexes. I have a Fedora 36 ISO image that says: $ ls -Z . unconfined_u:object_r:user_home_t:s0 Desktop unconfined_u:object_r:user_home_t:s0 Documents unconfined_u:object_r:user_home_t:s0 Downloads unconfined_u:object_r:audio_home_t:s0 Music unconfined_u:object_r:user_home_t:s0 Pictures unconfined_u:object_r:user_home_t:s0 Public unconfined_u:object_r:user_home_t:s0 Templates unconfined_u:object_r:user_home_t:s0 Videos And I don't know what any of that means? (I always delete all the directories except "Downloads" immediately on any new install, and only keep that one because every web browser uses it.) (I still haven't managed to build a vanilla Android system that boots under vanilla kvm. Did https://www.xda-developers.com/microdroid-stripped-down-android-virtual-machines/ ever turn into a thing?) Anyway, I've been poking at the whole tests-under-mkroot thing so I can run tests as root under a known environment for things like "yes the host system and this filesystem are capable of doing selinux but haven't got any weird rules that make stuff go 'boing' by themselves", but setting up a hand-crafted test environment doesn't help if I don't know what success looks like. I'm hoping I can "setprop" something, cp -a, and then "getprop" to see that it got propagated successfully? I suppose I can just copy one of the Fedora labels... Rob ___ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net
Re: [Toybox] cp --preserve=a doesn't preserve security context of directories.
On Wed, Aug 16, 2023 at 1:08 PM Rob Landley wrote: > > On 8/16/23 14:42, enh wrote: > > On Wed, Aug 16, 2023 at 12:33 PM Rob Landley 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
Re: [Toybox] cp --preserve=a doesn't preserve security context of directories.
On 8/16/23 14:42, enh wrote: > On Wed, Aug 16, 2023 at 12:33 PM Rob Landley 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 ___ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net
Re: [Toybox] cp --preserve=a doesn't preserve security context of directories.
On Wed, Aug 16, 2023 at 12:33 PM Rob Landley 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
Re: [Toybox] cp --preserve=a doesn't preserve security context of directories.
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
Re: [Toybox] cp --preserve=a doesn't preserve security context of directories.
strace other cp implementations? (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.) On Tue, Aug 15, 2023 at 10:47 PM Rob Landley wrote: > > So way back in https://github.com/landley/toybox/issues/112 I got a bug > report, > which goes with this comment in cp.c: > > // We only copy xattrs for files because there's no flistxattrat() > > Which is a symptom, not the problem. The fundamental problem is that creating > a > file gives me a filehandle so I can perform operations on the fd and know it > goes to the right inode, but when I mkdir() or mknod() or similar I _can't_ > get > a filehandle as part of create. > > This leaves an unavoidable gap between create and open where somebody could > do a > --bind mount or something and make our later chown/chmod/xattr fiddling apply > to > the wrong inode, which is bad juju. > > There's various paranoia I can do: for directories I can stat() the fd I just > opened and and confirm S_ISDIR and that .. from there is the expected parent > on > the same dev and the uid:gid is us and so on... except that cp -a may be > copying > over symlinks and bind mounts and stuff it's supposed to follow. I think the > rule is "we didn't mkdir() so we don't chown/chmod/xattr"? (I have to check > again, and possibly add tests.) > > Or, alternately, when creating the parent directory I can create it with > permissions 0700 and then chmod it to the correct permissions in > DIRTREE_COMEAGAIN after finishing with the contents... except I think maybe I > have to move the xattr application to _after_ the chmod because I have no idea > what weird selinux rules are going to veto doing a chmod on the node once > they've been applied? And that doesn't help creating the _first_ directory > we're > descending into... > > Is there standard security paranoia for handling this sort of thing so I don't > have to reinvent the wheel here? I really don't xattr much so I dunno how you > _expect_ to deal with it... > > Rob > ___ > Toybox mailing list > Toybox@lists.landley.net > http://lists.landley.net/listinfo.cgi/toybox-landley.net ___ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net
