Hi Alex,
On Sun, Jul 21, 2024 at 07:31:29PM +0200, [email protected] wrote:
Hi Rodrigo,
On Sun, 21 Jul 2024 13:33:32 +0200
Rodrigo Arias <[email protected]> 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.
_______________________________________________
Dillo-dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
