PostgreSQL pioneer's latest brainchild promises time travel to dodge ransomware Database pioneer Michael Stonebraker is promising his new concept of putting the operating system on top of a database could help end ransomware. The computer scientist behind Ingres and PostgreSQL has launched DBOS, with $8.5 million in funding, to help ease scalability in the cloud. By putting the cloud operating system on …
... I think this is a bit hyperbolic.
You can already snapshot filesystems and roll back almost instantly, but that doesn't really help with:
* Detecting the attack and knowing when it began
* Preventing an immediate recurrence of the attack when you roll back
* Having a reliable record of the work arriving since the rollback
* Reprocessing that work
* Working out where else the attack has spread to - including firmware/BIOS
Most of the long outages in response to ransomware have resulted from having to renew IT estates to eliminate unsupported and vulnerable software so that when data was restored it wasn't immediately subject to a repeat of the same corruption.
The rollback and then recovery would be using the DBOS transaction logs, replaying them after the attack transactions are skipped. So would be longer than the seconds stated, but could be dropped, while still being able to recover without any loss of data.
This is unlike snapshots, you will lose data rolling back to a snapshot, with data recovery being dependent then upon your backups.
The one thing that this doesn't take into account is the amount of storage that is going to be needed to do all this.
The bigger issue is that the "industrial and manufacturing companies" mentioned as being heavily affected by this problem are particularly concerned about their SCADA and other similar systems being taken down by ransomware.
These pretty much all use software from major automation vendors which run on MS Windows systems only and so are vulnerable to bog standard Windows viruses, including ransomware associated ones. There is usually a database involved, nearly always MS SQL Server. Porting them to another OS means a complete ground-up replacement of the whole application stack, which is a non-trivial undertaking.
Most of these installations, particularly those in factories, are not really suited to moving them to any sort of off-site cloud or data centre, as they rely on frequent low-latency polling of associated industrial hardware. Stuff involving utilities such as water or pipelines might be different due to things just inherently working a lot more slowly in those applications, but high speed assembly lines are far and away the most common industrial application.
A more promising approach to this particular problem for the mentioned "industrial and manufacturing companies" might be to move the existing applications and their associated Windows OS to VMs hosted on another OS. All the application related files and databases could be somehow written through to the underlying host OS instead of being hosted on Windows. Any transaction oriented file storage problem would then be isolated to just those application files necessary. Restoring would involving restarting the VM from a clean image and rolling the file transaction back to a known good point. I'll leave recovering the data from after the roll-back point as an exercise for the reader.
Of course this simply moves the goal-posts from attacks using bog-standard Windows viruses to attacks targeted specifically at the OS hosting the Windows VM. However, it would seem to provide the same sort of solution as DBOS would in this specific application, without replacing the entire application stack and without moving anything to "the cloud".
Yes. Stonebreaker's a great DB researcher and developer, but he's not primarily a security expert. And while defense in depth is always welcome, it's never a good idea to oversell a security feature.
Just consider "sleeper" ransomware that encrypts but then decrypts on the fly for some time before locking. That's a common technique to corrupt backups. Rewinding back a month isn't a much better alternative for an organization; there's a lot of value in the lost data.
Of course one defense against this is testing the backup — in whatever form it takes, conventional or DB OS — on separate, dedicated equipment, which is less likely to also be infected and thus more likely to detect encryption.
A bit of googling turns up that DBOS is a minimal Linux OS using FoundationDB as its file system. It's designed to run in VMs on cloud hosting services, and so doesn't include all the drivers for dealing with hardware directly. Those cloud hosting services of course all run on Linux.
There are of course a number of other "cloud native" operating systems which are minimal Linux systems designed to run only in VMs. DBOS's defining characteristic is that it uses it's FoundationDB distributed database for a lot of functions that would otherwise use a regular file system.
I wonder how many people at Microsoft are grinding their teeth right now. Weren’t they trying to build a database-centric filesystem in WinFS? That was one of the major innovations promised for Vista—and like all the others, it had to be abandoned before release.
This seems to only protect an organization whose data is encrypted in its database with an unknown key. The other risk in ransomeware attacks is that of having the organization's data exfiltrated and held for ransom by the criminals. I do not see how DBOS will address that risk.
OS/400 was not, initially, a POSIX-compliant OS — which isn't surprising, of course, since it evolved from the Future Systems project via the System/38. When POSIX compatibility was added to OS/400, it was an awkward bolt-on, with a second filesystem (HFS) that didn't fit well with the native one (IFS), and a lot of impedance between POSIX and native system APIs.
And OS/400's IFS was not a relational filesystem.
DBOS starts with a mostly-POSIX OS and replaces the filesystem underpinnings with a relational DBMS. That's very different from OS/400. You can argue which is better, under various assumptions, but they're certainly not the same thing.
I have multiple customers with machines that use elderly versions of Windows and DOS n that. Protecting them involves boring old properly designed networks, gateways and other boring stuff.
Fuck your cloud. It can't protect a 3D printer big enough to need a ladder to climb down into it or a printing press 50m long. Some of these things boot DOS 6. I have several Samba boxes acting as intermediaries because they can still speak NetBIOS or NetBEUI. Even so, you have to take quite a few safety catches off to get it to work but at least you can.
Oh and I have someone's AS/400 in my computer room. It is on its own network.
Patch, monitor ... patch, monitor. Its very boring but must be done. As some bloke once said: "Security is 1% fancy and fucking expensive gear and 99% boring, tedious and relentless log analysis ... and luck"
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2026
