Hi Alex, On Sat, Jul 20, 2024 at 04:02:54PM +0200, a1ex@dismail.de 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.