Idea to improve security on Haiku (Immutability)

Hello everyone!!
I’ve been reading through the security topics on the forum, and I would like to suggest something that could improve the security of Haiku, considering that applications run as root by default.

My idea is not a try to Linuxify Haiku, but, maybe we could take some inspiration of the immutable distros.
In this kind of distro, the root filesystem is read-only, with 3 or 4 folders which the user can access.

The only problem is the fact that software must be containerized to run on this kind of system (on Linux, mostly using flatpak/snap).

I’m just a C++ begginer, learning the basics of the language, but I would happily hear the professional opinions of the developers/users here.

Thanks for reading!!

We kind of have that already, have a look at packagefs.

1 Like

Haiku is already immutable and has been for much earlier (2018 or possibly earlier) than most of the prominent immutable Linux distros.


I’m not a fan of preventing users from modifying system files. There have been plenty of times I’ve needed to do so in other operating systems. It’s really messed up when I can’t even force the OS to give me permission to modify what I want to.

1 Like

Look: Haiku Package Management -

1 Like

In Haiku the „root“ (that is /) Is purely virtual, as it should ideally be in linux too!

I‘ve made my own distro with this once for fun, but generally distros tend not to do this.

In Haiku the /system mount point corresponds to the Immutable view of packages which are mounted ontop of each other (think like a union RO filesystem, but actually working)

1 Like

I didn’t know about all that!!
Haiku is really impressive.

Now I wonder…are there any security flaws at the moment??


1 Like

For one thing, everything is running as root.

Yes, each application currently have access to whole filesystem and run with root user by default. Some chroot or filesystem virtualization would be needed to protect user files.

1 Like

You cannot have 100% security and 100% freedom. What a user can do, so can software. Settling somewhere in the middle is about where we are today, with most OS’s. But wouldn’t it be nice to NEVER have to worry about your system being compromised? Wouldn’t it be nice if your OS was looking out for you instead of you having to be watching out for your OS? Wouldn’t it be nice if your OS was idiot-proof? Sure, you couldn’t tinker with internal settings and files… but neither could some malware. I’d far rather have an OS I could use without the fear of something being compromised, than to have the freedom to dig around and mess things up, if I did something wrong. Why do people feel the need to tinker? Why can’t they be focused on simply USING their OS, not messing with it for one reason or another?

Part of the reason (if not most of the reason) Haiku exists is because people like to tinker. And I’m all for warnings about messing with system files, but there should still be a way for me to bypass such things. If I go around messing with system files, needing to run some terminal command or enter my password to do so, then that’s on me.


If your intention is to mess with every part of the system, outside of creating your own Haiku images then there are prolly more suitable other OSes for that.

1 Like

You are pretty much free to “unpack / modify / repack” any .hkpg as you want. /bin/package makes it dead easy. You’d most likely need to avoid pkgman full-sync and be mindful of pkgman update (with you needing to re-apply your wanted changes)… but hard from impossible, or even being hard at all.

That, combined with the more usual “place custom binaries/data” under /non-packaged/, should go a long way in letting you customize the system, while still enjoying the conveniences of PackageFS.


What a user can do, so can software.

It does not have to: different programs could have different capabilities. You should not give a random app from the internet an ability to modify the system, but Tracker is not a random app from the internet.

Also, user changes could be layered on top of immutable base. So the system could be brought back into the original state by simply reverting user changes, and in the same time nothing stops the user from tinkering.

As it is already mentioned a lot of times, read-only installed software files is not a matter of security and intentional restrictions, but purely technical detail. Software files are read directly from HPKG archives without extracting. This approach have various benefits in addition to security such as faster install/uninstall, less disk usage and wearing, consistent updates.


It´s maybe a bit ironic to ask questions like these on a forum dedicated to the development of an open source operating system :wink: I still get your point, though and agree that having installed software reside in read only packagefs is a good thing. There´s still lot´s of opportunity to “tinker” with the OS though, many of them already mentioned in this thread.

There is. Just extract the packages

If this is a serious issue, it might help to identify a specific problem that someone who “likes to tinker” might run into. It isn’t like the package filesystem restricts write access to your home directory only - parts of the system directory structure are BFS too.

As far as kernel security the pledge interface from OpenBSD would probably be good to implement also… seems like relatively low hanging fruit.

It works by the application telling the kernel (I don’t need this this or that, and the kernel denies access if the application ever asks for those later such as if its process has been hijacked). You can also do things like have access to some things at startup for initialization of a service then pledge to not use those things again if they are never needed after init.

I think OpenBSD and SerentiyOS are the only ones to implement this so far, but seems like something NetBSD might pick up too eventually.