|
|
Subscribe / Log in / New account

KernelCI now testing Linux Rust code (Collabora blog)

KernelCI now testing Linux Rust code (Collabora blog)

Posted Dec 8, 2022 11:50 UTC (Thu) by khim (subscriber, #9252)
In reply to: KernelCI now testing Linux Rust code (Collabora blog) by Karellen
Parent article: KernelCI now testing Linux Rust code (Collabora blog)

> Make sure the download is self-contained (you could use a shar archive for this, if you wanted built-in unpackability/runnability), publish the hash of the download alongside the instructions, and have the instructions tell the user to download the file, check the hash, and only then extract/run the archive.

Rustup is a system which downloads and install rust compiler automatically when new versions are released.

Making download self-contained is pretty much pointless if the regular work of application includes the ability to download and run code from the internet.

Thus all that dance would just create false sense of security without achieving anything.

If you really want to review each and every binary before running it each and every time then rustup is just not something you would use. Ever.

> Sure, users could skip the verification step if they don't care about the security of their system, but don't propagate the notion that verification is something they shouldn't even normally think about, when they're downloading random software off of the internet. I mean, do you want botnets? Because that's how you get botnets.

Can you show me one example of successful attack which happened that way? Not even necessarily Rust, but any software where venue of attack was hijacking of an official site and then subsequent delivery of malware?

Botnets happen when people fail to recognize that they are interacting with fake site and do what's written on fake site.

That's completely separate vector of attack from “malicious official server does something weird” and this problem couldn't be solved by teaching people to do useless dance which they would perform with malicious content equally well.


to post comments

KernelCI now testing Linux Rust code (Collabora blog)

Posted Dec 8, 2022 14:32 UTC (Thu) by james (subscriber, #1325) [Link] (6 responses)

Can you show me one example of successful attack which happened that way? Not even necessarily Rust, but any software where venue of attack was hijacking of an official site and then subsequent delivery of malware?
EncroChat:
In short summary, the EncroChat servers were in France and the French Gendarmerie had discovered a way to send an implant to all EncroChat devices in the world under cover of an apparent update. That implant caused the device to transmit to the French police all the data held on it [...]

i) The French had all the necessary legal instruments in place to undertake the extraction of the material from the devices all over the world lawfully as a matter of French law.

ii) The implant was loaded by the French authorities on to the EncroChat servers in Roubaix and then via the servers uploaded onto all the EncroChat devices worldwide.

-- The Rt Hon the Lord Burnett of Maldon, Lord Chief Justice of England and Wales, sitting in the Court of Appeal (Criminal Division).

KernelCI now testing Linux Rust code (Collabora blog)

Posted Dec 8, 2022 15:22 UTC (Thu) by khim (subscriber, #9252) [Link] (5 responses)

And how would have your procedure helped?

AFAICS it was case where binary have come from “trusted” source, only contained unwanted content.

Pointless dance which you propose to do for no good reason is not enough to prevent something like that from happening.

They could have easily published all the checksums and PGP signatures if needed.

And version with backdoor would have had them, too.

Again: the whole point of rustup is to keep your rust compiler up-to-date.

If you don't need or want such service — then you wouldn't use rustup in the first place.

If you do need or want such service — then you have to trust rustup providers and it's stupid the add more protection to the installation script than to the payload which said script installs.

KernelCI now testing Linux Rust code (Collabora blog)

Posted Dec 11, 2022 13:02 UTC (Sun) by ballombe (subscriber, #9523) [Link] (4 responses)

A good source is one where it is difficult to tamper with without it being noticable.
Linux distributions provide that. A private update service does not and neither the curl | sh dance.

KernelCI now testing Linux Rust code (Collabora blog)

Posted Dec 11, 2022 13:21 UTC (Sun) by khim (subscriber, #9252) [Link] (3 responses)

Security if always about trade-offs. “Everything should come from the distors!” fanboys tend to forget about that.

> A good source is one where it is difficult to tamper with without it being noticable.

Time required to push update matters, too. What good is you “good source” if you can not obtain what you want/need from it?

> Linux distributions provide that.

Yes. At the cost of making it unable to use anything up-to-date. Bad for end-users (coz games and most productivity software), bad for developers (coz up-to-date versions of everything are never there).

It's not even clear whether that's a win for security (certainly no one in Rust land would be bothered to think about updating packages as old as you get from Debian), but it's definitely not a good fit for development in any modern language.

> A private update service does not and neither the curl | sh dance.

That's fine. They offer another point on the security/velocity curve.

You may like systems where bug fix needs months if not years to be delivered, other people prefer response time measured in minutes.

As long as you don't try to impose you rules on other people you may do whatever you want.

You can not give others what they need/want, but thanks to the stability offered by Linux kernel and/or GLibC you don't need to - and I'm yet to see any offer which is compatible with normal development-at-trunk approach which would be safer than what rustup offers.

KernelCI now testing Linux Rust code (Collabora blog)

Posted Dec 11, 2022 13:53 UTC (Sun) by pizza (subscriber, #46) [Link] (2 responses)

> Time required to push update matters, too. What good is you “good source” if you can not obtain what you want/need from it?

Over the course of my career, I've noticed the folks who complain the loudest about regressions are also the same ones complaining about updates taking too long.

Ask them to prioritize "speed" or "stability", and it will always be the opposite of what they currently have. If "cost" is also included in the mix, they'll _always_ complain that it's not zero.

KernelCI now testing Linux Rust code (Collabora blog)

Posted Dec 11, 2022 14:50 UTC (Sun) by khim (subscriber, #9252) [Link] (1 responses)

> Over the course of my career, I've noticed the folks who complain the loudest about regressions are also the same ones complaining about updates taking too long.

IOW: some people loudly complain, some people silently suffer.

And I'm proud to admit that I complain about both. Why? Because the way to reduce problems with regressions is to make updates less painful!

It's not a big deal for me if rustc or any other fast-moving component intermittently regresses: I just report the issue, roll it back for a few days and after few days (if regression is fault on the rustc side) everything is fixed.

Even if it's my fault (for using some unstable feature or something) I don't spend too much time on these regressions — because they are limited.

On the other hand every time I need to upgrade gcc or debian or any other project which releases updates once a year or, even worse, once per 2-3 years… it's a pain: regressions are numerous, I hit them all at once and even if each one, individually is “not a big deal”… cumulatively they are a problem.

> Ask them to prioritize "speed" or "stability", and it will always be the opposite of what they currently have.

It's because of false dichotomy. Once upon time MS IE was both a pinnacle of web browsing and epitome of stability. There was very stable steam of articles (and even books!) which described its various bugs and deficiences.

Today that literature genre have mostly dried up: if something is crazy bad then you report it and it's easier fixed or, at least, acknowledged.

I don't perceive it as a problem, although some people miss time where they both needed to collect pile of hacks needed for MS IE 6 and could afford to collect such pile because MS IE 6 was destined to stay with us for decade or more.

> If "cost" is also included in the mix, they'll _always_ complain that it's not zero.

Again: they are no saying anything others are not thinking, do they?

KernelCI now testing Linux Rust code (Collabora blog)

Posted Dec 11, 2022 17:31 UTC (Sun) by pizza (subscriber, #46) [Link]

> Once upon time MS IE was both a pinnacle of web browsing and epitome of stability.

Those were never simultaneously true. I'm not sure if the former was _ever_ true in anyone's eyes but Microsoft's.

> Again: they are no saying anything others are not thinking, do they?

They're not willing to acknowledge, much less pay for, the price of what they want.

KernelCI now testing Linux Rust code (Collabora blog)

Posted Dec 9, 2022 23:24 UTC (Fri) by Karellen (subscriber, #67644) [Link] (5 responses)

Rustup is a system which downloads and install rust compiler automatically when new versions are released.

Does rustup also automatically check hashes and signatures, like e.g. apt does? If so, cool. If not, wtf.

Yeah, I don't check every version of apt by hand, or the packages it installs, because I know it does that for me. But I do check the hashes on the installer .iso images I download, which is the start of the chain. Because it's not actually hard to do, and it cuts off a possible line of attack.

(Also, maybe the reason that malicious downloads are rare for popular software is because hashes are regularly published for most of them? Even if the instructions don't tell you to check, and most people don't, plenty might, and anyone could catch a substitution and suddenly get trending on $SOCIAL_MEDIA over it.)

KernelCI now testing Linux Rust code (Collabora blog)

Posted Dec 9, 2022 23:46 UTC (Fri) by khim (subscriber, #9252) [Link] (4 responses)

> Also, maybe the reason that malicious downloads are rare for popular software is because hashes are regularly published for most of them?

If they are regularly published but never verified then it wouldn't help, would it? Rustup verifies checksum when it upgrades itself (and when it upgrades Rust), but not during initial install.

> But I do check the hashes on the installer .iso images I download, which is the start of the chain. Because it's not actually hard to do, and it cuts off a possible line of attack.

If you are paranoid enough then sure, sha256 sums and all binaries are not hidden.

But as our discussion here have shown much bigger issue is not that someone would change official installers (and if people who are supposed to change them would put malicious content inside you wouldn't know that case from when new good version is uploaded), but that user would visit entirely different web site.

That problem doesn't have a good solution, I'm afraid: for projects as big as rust or gcc usually it's not hard to find the official site, but for smaller projects it's a problem.

Doing crazy security dance and comparing sha256sums and doing other such things wouldn't help you if you are on the wrong web site.

KernelCI now testing Linux Rust code (Collabora blog)

Posted Dec 12, 2022 12:05 UTC (Mon) by Karellen (subscriber, #67644) [Link] (3 responses)

If they are regularly published but never verified then it wouldn't help, would it?

If they are never verified? No, it wouldn't. But (as I mentioned) it probably only needs one person to check them, notice an inconsistency, and post to Twitter/HN/Reddit/FB/.... to make people aware of the situation and get it looked into properly.

Doing crazy security dance and comparing sha256sums and doing other such things wouldn't help you if you are on the wrong web site.

No, but isn't that an example of the perfect being an enemy of the good? Saying that if $PROCEDURE cannot solve all possible problems, we should not bother adopting it to fix the problems it can solve? Isn't that like saying that because Rust cannot prevent all possible bugs in a program, we should not bother adopting it to remove entire classes of memory safety bugs that it can prevent? Or, because wearing a seat belt won't guarantee you'll survive a car crash, you shouldn't bother wearing one at all?

Just because we can never make users perfectly safe (unless we give them a complete walled-garden app store, a la Apple/Google Play), I don't see why we shouldn't guide them into habits of taking reasonable precautions that can make them safer. curl | sh just seems like giving up on that.

KernelCI now testing Linux Rust code (Collabora blog)

Posted Dec 12, 2022 12:46 UTC (Mon) by khim (subscriber, #9252) [Link] (2 responses)

> No, but isn't that an example of the perfect being an enemy of the good?

Your solution? Yes, it's absolutely like that.

> Saying that if $PROCEDURE cannot solve all possible problems, we should not bother adopting it to fix the problems it can solve?

No. But if $PROCEDURE makes things which are already problematic more acute while making things which are already not-that-bad better then it's wrong $PROCEDURE.

People don't care all that much for security, they want convenience. If you wouldn't provide simple curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh command then people would go looking for third party packaging which would make installation easy.

I have seen plenty of such ready-made packages with MySQL+PHP+Apache or containers with Postres+Node.JS+Whatever.

These are much more immediate threat that hypothetical case where someone hijacks https://rustup.rs/ site, replaces certificate and places malicious compiler there.

> Isn't that like saying that because Rust cannot prevent all possible bugs in a program, we should not bother adopting it to remove entire classes of memory safety bugs that it can prevent?

No, it's like saying that if you want to avoid problems with shared mutability then there are no need to ban all mutability (like FP lamguages are doing).

> curl | sh just seems like giving up on that.

Give up on what? On the pipe dream of making people using inconvenient and hard-to-follow dance? Maybe. But is it a bad thing?

I have seen that many times: people would ignore security if it's painful enough. In some really super-duper-secure places (like banks) security organisation has so much power and invent such a crazy rules that people don't perceive these guys as a friends. They become an adversaries who are sitting between you and your $JOB and thus your $SALARY.

At this point this:

> I don't see why we shouldn't guide them into habits of taking reasonable precautions that can make them safer.

Becomes a pipe dream. I've seen password attached to monitors and clickers which touch USB token on demand, I've seen cracked versions of programs installed by official distributors because it saves them money (cracked version of program just works while official would need constant hassle of updating keys, dealing with hardware tokens) and so on.

It always amazes me how “securuity guys” couldn't understand that.

First you make secure solution easy to use, then you push it.

Right now the best compromise is TLS with certificate verification and domain pinning.

KernelCI now testing Linux Rust code (Collabora blog)

Posted Dec 12, 2022 18:42 UTC (Mon) by Karellen (subscriber, #67644) [Link] (1 responses)

Your solution? Yes, it's absolutely like that.

What are you, like 10 years old? FFS.

KernelCI now testing Linux Rust code (Collabora blog)

Posted Dec 13, 2022 10:44 UTC (Tue) by farnz (subscriber, #17727) [Link]

khim's writing style makes it very clear that they are not a native English speaker, and therefore you need to take their text as written, rather than assuming that they're using English idiom correctly.

I note that you've pulled out 7 words from their comment, where the remaining 300-odd words of their comment are a substantive explanation of why they believe that your proposal will not work. Could you perhaps address the substance, and not nit-pick their linguistic oddities?

And yes, it can be frustrating talking to a non-native speaker whose English isn't yet idiomatic - I've had a comment chain with khim recently where i had to rephrase things 2 or 3 times before they understood what I was saying. But that's the challenge of a global network - nuance doesn't carry over well in text, nor does it translate nicely when someone's clearly still partially thinking things through in one language and then writing English as a second task, rather than thinking it through in English.


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds