Hi, On 06/22/2018 02:25 PM, Till Maas wrote: > [...] >> I think you keep putting some kind of base standard on the hypothetical >> attacker and then your argument is "if they can do X then they can do >> Y". Because we're both SW engineers, the relation between X and Y is >> obvious to us, so yeah, anybody who would do X would totally obviously >> also do Y. Sure, we've been there so many times we don't even think >> about it. > > This is a useful way to categorize security vulnerabilities because they > should allow an attacker to gain more privileges/possibilities/... And > if we assume that a system is secure because people do not know about > other possibilities, then it is security by obscurity which does not > work in practice. It's not about whether the bad guys know it, but whether they find it economically plausible to make the effort and actually implement the necessary logic. $Subj makes this logic trivial, hence making the cost lower, hence making the success more likely. >> OTOH, I don't think that's the best way to think about security. There >> are no standards. The amount of code (dedicated to Linux) could >> totally be just that single line, writing the payload to .local/bin. >> By including the path in default $PATH, you are allowing also the >> on-bit-dumber attack to succeed (... now with all Fedora users, yay!...) > > Is this realistic? There a endless other possibilities and there is no > reason why an attack to access exactly these directory paths is more > likely than the many other possibilities. Because it's trivial and with $Subj, this will be almost guarranteed to succeed, without almost no awareness of contents of some files and their syntax. > Also why would attackers > choose this path in the first place? Putting a new ~/.i18n file in the > user's home directory seems to me to be more likely to succeed. I don't think so, because ~/.i18n might already exist, so by writing to it the attacker could break something. I'd say it has same chance of success at best. >> I'm saying there is some impact. I'm not aware of any meaningful way to >> measure it, but I don't think it's necessary: IMHO even making a "minor" >> impact is already bad idea. > > I do not agree because the way you argue could be applied to anything > and there could always be the one imaginary exploit that will have a > payload that will only work because of $whatever and therefore make in > impact. For example from the other changes, what if there is a payload > that uses a feature of Golang 1.11 or a bug that is fixed in Binutils > 2.31. Yes, that's why the conversation should not be about "can they do it" but in what direction and *how far* the pointer is moved by the $Subj on security scale. IMO the change is towards less secure, and I haven't seen any reasonable analysis that would allow an informed guess on *how far*. (Merely eyeballing it does not count.) So why not err on the safe side? >> Especially if I don't really see any convincing reason why this should >> be done. > > I do not see any reason why a user would put something in ~/bin that > would mask something in /usr/bin except to actually mask the binary. It > is the same with other user configuration, anyone expects ~/.ssh/config > to override /etc/ssh/ssh_config instead of the other way round. Yes, and they should also define the scope of (=limit!) that masking by using mechanics of envvars. It is my understanding that the basic (if not only) motivation for $subj is that some people fail at the envvars part. IMO that's not convincing, especially if it's about "developers" who want to push their fresh new code without bothering with package review, etc.---they should know better IMO. aL. -- Alois Mahdal <amahdal@xxxxxxxxxx> Platform QE Engineer at Red Hat, Inc. #brno, #daemons, #preupgrade _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/message/USZX4Z5WC635SKQ7VFWA75SSBDJSVS52/
