Hi Alex,
On Sat, Jul 20, 2024 at 04:02:54PM +0200, [email protected] wrote:
Hi list,
I have been experimenting with unveil[1] and pledge[2] on Dillo to
reduce possible attack surface. Right now these system calls are
exclusive to OpenBSD, but there are projects[3] working to bring them to
Linux and other systems.
Basically, unveil restricts which areas of the filesystem a program can
access, and pledge restricts which system calls the program is allowed
to make.
[1] https://man.openbsd.org/unveil.2
[2] https://man.openbsd.org/pledge.2
[3] https://justine.lol/pledge/
Initial testing indicates that both of these features are working
correctly with Dillo. I am including a patch which provides some basic
filesystem protection, and limits Dillo to the minimum amount of
syscalls possible. If anyone has questions or comments, they are
welcome.
Thanks for the patch, I had just opened an issue on this topic a few
days ago:
https://github.com/dillo-browser/dillo/issues/225
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.
I also have to take a look at Justine implementation of pledge(2) for
Linux. Constraining the current design may already lead to some
improvement.
+ if (unveil("/home", "rwc") == -1) {
We may want to constraint this a bit further, so a malicious actor
cannot read anything from /home/.config. Maybe only /home/.dillo and the
downloads directory would be suitable?
+ if (pledge("stdio rpath wpath cpath inet unix dns tty proc prot_exec",
Does this work with plugins, when the dpid daemon is not running?, as I
believe it has to fork and exec the dpid program. Easy test:
$ dpidc stop
$ dillo dpi:/bm/
Best,
Rodrigo.
_______________________________________________
Dillo-dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
