A bug is a bug, but a patch is a policy: The case for bootable containers

Joker_vD 2 hours ago | parent | next [-]

> Greg’s argument is a hard truth: “Usage is different for each user.” He cannot score a vulnerability because he doesn’t know if you’re running a cloud-native microservice or a legacy industrial controller.

What about having several use cases in mind, and give the scores for each of those?

> We must stop litigating which fixes matter and start treating every kernel bug fix as relevant (a bug is a bug). We must stop running patching as a project and bake it into the pipeline so that applying stable fixes is simply what the system does (the patch is the policy).

Ah, so it's simply "apply all the fixes automatically", i.e. "the Chainguard way" but, again, fully automated. Okay?

	▲	twelvedogs 31 minutes ago \| parent \| next [-]
		> What about having several use cases in mind, and give the scores for each of those? i imagine the same reason they don't score for 1, it takes time that could be allocated elsewhere tbh i think scoring for multiple scenarios would take more time and be less useful. kernel devs are not implementors, they may have never used docker or built a cut down kernel for an iot device, they just build a general purpose kernel
	▲	kleiba 2 hours ago \| parent \| prev [-]
		> What about having several use cases in mind, and give the scores for each of those? Or assign one score according to the worst case scenario.

▲

faust201 2 hours ago | parent | prev | next [-]

I tried a lot to get this in reality - using fedora silverblue. But that thing sucks. It is slow. Really dogslow. Devs are blaming rpm-ostree or btrfs - no idea. I wish there was something like ChromeOS but open.

Hint: Maybe firefox should pivot (re-do Firefox OS) to that.

	▲	Conan_Kudo 18 minutes ago \| parent [-]
		It's pretty much rpm-ostree. Nobody bothered to make those workflows performant, so if you need to apply updates separately, it's going to suck. The OSTree download can be fast if you have a fast connection to the Fedora server, but it's not mirrored and there's no mirror network support (so no geographically close downloads). To be fair, bootc has this problem too because container tooling in general can't support mirror networks currently.

▲

MattPalmer1086 2 hours ago | parent | prev | next [-]

As part of a security team tasked with triaging endless CVSS scores that all make the assumption you are directly piping unauthenticated malicious data to the code in question, using whatever the worst way of doing it is, I approve of not giving misleading "worst case" CVSS scores. They are almost never worst case, are frequently trivial, and suck up a huge amount of resource.

Glad to hear developers are also pushing back against the madness. I do think just patching known bugs quickly is the best way to go. Alternative might be some kind of AI assisted triage process.

EDIT: CVSS evaluates vulnerabilities in the context of the entire system. It makes no sense to apply it to software components; you just don't know what the solution actually looks like from down there. So it's just an inappropriate method to use in the first place.

▲

littlestymaar an hour ago | parent | prev [-]

I really don't understand the argument being made, here, it genuinely feels nonsensical to me:

- it talks about Kernel CVEs while talking about a user-space tool (containers).

- with respect to a kernel bug, what's the difference between updating/downgrading a kernel container image (whatever that means) and just doing the same for the kernel installed on the machine? Unlike a whole distro' which is made out of many moving parts with complex (and brittle) interactions, where updating can break things in ways that cannot trivially be rolled back (which makes stateless containers a good idea for user space), the kernel is pretty much a monolith and you can trivially switch between versions (even on a consumer Linux desktop you can use the previous kernel simply by selecting it in the grub list…).