Re: [PATCH v2] Unveil patch

Hi,

On Sun, Aug 04, 2024 at 05:14:52PM +0200, [email protected] wrote:
>> If you see your SSH key in the stdout, the unveil() protection alone
>> is not enough to mitigate this attack (check that the key exists
>> first, I used id_rsa). This would also confirm that unveil() settings
>> don't get inherited in forked children.
>
>I placed that after the last unveil call and made sure I used a valid
>key path. Here is the console output:
>
>game over exploit, fopen failed: No such file or directory

>>From what I am seeing, fork() inherits the unveil, and exec() does 
>>not.

Hmm, I guess that makes more sense.

I was thinking we could read the preferences only from Dillo, then 
unveil accordingly, and then all DPIs would already get the unveiled 
environment.

But as you comment, on the exec() the unveil will reset, so we will need 
to re-read the dillorc file again. I think this is also a good approach 
in case someone runs the dpid by hand, so it adheres to what dillorc 
says.

>> Maybe for now we can add a simple implementation of the parser just to
>> parse the "save_dir" and the new "enable_unveil" (or similar) option,
>> like dpid is doing for dpi_dir.
>
>Ok thanks, I will try to use that as an example and see if I can get
>anywhere with it.

Thanks!

>> I think we could just not allow $HOME to be set as save_dir (or any
>> directory that contains $HOME, like /home) and refuse to start if this
>> is the case.
>
>Not sure I understand what this achieves. So '/home/user' would be
>blocked, but '/home/user/foo' would be allowed? Why not just explicitly
>block access to ~/.ssh with unveil, and then let the user do whatever
>they want after that?

Yeah, but there may be a lot of other unknown directories we don't want 
Dillo to access to (~/.config, ~/.cache, ...). So I think is a good 
approach to block all directories in home, except the downloads one.

Another attack may involve encrypting ~/Pictures and asking for a 
ransom, so we should prevent any access to home that is not required.

Best,
Rodrigo.
_______________________________________________
Dillo-dev mailing list -- dillo-dev-lx9mn2B4QYRWk0Htik3J/[email protected]
To unsubscribe send an email to dillo-dev-leave-lx9mn2B4QYRWk0Htik3J/[email protected]