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. > I think allowing exec and inet is too permissive and would allow an > attacker to easily spawn a remote shell as soon as a RCE bug is > found. I agree about exec, but right now without inet Dillo fails to start. One drawback to this current implementation is that things like my external link handler patch, and your multiple-actions patch don't work anymore. I ran some tests and confirmed that it causes issues, even with exec pledged. Maybe it would be possible to work around that with an un-pledged process which does the call, which would have to be started by Dillo prior to the pledge call in main. I did some experiments with initializing dpid prior to the pledge call being made, so that it can run un-pledged. It seems possible, but may require other changes which seem to be above my current skill level. > I think is a good idea more OpenBSD people review this part, as I'm > not very familiar with pledge(2). > > However, I'm afraid having this patch only in OpenBSD may cause a > negative effect, as we may start receiving bug reports that are only > happening on OpenBSD with that patch and cannot be reproduced on > Linux or other systems without it. > > Maybe you can make a hardened Dillo port, so people can still test > the non-hardened port to determine if the problem comes from these > changes. I will have to think a bit on that, but maybe I'll start by forwarding this thread to some OpenBSD people and see what kind of response comes back. Really not sure how much interest there will be in this, as I suspect the amount of developers who use Dillo on OpenBSD is not huge. Hopefully I'm wrong. :) 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. -Alex _______________________________________________ Dillo-dev mailing list -- [email protected] To unsubscribe send an email to [email protected]
