Linux kernel maintainers pitch emergency killswitch after CopyFail and Dirty Frag chaos Linux kernel maintainers are considering giving admins a giant red emergency button to smash the next time another nasty vulnerability drops before patches are ready. The proposed feature, named "Killswitch," would let admins temporarily disable specific vulnerable kernel functions at runtime instead of sitting around waiting …
I've been spared more than a couple times because I just don't build modules I don't need.
It always seemed like a bad idea to have a thousand unneeded kernel modules sitting around waiting to be demand-loaded by next week's exploit program.
You can achieve something similar by disabling/blacklisting modules you do not need.
The problem when you don't build in the modules is that you no longer have PnP for the vast majority of prospective users - you're going to have rollout or application failures on new[bies] systems when the module calls fail and they don't understand what's happening. It is OK for the advanced Linux user of course, but can be frustratingly 'deadly' for larger-scale Linux adoption across unknown configuration needs.
Quite.
But the days of "make allmodconfig" are long gone and I haven't compiled my own kernel in years now.
It would be nice, however, to have systems configured so that module loading of new modules required explicit and secondary elevation (rather than just using sudo for install and it automatically loading lots of modules along the way).
>> the kernel community increasingly seems to be arriving at the conclusion that running broken functionality
If the kernel community can't spot the bugs (fair enough, it's complicated) then I don't expect them to spot all the side effects of having a kill switch either. It's just xyz function. Oh, something deep down has a hook into xyz. Panic.
For some aspects I can see it making sense. Things like crypto extensions/optimisations where the kernel can reply "I don't have that" and the library will say "OK, we'll calculate it the traditional way"
Or drivers where it can fall back to a generic driver (eg displays falling back to VESA mode)
But for the most part, if the system can behave without those bits loaded then they shouldn't be loadable.
Yes, that might happen. The more an admin knows about whether they're using a certain thing, the more certain they can be about whether that's going to break or not. Some software can also plan for kernel functions ceasing to work and having a fallback or at least crashing more nicely. The decision every admin has to make is how much they want to avoid a possible crash and how much they want to avoid a possible attacker with root access, with this being an option allowing you to decide to take a higher chance of crash and a lower chance of attacker if you so choose.
>> The more an admin knows about whether they're using a certain thing,
I've been through this. They may not know. It's not good enough saying "they should". Is an admin supposed to know every function call? They can't and won't. It's ridiculous to even make the suggestion.
I didn't say everyone should or will. You don't have good choices. You are going to take a risk somehow, and this lets you choose what risk. It's also not as dire as you describe because, if the worry is that something will break because it used to be able to count on some functions working and now can't, that can be solved by rebooting when enabling the kill switch, meaning everything starts up again with the new behavior from invocation. When something this severe happens, there's no solution which fixes it all until the patch is out.
I guess this could have some uses, but there are signficant manageability problems.
It's not really enough to just kill some apis. You need to know how system behaviour is changed, as well as capability. Otherwise you don't know what you're providing or supporting.
Is the kernel team going to be issuing security advisories with impact statements ?
If it was Windows, you'd simply expect more BSODs. Easy to detect and communicate to end users.
But there's a good chance that Linux will log some complaints somewhere and soldier on in a fashion.
And how do you secure that killswitch against abuse ?
A killswitch IS a measure of last resort, pretty much by definition.
> You need to know how system behaviour is changed, as well as capability.
Yes, and that's the job of the sysadmin. Before using the killswitch: People need to read up what the thingamajig they are about to shut down is doing, and need to decide "Does my system need this to work?".
The kernel team cannot tell people whether or not flipping the killswitch is good for their system or not, because the kernel team doesn't know the ins and outs of every Linux box on the planet. That responsibility is on the sysadmins.
> And how do you secure that killswitch against abuse ?
The same way all core functionality is secured I'd say, by requiring root access to use it.
No it's not a kill switch, it's a frontal cortex snip.
And it's far far below the sysadmin level. Show me the reverse dependency graph showing how kernel api X is propogated up through Libraries Y1 and Y2 to applications Z1 and Z2 which are running as daemons for app Z3.
Since all core functionality is protected by root, tell me again why we need a kernal api kill switch ?
>> People need to read up what the thingamajig they are about to shut down is doing
See my point above. They may not know. Would you know 100% for sure that a driver your system uses has a hook into a specific kernel function? I doubt it. I wouldn't expect you to. It might not even be documented, so expecting people to know it is not reasonable.
I don't know exactly what they're talking about here but you could hide such dangerous functionality behind PKE. In order to set it up you could create a public/private keypair and install the public key(s) for various killswitches in a config file. To activate you echo the private key into a specific place in sysfs designated to disable that function. It only executes if the correct private key is provided.
That way hackers who break into your system can't kill switch a bunch of necessary functionality as a DOS attack. Though honestly if someone has root on your system (the killswitch would OBVIOUSLY require root) the amount of damage they can do is such that worrying about a killswitch attack is probably a waste of time.
...to a kernel near you are two new name-brand security vulnerabilities: Kill Fail and Dirty Switch. These local privilege escalation bugs with chained remote under active exploitation can be mitigated by removing the killswitch loadable kernel module. This also has the advantage of reversing an earlier performance regression.
The moral of the story: You can't fix the problem of too much complexity by adding more complexity.
That abuse is already possible, as is most other types, for someone with the required access. If I'm trying to break your system and I have enough access to use this kill switch, I can break it in a lot of more problematic or subtle ways. The risk with this is not that an attacker will abuse this but that someone trying to use it will end up breaking their own system and needing to reverse the setting, perhaps at worst from a non-booting system.
Seems the problem isn't the vulnerabilities that got detected, but the appalling way they were advertised to the entire world, before patches could be rolled out.
Now call me a cynic, but this likely left many Microsoft execs drooling in ecstasy as Linux got a kick in the security credentials. I always doubted the M$ motivation to get on-board with Linux, and foresaw a time when their involvement got leveraged to outright sabotage.
Linux rules the server and super computer world, and given time and a fair playing field would come to dominate the PC world, as it has the mobile phone operating system.
Linux is so precious to the future of this world that we need to protect it from unscrupulous actors, whether they be hard nosed capitalists protecting their monopolies, or state sponsored agents seeking to undermine its and our security.
> "Seems the problem isn't the vulnerabilities that got detected, but the appalling way they were advertised to the entire world, before patches could be rolled out."
"Vulnerability rolled out ungracefully" is always on the sysadmin's bingo card. Great when it's not, but we can't expect that.
Seems the problem isn't the vulnerabilities that got detected, but the appalling way they were advertised to the entire world, before patches could be rolled out.
The process is what it is because so many reported vulnerabilities were simply ignored. Companies didn't want to waste $$ chasing bugs in legacy code. OSes didn't want to admit that they had vulnerabilities. OSS devs that had other priorities. It had been the practice to report the bug to the owner, then wait a period of time before announcing to the world. But if your only option for reporting a vulnerability is to open a ticket on some public bug tracker that is possibly monitored by people who want to find new exploits, do you not report and hope no one else finds it, or use the tools available that make it public immediately?
BTW, note that the details of neither of the CopyFail or Dirty Frag were 'simply released'. They were reported, there was an embargo on releasing the details, and someone else released exploits. One was by looking at developer commits to fix the problem.
Also, both of these were LPE (Local Privilege Escalation). So rather than needing a kill switch, lock out non-admin local logins until it's patched.
> Seems the problem isn't the vulnerabilities that got detected, but the appalling way they were advertised to the entire world, before patches could be rolled out.
LOL. Can you imagine the ridicule from the linux crowd if a MS evangelist used the same excuse about Microsoft vulnerabilities?
The outcome of these series of bugs is that if security matters, then the operating system need to be running the SELinux 'strict' ruleset. Many operating systems run the SELinux 'relaxed' ruleset, no major distribution uses 'strict' rules as the default ruleset. Then those system calls would have been rejected as they are not made by from a context authorised to make them. For example, calling into the networking IPsec code, but not from a program marked as being a IPsec user space program.
We've been lucky so far. The modules with issues have been unpopular (although IPsec tunnels are starting to impinge on everyday use). But one day a popular system call will be implicated, and turning off that system call will be the same as turning off the operating system. In that case we will want to determine the context from which the system call was made before allowing access to the system call, and SELinux 'strict' rules is the only technology doing that today.
This is turn means that distributions need to get serious about the 'strict' ruleset if they are to provide ongoing protection from this class of bug, rather than be chasing the bolting horse. At the moment the 'strict' ruleset is too much of an adventure for most systems administrations, let alone personal use of a computer.
The problem being that almost every problem I encounter on Linux when doing basic things ties back to either a) systemd or b) SELinux rules.
And I'll be honest... I just don't have the time to bother to learn their stupid configuration / syntax / etc. in order to fix them.
If it fixed the problems instead of just disabling them then they'll have reinvented SetPatch for the Amiga.
Much as the idea appeals, you just 'Know' that some clever little hacker will work out a way to 'push' the 'killswitch' for 'fun' and create havoc all around.
Yet another powerful feature that is going to be protected by root.
As per ususal, gain root access and have fun fun fun !!!
Until root access is 100% safe/secure and only accessible by the Sysadmin, it is just another set of 'toys' for the miscreants to play with !!!
:)
