3 ms·

That's a bit critical, isn't it? Just think of servers. You want to reboot them as seldom as possible, to be online. But you also want to have critical securit

by onli 10y ago

That's a bit critical, isn't it? Just think of servers. You want to reboot them as seldom as possible, to be online. But you also want to have critical security patches (or well, just all security patches) applied as fast as possible. It is already very easy to run unattended upgrades, and a common practice. Maybe not in a high-class startup or big enterprise, but everywhere else. With livepatching the kernel you get the kernel security patches applied immediately, which is very very useful and will make the linux server more secure in general. And even if your security practices are perfect, livepatching is still (potentially) easier and faster and thus a good addition. > if your situation is so bad that a kernel update is the only solution I don't get that part, btw. In every situation you always need to update the kernel when security issues are detected.

glandium 10y ago
> I don't get that part, btw. In every situation you always need to update the kernel when security issues are detected. Not the GP, but he means that if you can't take downtime on a server to reboot with an updated kernel, then you have bigger problems than the kernel not being up-to-date. Because instead of a scheduled reboot, the server could crash, lose its disks, lose its power, etc. And if you can't take a scheduled reboot, how do you take those?
- Xiol 10y ago
  Got RAID and UPS, bruh. Norton on the box. Basically invulnerable.
  - cyberpunk 10y ago
    Raid? Pah! Putting your main tablespaces on ramdrives makes them go like 300x faster!! Redundancy is for cowards, just like unit tests... </s>
cyberpunk 10y ago
That's totally correct, and I can't disagree with you.. If you architect things properly, then rebooting any one component shouldn't be a problem.. In such a case though, there is no need for this tool.. In practice, though, things really don't happen all nice like that. I've got loads of internal boxes with holes. Terrible? Yeah, absolutely. We're all ashamed. These aren't a real problem security wise though, if you take a second to think about it... Say I have a box I can't bounce (or rather, won't bounce) to get a patch for some bug -- probably it'll be some DB server in a legacy env, or something so fragile that there's a massive risk in bouncing it, vs the risk of some DOS attack which could only happen from inside the network then usually, we just won't do it... Sure, that's terrible practice and not something anyone should admit, but it's the reality... Environments like this, the attack surface is the JVM and OpenSSH.. Assuming an attacker can get through our CDN, then through our rproxies (which we do seriously patch), after that blindly break out of a JVM on an ASLR'd linux box, THEN look to pwn a kernel hole on the DB server we've not patched, then do you really think patching is going to save you? It's a trade off; and it's all tech debt many teams are working to completely replace -- this stuff is horrible, but sometimes you have to put up with it until you can replace it.. To me it seems the attack surface isn't really the OS anymore -- it's the app. More likely whoever is hitting you is going to rip your DB off via some dodgy post sanitation bug than remotely pwning your internal boxes with kernel exploits -- so this does little to protect anyone..

by onli 10y ago

glandium 10y ago

> I don't get that part, btw. In every situation you always need to update the kernel when security issues are detected. Not the GP, but he means that if you can't take downtime on a server to reboot with an updated kernel, then you have bigger problems than the kernel not being up-to-date. Because instead of a scheduled reboot, the server could crash, lose its disks, lose its power, etc. And if you can't take a scheduled reboot, how do you take those?

Xiol 10y ago
Got RAID and UPS, bruh. Norton on the box. Basically invulnerable.
- cyberpunk 10y ago
  Raid? Pah! Putting your main tablespaces on ramdrives makes them go like 300x faster!! Redundancy is for cowards, just like unit tests... </s>

cyberpunk 10y ago

That's totally correct, and I can't disagree with you.. If you architect things properly, then rebooting any one component shouldn't be a problem.. In such a case though, there is no need for this tool.. In practice, though, things really don't happen all nice like that. I've got loads of internal boxes with holes. Terrible? Yeah, absolutely. We're all ashamed. These aren't a real problem security wise though, if you take a second to think about it... Say I have a box I can't bounce (or rather, won't bounce) to get a patch for some bug -- probably it'll be some DB server in a legacy env, or something so fragile that there's a massive risk in bouncing it, vs the risk of some DOS attack which could only happen from inside the network then usually, we just won't do it... Sure, that's terrible practice and not something anyone should admit, but it's the reality... Environments like this, the attack surface is the JVM and OpenSSH.. Assuming an attacker can get through our CDN, then through our rproxies (which we do seriously patch), after that blindly break out of a JVM on an ASLR'd linux box, THEN look to pwn a kernel hole on the DB server we've not patched, then do you really think patching is going to save you? It's a trade off; and it's all tech debt many teams are working to completely replace -- this stuff is horrible, but sometimes you have to put up with it until you can replace it.. To me it seems the attack surface isn't really the OS anymore -- it's the app. More likely whoever is hitting you is going to rip your DB off via some dodgy post sanitation bug than remotely pwning your internal boxes with kernel exploits -- so this does little to protect anyone..