Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Copy Fail, Dirty Frag, and Fragnesia kernel vulnerabilities

gentoo.org

Post reply on HN
Print view View original

31–40 of 55 posts

Re: Copy Fail, Dirty Frag, and Fragnesia kernel vulnerabilities

#31

Post by gilrain »

belorn wrote: post #21
yjftsjthsd-h wrote: post #9

> We recommend exploring ways to automate upgrading your kernel Like, running emerge -u @world on a regular basis, or ... /me searches Okay, so https://wiki.gentoo.org/wiki/Live_patching exists but says, > A note of caution: Kernel live patching is risky. Count on hard freezing or panics to become normal... That's not encouraging. --- Another approach: Can we make the kernel vulns less important? Has anyone had luck…

If we are looking at things like gvisor or firecracker, SELinux might be an alternative. From what I can see, SELinux prevented both copy fail and dirty frag, and maybe also fragnesia but I couldn't find any definitive answer on that one. Last time I tried it was a pain to setup and a pain to use, but as a sysadmin there is a lot of thing that share those attributes. The only question if its worth it. If the current…

SELinux is a bear when you’re reacting to it, but ever since I took a day to proactively read about it, it’s become much easier to reason about. It’s not actually all that complex.

I still need to troubleshoot from time to time, but I never reach for permanent setenforce 0 anymore.

Re: Copy Fail, Dirty Frag, and Fragnesia kernel vulnerabilities

#32

Post by ordu »

ahartmetz wrote: post #17
ordu wrote: post #13

Earlier quoted context omitted.

Linux distros are not npm. It doesn't mean they are infallible to malicious actors, but I believe it is possible to make them infallible for some small set of packages at least. Attacks are still possible, but if we look at xz backdoor attack[1] it was insanely complicated attack and it still failed. Its fail doesn't look promising, attack could succeed just the attacker was unlucky. Still it shows that the success i…

Whenever you read about an incredibly unlucky criminal, there's a chance that the unlucky event is a parallel construction to the classified real reason why they were caught. Not sure how exactly that would have worked in this case.

Yes, it could be. But it is a hypothetical that smells like a conspiracy theory. I wonder why you think it is a good idea to go for these hypotheticals?

Are you arguing that the system may be more resilient than it seems? Like, maybe there is a conspiracy working on security. And they keep themselves secret so attackers would be susceptible to under-appreciate the real level of security and make mistakes that inevitable would caught?

It seems like a over-stretched explanation, doesn't it. Care to explain yourself?

Re: Copy Fail, Dirty Frag, and Fragnesia kernel vulnerabilities

#33

Post by kafrofrite »

himata4113 wrote: post #4

Expanding on gentoo's recommendations: I wonder if we should just universally accept that live patching should become part of the linux kernel? An automatic job that updates (much like some system packages in some distros) that installs (signed) live patches from upstream? Of course we would run into a problem where a malicious patch can now be distributed reliably to hundreds of thousands of machines, but we already…

I guess there's merit for that, especially if you are in a cloud environment. In a previous company, I decided to set up dnf/kpatch for VMs that we considered critical. At the time I had a healthy disregard for reliability, mostly because we had enough trust in our terraform process so I decided to automate the whole thing through AWS System Manager across the fleet and guard the feature to work only for security patches targeting the kernel. Briefly, every VM that came up would have the necessary packages installed and from there live patching would execute periodically (I believe once a week) or manually. At some point after a quarter or something we had to devise a way to tag VMs to be excluded from this but this was relatively easy to do and most of the exclusions were testing infra anyway.

Re: Copy Fail, Dirty Frag, and Fragnesia kernel vulnerabilities

#34

Post by ahartmetz »

ordu wrote: post #32
ahartmetz wrote: post #17

Earlier quoted context omitted.

Whenever you read about an incredibly unlucky criminal, there's a chance that the unlucky event is a parallel construction to the classified real reason why they were caught. Not sure how exactly that would have worked in this case.

Yes, it could be. But it is a hypothetical that smells like a conspiracy theory. I wonder why you think it is a good idea to go for these hypotheticals? Are you arguing that the system may be more resilient than it seems? Like, maybe there is a conspiracy working on security. And they keep themselves secret so attackers would be susceptible to under-appreciate the real level of security and make mistakes that inevita…

I mentioned it mainly because I find it interesting. We are probably just slightly less lucky than it seems. This particular case doesn't look that much like a parallel construction to me.

Re: Copy Fail, Dirty Frag, and Fragnesia kernel vulnerabilities

#35

Post by ordu »

c7b wrote: post #26
ordu wrote: post #13

Earlier quoted context omitted.

Linux distros are not npm. It doesn't mean they are infallible to malicious actors, but I believe it is possible to make them infallible for some small set of packages at least. Attacks are still possible, but if we look at xz backdoor attack[1] it was insanely complicated attack and it still failed. Its fail doesn't look promising, attack could succeed just the attacker was unlucky. Still it shows that the success i…

Linux itself, major Linux distros, npm - none of these were designed with a security-first approach. Even the things that do help with security, like package maintenance or containerization, were more incidental to other primary goals like stability, reproducibility and so on rather than being born from a comprehensive security-first strategy. They could have been, but then things would have moved slower. They even e…

I technically agree, but it seems too abstract to me. How could look a distro maintenance, if it was built with a security-first approach?

Maybe I have not enough fantasy and/or creativity, but trying to imagine it, I see just a bit more of oversight built into protocols of approving changes to repositories. I mean, it doesn't seem that improved security needs an approach "destroy everything and build it from scratch", some additions on top of existing structures would do. Am I wrong?

Re: Copy Fail, Dirty Frag, and Fragnesia kernel vulnerabilities

#36

Post by kwhat4 »

ordu wrote: post #15
clircle wrote: post #2

Is Gentoo an outlier or do all Linux distributions deal with this problem?

All of them need to do it. There maybe differences, like different number of versions of kernel supported, so less of backporting, but still distros have to provide fixed kernels. With Gentoo I believe it is more fun, because of all the options gentoo provides out of a box. More kernels, more work to do. ls /var/db/repos/gentoo/sys-kernel/ asahi-sources/ git-sources/ linux-next/ scx-loader/ bliss-initramfs/ gnumach/…

This is a bit misleading. All of genkernel/, gentoo-kernel/, gentoo-kernel-bin/, gentoo-sources/, git-sources/, vanilla-kernel/ and vanilla-sources/ are all different packages for the same Linux Kernel. There are multiple slots per package for the various supported LTS versions of said kernel but they will all get +/- the same set of patches for these issues. There is some support for other kernels like Darwin, BSD and HURD but your millage will vary.

https://wiki.gentoo.org/wiki/Kernel/Packages/en

Re: Copy Fail, Dirty Frag, and Fragnesia kernel vulnerabilities

#37

Post by yjftsjthsd-h »

kwhat4 wrote: post #36
ordu wrote: post #15

Earlier quoted context omitted.

All of them need to do it. There maybe differences, like different number of versions of kernel supported, so less of backporting, but still distros have to provide fixed kernels. With Gentoo I believe it is more fun, because of all the options gentoo provides out of a box. More kernels, more work to do. ls /var/db/repos/gentoo/sys-kernel/ asahi-sources/ git-sources/ linux-next/ scx-loader/ bliss-initramfs/ gnumach/…

This is a bit misleading. All of genkernel/, gentoo-kernel/, gentoo-kernel-bin/, gentoo-sources/, git-sources/, vanilla-kernel/ and vanilla-sources/ are all different packages for the same Linux Kernel. There are multiple slots per package for the various supported LTS versions of said kernel but they will all get +/- the same set of patches for these issues. There is some support for other kernels like Darwin, BSD a…

> There is some support for other kernels like Darwin, BSD and HURD but your millage will vary.

I believe at this writing only Linux and HURD are officially supported standalone. Which IMHO is sad because Gentoo kFreeBSD was really cool but oh well. There is still the Gentoo prefix project, though even there support for the BSDs is iffy:(

Re: Copy Fail, Dirty Frag, and Fragnesia kernel vulnerabilities

#38

Post by bombcar »

patmorgan23 wrote: post #20
Muromec wrote: post #19

Earlier quoted context omitted.

>but then package those modules into separate packages. If you don't need somedriver.ko, then you don't `apt install linux-driver-somedriver But I don't want to know what drivers I need and will need next. Tomorrow I could buy a different wifi module and then what? Spend 3 hours googling which rtl378326973268632aahaxhabt.ko to install? Thanks but no thanks.

So why can't someone (probably the distro) build a utility that detects the hardware and installs the required kernal module? We can have security and convenience.

That existed for a very short period of time before it became simpler to just ship everything all the time. I remember at least one distro booting with a single processor kernel and detecting that it could use an SMP kernel and did I want to pull it down?

Re: Copy Fail, Dirty Frag, and Fragnesia kernel vulnerabilities

#39

Post by johnny22 »

patmorgan23 wrote: post #20
Muromec wrote: post #19

Earlier quoted context omitted.

>but then package those modules into separate packages. If you don't need somedriver.ko, then you don't `apt install linux-driver-somedriver But I don't want to know what drivers I need and will need next. Tomorrow I could buy a different wifi module and then what? Spend 3 hours googling which rtl378326973268632aahaxhabt.ko to install? Thanks but no thanks.

So why can't someone (probably the distro) build a utility that detects the hardware and installs the required kernal module? We can have security and convenience.

and how would it get that module without network access. I'd say for network drivers specifically, this is tough one.

It would work for various other drivers though.

Re: Copy Fail, Dirty Frag, and Fragnesia kernel vulnerabilities

#40

Post by bombcar »

johnny22 wrote: post #39
patmorgan23 wrote: post #20

Earlier quoted context omitted.

So why can't someone (probably the distro) build a utility that detects the hardware and installs the required kernal module? We can have security and convenience.

and how would it get that module without network access. I'd say for network drivers specifically, this is tough one. It would work for various other drivers though.

The standard method is for the installer to have the needful and then it knows what packages to install to give you the network drivers you need going forward (shades of slipstreaming in all the network drivers I could find into W2K custom ISOs so I'd not need to find floppies).
Post reply on HN