No, and this is far from the only problem caused by BeOS legacy, as BeOS was designed long before security became such a worry as it is today.
chroots are ineffective because you can easily discover files outside of it (by queries, by asking the mount server about mounted disks) and get quite a bit of things done to a file with just knowing its inode and device.
There is a lot of memory sharing that gives applications more access than they should have to app_server data (including the framebuffer) and writing a keylogger is also trivial. Since a lot of things run as add-ons, they donât spawn their own processes, making them harder to detect.
The defence is to keep your computer offline or use an operating system designed with all these problems in mind. I donât think the Haiku team is staffed well enough to work on such issues. For now you get a bit of security by obscurity (few people know Haiku well enough to set up such an attack), but that will not hold for long if an Haiku user was to be targetted by something like this.
Anyway, what did you expect, all your apps are running as the root user with way too much access to everythingâŚ
What do you think could or should be done to make Haiku safer. At least the direction in which Haiku development should move should be defined. That security could be achieved in a defined future.
I think this part can be fixed with small effort. It should be possible to run GUI session and applications from non-root user and implement some permission confirmation dialog when running applications that need root privileges. It do not need to implement proper multi-user support.
I donât think posix multiuser is the tool to use here, there are way more ressources than just file directory entries that need to be checked for what application may use them.
And even for those the posix model is insufficient. (e.g a chat app uploading a photo should only have access to it once, for upload, and afterwards lose the access)
I donât think that it is realistic to design and implement some principally new permission and access control system as part of Haiku project with current available developers resources.
It doesnât have to be âprincipally newâ. OpenBSD is doing some syscall protections. AppArmor on Linux also implements finegrained permissions. From a user perspective, something like Android, where you can grant high-level permissions to each app (access files, access camera, acces microphone, access geolocation, âŚ) seems a good idea: finegrained enough that it is useful, but high level enough that it is not too complicated to configure.
Anyway, the decision will be made by whoever actually implement the things, as usual. So if someone think it is fun and interesting to implement running things as different users, it can happen first. If someone wants to implement an OpenBSD style system, it can happen first as well.
All this systems still use classic UNIX users and donât run everything as root user. So I think making running GUI session from non-root user is good place to start.
No, apparmor does not work on posix permissions. Neither does SELinux, OpenBSD pledge, FreeBSD extended filesystem flags etc.
The app_server should likely not need access to random files it doesnât need. Sure, but there are other much more pressing concerns like every application beeing able to use the network stack, even if not designed too (e.g by code injection)
All this features works in addition to POSIX users, not instead it. As you can see, applications in Linux/*BSD are not started from root by default. POSIX users are not declared deprecated feature.
sshd is started as root by default and employs seperation of concerns to make this âsafeâ
On OpenBSD it uses pledge to make sure it does not get access to files it should not have access to not posix users
It will simply be killed if it tried to open a file descriptor after it has declared (via the pledge call) That it has dropped this capability and wonât use it in the future.
Fortunately, Capsicum exists, so one does not have to reinvent the wheel.
From a user perspective, something like Android, where you can grant high-level permissions to each app (access files, access camera, acces microphone, access geolocation, âŚ) seems a good idea: finegrained enough that it is useful, but high level enough that it is not too complicated to configure.
No, itâs backward: instead of asking for permission to use all microphones in the system, a program should wait until the user gives it a microphone it can use. The user provides a microphone using a system dialog window.
Same with files: a simple application has no access to files and calls the system file dialog to get a file.
Posix multiuser allows to quickly solve the problem of a regular application being able to alter files in /system or in a boot partition. Thatâs a big improvement over the current state of things.
Android does both. It can grant access to the microphone prior to starting an app using system settings, or an app can request access to the microphone once it started through a specific notification.
or an app can request access to the microphone once
Again, you donât want to give an access to the microphone. You want to give a microphone to an app. The right user interface metaphor is facilities, not access.
I actually donât quite understand what the difference between âgiving the app access to the microphoneâ and âgiving the microphone to the appâ is. Isnât it just a different way in phrasing the UI, but essentially technically the same?
You know how Javascript apps running in the browser can read files from your local drive, but only if you open them explicitly using a file dialog, or with drag&drop? It doesnât get access to all your files forever more. Just the one you hand over each time. Thatâs the difference.
So instead of giving access to the microphone once (maybe at install time, or on first use) the app needs to ask for permission to use the microphone everytime it needs it? I think I still donât quite grasp the difference, sorry
Why? Because it does not allow the user to pick which microphone the application is allowed to see. The application should not be aware of any microphones but the one given by the user. Moreover, the user should be able to provide any audio source as a virtual microphone.
Another important detail: if user decides not to provide a microphone, this should be indistinguishable from the situation when thereâs no microphones at all.
