Hi Rodrigo, On Fri, 2 Aug 2024 01:23:56 +0200 Rodrigo Arias <rodar...@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/unveil_landlock.c 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 _______________________________________________ Dillo-dev mailing list -- dillo-dev@mailman3.com To unsubscribe send an email to dillo-dev-le...@mailman3.com
