Hi Rodrigo, On Fri, 2 Aug 2024 01:23:56 +0200 Rodrigo Arias <rodarima@gmail.com> wrote:
I'll be doing some tests with your patch when I have a moment. I'll need to get an OpenBSD VM for testing probably.
Sounds great! Let me know if you need any help getting OpenBSD set up.
In the meanwhile, I just wanted to link this compatibility unveil() function for Linux, so I don't forget the link:
https://github.com/rpki-client/rpki-client-portable/blob/master/compat/unvei...
Nice find. Not sure if this will be an issue: /* * This is by no means a proper implementation of unveil() but it is * good enough for rpki-client which uses only a few features. * rpki-client only uses 'r', 'rwc' and 'x' and for 'x' we need to do * some horrible hacks. */
I think a simple approach to test this is to find out if we cannot read the ~/.ssh/id_rsa private keys from Dillo or plugins by any means. So far I think we could read them by forging a call to the file plugin and maybe by forking a new process that doesn't have the unveil() protections and then reading ~/.ssh/id_rsa from there.
Right, but this attack vector seems pretty unlikely, and assumes the system is already somehow compromised (by calling a malicious program on the filesystem in an unveiled location).
I saw that the OpenBSD developers have placed an "uploads" directory to place files to be available to be read from the browser, and only that directory is allowed (along with the downloads dir). It doesn't sound a bad idea to me. This way we can avoid leaving ~/ unprotected in the file plugin. What do you think?
I believe the approach OpenBSD takes with Firefox and Chromium is to only give the browser access to '~/Downloads', which can be used for both downloads and uploads. Basically, users on OpenBSD are already used to this restriction, most likely already have a ~/Downloads directory, and don't think they would be too troubled to have this restriction in Dillo, especially if it is well documented.
To-Do: - Add prefs parsing to plugins to get 'save_dir' (may need help here)
I assume you could reuse the same prefs parser from Dillo, but we would need to link the DPIs with some of the code that is now only being linked in the browser.
I have made some efforts to do that, but was not successful yet. I included an example earlier of downloads.cc where I made some progress, but still something missing. I still wonder if it makes more sense to just use a fixed location (~/Downloads) if we are calling unveil, and override the save_dir with that. This ties back to my response above.
We can probably put the dUnveil() wrapper into dlib/ so it is available in all the other parts.
Thats a good point, I agree, and will work on it.
+ dUnveil(prefs.save_dir, "rwc");
What happens if someone puts save_dir to $HOME?, should we restrict it maybe?
To give access to ~/, and yet still protect ~/.ssh, we could do something like this (simplified example): unveil("/home/user", "rwc"); unveil("/home/user/.ssh", ""); But again, maybe it's better to override save_dir entirely if we are using unveil. Regards, Alex