site banner
PaperclipPerfector  7mo ago (text post)   25759 thread views

Culture War Roundup for the week of April 1, 2024

This weekly roundup thread is intended for all culture war posts. 'Culture war' is vaguely defined, but it basically means controversial issues that fall along set tribal lines. Arguments over culture war issues generate a lot of heat and little light, and few deeply entrenched people ever change their minds. This thread is for voicing opinions and analyzing the state of the discussion while trying to optimize for light over heat.

Optimistically, we think that engaging with people you disagree with is worth your time, and so is being nice! Pessimistically, there are many dynamics that can lead discussions on Culture War topics to become unproductive. There's a human tendency to divide along tribal lines, praising your ingroup and vilifying your outgroup - and if you think you find it easy to criticize your ingroup, then it may be that your outgroup is not who you think it is. Extremists with opposing positions can feed off each other, highlighting each other's worst points to justify their own angry rhetoric, which becomes in turn a new example of bad behavior for the other side to highlight.

We would like to avoid these negative dynamics. Accordingly, we ask that you do not use this thread for waging the Culture War. Examples of waging the Culture War:

  • Shaming.

  • Attempting to 'build consensus' or enforce ideological conformity.

  • Making sweeping generalizations to vilify a group you dislike.

  • Recruiting for a cause.

  • Posting links that could be summarized as 'Boo outgroup!' Basically, if your content is 'Can you believe what Those People did this week?' then you should either refrain from posting, or do some very patient work to contextualize and/or steel-man the relevant viewpoint.

In general, you should argue to understand, not to win. This thread is not territory to be claimed by one group or another; indeed, the aim is to have many different viewpoints represented here. Thus, we also ask that you follow some guidelines:

  • Speak plainly. Avoid sarcasm and mockery. When disagreeing with someone, state your objections explicitly.

  • Be as precise and charitable as you can. Don't paraphrase unflatteringly.

  • Don't imply that someone said something they did not say, even if you think it follows from what they said.

  • Write like everyone is reading and you want them to be included in the discussion.

On an ad hoc basis, the mods will try to compile a list of the best posts/comments from the previous week, posted in Quality Contribution threads and archived at /r/TheThread. You may nominate a comment for this list by clicking on 'report' at the bottom of the post and typing 'Actually a quality contribution' as the report reason.

11
Top Bottom Old Controversial Comments
Jump in the discussion.

No email address required.

My takeaways:

  • Security is hard.
  • Binary blobs are bad. Ideally, there should not be binary blobs in the working directory during compilation of distribution packages. Test cases should be run with no write permission towards stuff which goes into the distribution package. Binary blobs which should be shipped in the package (e.g. images, sounds) should be added by the build process using a distribution-wide mechanism after the package specific stuff (makefile etc) has finished executing. Paranoid distributors might want to add low levels of noise to images and sound files to disincentive hiding executable code in them.
  • Attack surface should be minimized for daemons which listen on network ports. This means loading only the libraries which are absolutely required. A compromised xz library should result in being exploitable whenever you unpack xz, not whenever you run sshd.
  • The anonymity of github makes supply chain attacks by nation state actors less costly. Sure, you can get an agent into Google, but this is certainly much more difficult than just having your attack team maintain a plausible volunteer git account.
  • Of course, if you can coerce your citizens who are already established open source volunteers, this is a cheap way to get around any requirements for meatspace identities. I think that in the Western world, coercion should not work too well, if the NSA puts CSAM on the computer of a senior linux dev and then tries to blackmail them with it, the chances of this backfiring are too high to make it sustainable. (Of course, if they have real dirt on some dev (say Reiser-level), then the NSA could well coerce them to apply some evil commits in exchange for their legal troubles going away. Still, the median developer probably does not have literal skeletons in the closet.) By contrast, the median developer in the PRC might be more vulnerable to coercion by the state.
  • An automated way to compare the memory dumps of processes with the source code which purportedly defined them seems generally helpful. Preferably, these should not be open source, but be run by various big institutions (Google, Microsoft, NSA) internally, so attackers will have a harder time learning how to bypass them.
  • Having persistent pseudonymous identities with some PKI authentification over multiple platforms would be desirable because it raises costs to attack. An anonymous comment on debian costs the attacker nothing, while burning an identity which has enough open source backstory to take some time to create will hurt.

Some more comments on the OP:

But a compression library seems just after cryptographic libraries are a reasonable thing to not roll your own, and even if this particular use for this particular library might have been avoidable, you're probably not going to be able to trim that much out, and you might not even be able to trim this.

I think there is a big difference. Rolling out your own crypto is a big no-no because they are hard to get right, and any mistakes likely leave you vulnerable.

Rolling out your own compression is much less evil: there is certainly some potential for arbitrary code execution vulnerabilities, but not more than with handling any other file parsing. With regard to generally reinventing the wheel versus loading wheels from a zillion different libraries, each of them with their own dependency chains, there is probably some reasonable middle ground. For something like sshd which sits on a security boundary, the obvious way in retrospect to add systemd logging would be to implement the interface from the scratch instead of including a bloated libsystemd.

and may not even recognize xz as a file extension

Data point: As some casual linux user, I recognize the xz file extension. Before last week, the main thing I could have told you about it was that it was a compression commonly used for tar files, the third one I am aware of after gz and bz2. GNU tar wants -J when handling xz. I would have guessed that the fact that it de-facto replaced bz2 is likely due to the fact that it is better on at least some metrics, but have no clue how the xz algorithm works in particular.

On the plus side, the fact that the attackers stayed in userspace instead of having /usr/bin/sshd load some kernel model seems to indicate that a stealthy compromise of the kernel is hard? Yay for NSA's SELinux?

Security is hard.

I like to think that this will get better as time goes on. If you think about it, humans have only really been writing software at an industrial scale for two, maybe three decades now. We're not good at it yet.

Every single one of us is running a kernel that was written in the 90s using paradigms formed in the 80s with a computer language that was invented in the 70s.

So little about how we do computing has even caught up to modern thinking. I don't know if Rust specifically is the future, but something like it is.

I’ve heard it said that Rust is the new C++ but Zig is the new C.

Every single one of us is running a kernel that was written in the 90s using paradigms formed in the 80s with a computer language that was invented in the 70s.

The paradigms are from the 70s. The language and paradigms are inherently related. UNIX is the c environment. After Pascal's demise, our hardware was deformed to fit this structure too, so we're really 50 years behind. It's so sad.

Very much appreciate the additional takeaways.

Rolling out your own compression is much less evil: there is certainly some potential for arbitrary code execution vulnerabilities, but not more than with handling any other file parsing.

Yeah, that's fair. There are some esoteric failure modes -- how do you handle large files, what level of recoverability do you want to handle, how do you avoid being the next zlib -- but for good-enough lossless compression you can get away with some surprisingly naive approaches, without the cryptography-specific failure mode where it can look where it's working fine but be vulnerable in ways you can't even imagine.

Data point: As some casual linux user, I recognize the xz file extension.

Huh, I stand corrected. I've seen it occasionally, but more often for Docker than anything else -- a lot of environments still use .gz almost everywhere.

On the plus side, the fact that the attackers stayed in userspace instead of having /usr/bin/sshd load some kernel model seems to indicate that a stealthy compromise of the kernel is hard? Yay for NSA's SELinux?

There is that on the plus side. I'm not hugely optimistic people would be as easily able to discover those sort of attacks, but then again, there's a lot more eyes on the kernel and a lot more emphasis on finding weird or unexpected behaviors in it.

I for one do not want to scream at them because I consider them to be a sock puppet of some unknown agency. I am kind of gleeful that some agency burned through this identity they put a lot of work into propping up.

Yeah, that's probably the more Correct response.

the obvious way in retrospect to add systemd logging would be to implement the interface from the scratch instead of including a bloated libsystemd

I have to wonder whether we're sure this wasn't the obvious way with foresight, too. The top comment on Hacker News claims the from-scratch option is to simply send a systemd notification by writing to a socket, with a dozen lines of code that don't link to anything beyond libc, no need to apply a non-standard patch to openssh to link it to libsystemd instead. In the context of a years-long many-pseudonym social-persuasion-filled attack it might not be too paranoid to find out who persuaded Debian etc. that linking was the way to go here.

Or if we want to go too-paranoid, systemd itself is an utterly massive pile of privileged C code that took a lot of persuasion to be accepted...

And if we want to go Full Tinfoil Hat, how'd we all end up on this "Linux" macrokernel, anyway? Minix could have been easier to secure...

What is this place?

This website is a place for people who want to move past shady thinking and test their ideas in a court of people who don't all share the same biases. Our goal is to optimize for light, not heat; this is a group effort, and all commentators are asked to do their part.

The weekly Culture War threads host the most controversial topics and are the most visible aspect of The Motte. However, many other topics are appropriate here. We encourage people to post anything related to science, politics, or philosophy; if in doubt, post!

Check out The Vault for an archive of old quality posts. You are encouraged to crosspost these elsewhere.


Why are you called The Motte?

A motte is a stone keep on a raised earthwork common in early medieval fortifications. More pertinently, it's an element in a rhetorical move called a "Motte-and-Bailey", originally identified by philosopher Nicholas Shackel. It describes the tendency in discourse for people to move from a controversial but high value claim to a defensible but less exciting one upon any resistance to the former. He likens this to the medieval fortification, where a desirable land (the bailey) is abandoned when in danger for the more easily defended motte. In Shackel's words, "The Motte represents the defensible but undesired propositions to which one retreats when hard pressed."

On The Motte, always attempt to remain inside your defensible territory, even if you are not being pressed.


New post guidelines

If you're posting something that isn't related to the culture war, we encourage you to post a thread for it. A submission statement is highly appreciated, but isn't necessary for text posts or links to largely-text posts such as blogs or news articles; if we're unsure of the value of your post, we might remove it until you add a submission statement. A submission statement is required for non-text sources (videos, podcasts, images).

Culture war posts go in the culture war thread; all links must either include a submission statement or significant commentary. Bare links without those will be removed.

If in doubt, please post it!


Rules


Recommended Posts And Communities

Recommended Realtime Chats