Hi Alex, On Sun, Jul 21, 2024 at 07:31:29PM +0200, a1ex@dismail.de wrote:
Hi Rodrigo,
On Sun, 21 Jul 2024 13:33:32 +0200 Rodrigo Arias <rodarima@gmail.com> wrote:
I can see clear benefits on restricting the file system access, but do you have in mind which type of attack the pledge() configuration would you help mitigate?
It might reduce the attack surface for exploits in things like image and compression libraries. Or maybe there could be a bug in FLTK. Or in Dillo itself. I'm not saying these things are very likely, but they are possible. Since Dillo is a complicated program, we have to grant it access to lot of syscalls, which limits how effective pledge can be. But it still offers a level of protection which can be valuable in various scenerios.
Sorry, I think I didn't explained myself very clearly :-) With "which type of attack the pledge() configuration would you help mitigate?", I meant: if using your current configuration of "stdio rpath wpath cpath inet unix dns tty proc prot_exec" you have in mind an specific attack that we can mitigate, as this is giving Dillo access to a lot of syscalls which can be used to easily exploit any bugs. Also, I think it is very likely we have some exploitable bugs laying around in the parsers and other parts of the code and I don't think we will be able to use pledge effectively until we change the design to be able to split Dillo in more than one process. But maybe there is some exploitation that we can prevent right now with that combination that I'm not aware of. Otherwise I'm not sure if it is worth using pledge(2) as-is, until we change Dillo design so it is more effective. However, I think using unveil(2) is an effective way of restricting a lot of attack surface and doesn't require any design change. Maybe it would be better to start with unveil(2) alone and think later how to approach pledge(2). In Linux there is Landlock[1] (and also a project to implement an API like unveil on top of Landlock[2]), so it should be possible to at least implement support for OpenBSD and Linux to restrict access to the FS. [1]: https://landlock.io/ [2]: https://github.com/marty1885/landlock-unveil
Regarding something you said earlier:
I believe it would be nice to move the network facing code away from the parsers, so the parser code cannot use the network or read the file system. This requires separating them in different processes.
This sounds like a very reasonable approach which would benefit all Dillo users and not just the small minority who have access to pledge and unveil.
This is something I'm considering addressing already in RFC-002, as we will have to change the way Dillo exchanges data internally, we can move to a message passing design. While right now we will continue to use a single process, this design could potentially run over different processes, and then we could use pledge(2), seccomp(2) or other OS protection mechanisms for the untrusted code. I think it is important to remember that Dillo is a *multiplatform* browser, and it would be nice if security features are be available in all supported platforms. If you want to add support for unveil(2), I recommend you do that in the Dillo git repository with an #ifdef guard, so it can be enabled only if build for OpenBSD, and with some way to enable/disable it for testing. I can help you with this part if you are not familiar with autoconf. Then we can see how to add similar protection for other operating systems. Best, Rodrigo.