i was reading about bfs and the Haiku packaging system: read only, saved states, and rollback.
There are some propritory softwares for Windows that provide a “fast rollback” feature as a way of restoring a corrupted system - and maybe to get rid of malware - without having to reboot. Don’t know how this is done though.
So, just wondering if some extra coding work to the bfs/packaging sytem could provide fast rollbacks to a saved state, without rebooting, as an antimalware feature. “But Haiku doesn’t have any malware” - you say. It will eventually - and an antimalware feature would be a great selling point.
For exampe: boot to the Haiku desktop; create a new user “surferjoe”; launch a web browser and surf the net - but collecting malware onto the system, which tries to copy your files and send them back to “hackerjoe”. After surfing, close the browser and delete user “surferjoe”, or rollback to a state before he was created, and surferjoe disappears, along with “hackerjoe”'s malware.
Of course, this would require the ability to create different users, and more coding thought and time, and may be an R1/R2 thing. But do others think that this may be possible?
The thing is we don’t roll back states at all. We just boot a different one.
Think of it this way: the bootloader just picks a different ser of packages to activate, it’s always in memory and never gets send to the disk. On the next boot the bootloader can pick a different set of packages.
Now the problem here is malware can simply overwrite packes, and the the different state won’t help you
What could help is cryptographic integrity checks of packages.
edit: also this system ONLY works for packages, not for non-packaged applications or user data
I read the article too and am glad it has invoked a discussion here. However the thread title did not suggest a link with that particular article and I wondered if it could be edited to make that connection.
I only found this thread by searching the blog name, to see if it had been mentioned here.
I’m pretty sure the repo file contains the sha256 checksums of packages (this need validated). So in theory the package kit just needs to validate the minisig and warn users when the repo signature isn’t valid.
So we’re close, but someone needs to do the work in the “difficult” package kit spaghetti java factory code.
The article says that each user has a /boot/home/config directory where they can install their packages, and that this is effectively a copy of the system directoy. So it seems like having virtual filesystems could be the basis for a security feature.
if Haiku was multi-user and also had jails or VMs, it could work similarly to Qubes Linux, that has multiple VMs and a disposable network VM. For example, the root user could create a disposable “networkjoe” user, with his own isolated virtual filesystem (or jail) and web browser app for surfing the net. When finished surfing, any dowloaded files are copied to another user filesystem or to root, while the “networkjoe” user (filesystem and apps) are deleted - along with any downloaded malware (e.g., cookies, ads, cruft, etc.). No rollback required. In this way malware doesn’t infect the system.
Or, the root user could create numerous “userjoes” as a kind of “honeypot” to trap hackers in a maize of virtual filesystems. This would be like a cross between BSD and Qubes Linux security features - or maybe Haiku could add a new, faster, twist to such securiy measures.
The filesystem and apps are immutable in your example, I see no reason to delete them.
I don’t see how this protects against malware if you download files anyway
You seem to implicitly assume that ads and malware are related, while they are partially it seems to me that the webrowser refusing most cookies by default and blocking ads would go much better into the direction of “safer browsing”
Of cource, if your main fear is tracking then maybe don’t use webpositive… it’s likely easily trackable.
In the 90s (or probably earlier on serious systems, not home computers), we got memory protection. This allowed to isolate apps from each other so they could not read each other memory. But then developpers wanted some way for their apps to communicate still, and so, many ways to do that were added.
30 years later, we got virtual machines in QubesOS to again isolate apps from each other so they can not share data. I have my guess about what will happen next
Immutability / read only I think means that things can be changed - e.g., by malware or a hacker - while the OS is running. But any changes made will be discarded on reboot.
Encryption means things can be changed - e.g., by malware or a hacker - while a file / volume / disk is decrypted. It’s mainly useful when the file / volume / disk is not being used.
Browser add-ons are good for casual surfing, but they don’t stop persistant malware or hackers.
So you can still get your data stolen under the above scenarios. The trick is to have the right security tools to make it difficult for malware / hacker to get into the system, or execute code, etc. This could be done via a VM / sandbox / jail, or firewall, or intrusion detection system, 2factor authentication, etc. And it seems that Haiku has a good design for such security tools, because its got good foundations of read only, immutaility, virtual filesystems, states, etc. And it’s got SPEED. If Haiku could maintain good speed while full with packages, and running various security tools, then it would be ideal for some interested devs to create a hardened edition. Some security tools could be ported, and maybe some new native ones could be created.
Yeah, everything runs in cycles. But if you want Haiku to be used by businesses and organizations, your gonna have to eventually have some sort of security. Because, for one thing, they will be fined by their governments if their users’ data is stolen (they have to report such breaches). Without security Haiku will always remain an OS for casual / enthusiast users.
immutable means unchangeable, even while the system is running.
We also don’t have browser add-ons rather make the browser behave properly directly.
There are a lot of things one could do for improved security, but we should do that very deliberately. I don’t think just copying the ebtire OS behind some boundary is gonna make it any more secure
The main stuff users need protected really is their files, so maybe start from that:
why do apps that don’t use files still allowed to read them?
why are apps that don’t need network allowed to open a socket?
I think some of those security questions could be answered by something like openbsd pledge, but redone for our needs.
Perhaps adding a whitelist of capabllities the app may perform to it’s ressources.
What you describe, that I understand is an established concept called “capability based security”, is used by aspiring operating systems such as Fuchsia and Genode.
Presumably Open BSD are having to retrofit something similar into what is essentially UNIX, whereas Haiku may still be young and malleable enough to absorb the capabilities infrastructure from one of the newer systems after R1?
