| Newsgroups |
gmane.comp.web.dillo.devel |
| Message-ID |
<[email protected]> |
Hi Rodrigo,
On Fri, 2 Aug 2024 01:23:56 +0200
Rodrigo Arias <[email protected]> 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-lx9mn2B4QYRWk0Htik3J/[email protected]
To unsubscribe send an email to dillo-dev-leave-lx9mn2B4QYRWk0Htik3J/[email protected]