4 ms·

The linux-stable security tree project

47 points by tshtf 10y ago

geofft 10y ago
Some possible context: the maintainer works for Oracle's Ksplice team, and the stated purpose of the tree fits perfectly with the set of patches you'd expect Ksplice to apply to a stable kernel, but not the ones you wouldn't.
- kragniz 10y ago
  It looks great for this purpose. Hopefully it will make the upstream livepatching subsystem more useful.
chris_wot 10y ago
Is Torvalds going to support this? Given some of his comments on security in the past, I don't think he'll consider it a good idea...
- d33 10y ago
  I'm pretty sure that not and his bug obfuscation scheme is something that worries me a lot. Combine it with their attitude towards grsec and the vision of SELinux/AppArmor/yet-another-overly-complex-security-module and I'd say that Linux is a hell from the kernel security standpoint.
  - cm3 10y ago
    What happened to the LinuxFoundation project to pull in as much from GRsec as possible, which started last year?
    - corbet 10y ago
      See, for example, https://lwn.net/Articles/666550/ https://lwn.net/Articles/666550/ - merged for 4.6. Various other patches are out there in various stages of readiness.
rincebrain 10y ago
I'd guess this is a result of two things: > customer pushback over seeing churn in changelogs for their "stable" systems > RH making it difficult to cherry-pick kernel patches out of their tree by only including their changeset on the vanilla kernel version as a monolithic patch They can't feasibly lie to their customers by eliding the changelogs, they presumably have failed to change attitudes about fixes to other parts of the codebase being rolled in, and so here we are, though having it be public is an interesting choice for Oracle. I wonder if it's also a PR move to get other people to leverage their "security" tree.
d_theorist 10y ago
What I would find more useful is a way to do something like: $ apt-get upgrade --security-only on a normal ubuntu distribution. The key thing for me is to have as little change as possible from the time the machine is initially provisioned.
- kpcyrd 10y ago
  debian supports something like this, if you remove the jessie-updates line and only have the release source (which is never changed) and the security source in /etc/apt/sources.list I'm not sure if this is recommended, I could imagine that some security fixes might be based on updated packages from jessie-updates. You might also run into fixed bugs by ignoring stability fixes, personally I don't think it's worth it.
  - d_theorist 10y ago
    You are probably right. Interesting though; thanks.
- iam-TJ 10y ago
  sudo /usr/bin/unattended-upgrade This will only use the ${dist}-security target. Most systems should have this installed and available. The default configuration is at: /etc/apt/apt.conf.d/50unattended-upgrades It is configured as a system service that runs automatically at shutdown.
  - d_theorist 10y ago
    Ah, nice. Thanks.
vog 10y ago
> This project provides an easy way to receive only important security commits I wonder if this is actually possible, given that a refactoring or code cleanup could also remove lots of security issues (which in part aren't even known today). This point is quite well articulated by the OpenBSD security folks, for example: http://www.tedunangst.com/flak/post/long-term-support-considered-harmful http://www.tedunangst.com/flak/post/long-term-support-consid...

47 points by tshtf 10y ago

Some possible context: the maintainer works for Oracle's Ksplice team, and the stated purpose of the tree fits perfectly with the set of patches you'd expect Ksplice to apply to a stable kernel, but not the ones you wouldn't.

kragniz 10y ago
It looks great for this purpose. Hopefully it will make the upstream livepatching subsystem more useful.

chris_wot 10y ago

Is Torvalds going to support this? Given some of his comments on security in the past, I don't think he'll consider it a good idea...

d33 10y ago
I'm pretty sure that not and his bug obfuscation scheme is something that worries me a lot. Combine it with their attitude towards grsec and the vision of SELinux/AppArmor/yet-another-overly-complex-security-module and I'd say that Linux is a hell from the kernel security standpoint.
- cm3 10y ago
  What happened to the LinuxFoundation project to pull in as much from GRsec as possible, which started last year?
  - corbet 10y ago
    See, for example, https://lwn.net/Articles/666550/ https://lwn.net/Articles/666550/ - merged for 4.6. Various other patches are out there in various stages of readiness.

rincebrain 10y ago

I'd guess this is a result of two things: > customer pushback over seeing churn in changelogs for their "stable" systems > RH making it difficult to cherry-pick kernel patches out of their tree by only including their changeset on the vanilla kernel version as a monolithic patch They can't feasibly lie to their customers by eliding the changelogs, they presumably have failed to change attitudes about fixes to other parts of the codebase being rolled in, and so here we are, though having it be public is an interesting choice for Oracle. I wonder if it's also a PR move to get other people to leverage their "security" tree.

d_theorist 10y ago

What I would find more useful is a way to do something like: $ apt-get upgrade --security-only on a normal ubuntu distribution. The key thing for me is to have as little change as possible from the time the machine is initially provisioned.

kpcyrd 10y ago
debian supports something like this, if you remove the jessie-updates line and only have the release source (which is never changed) and the security source in /etc/apt/sources.list I'm not sure if this is recommended, I could imagine that some security fixes might be based on updated packages from jessie-updates. You might also run into fixed bugs by ignoring stability fixes, personally I don't think it's worth it.
- d_theorist 10y ago
  You are probably right. Interesting though; thanks.
iam-TJ 10y ago
sudo /usr/bin/unattended-upgrade This will only use the ${dist}-security target. Most systems should have this installed and available. The default configuration is at: /etc/apt/apt.conf.d/50unattended-upgrades It is configured as a system service that runs automatically at shutdown.
- d_theorist 10y ago
  Ah, nice. Thanks.

vog 10y ago

> This project provides an easy way to receive only important security commits I wonder if this is actually possible, given that a refactoring or code cleanup could also remove lots of security issues (which in part aren't even known today). This point is quite well articulated by the OpenBSD security folks, for example: http://www.tedunangst.com/flak/post/long-term-support-considered-harmful http://www.tedunangst.com/flak/post/long-term-support-consid...