search

ricochet-im / ricochet

Anonymous peer-to-peer instant messaging
https://ricochet.im/
Other
3.7k stars 400 forks source link

Sandboxing #222

Open ioerror opened 9 years ago

ioerror commented 9 years ago

I've been experimenting with sandboxing Ricochet - I've contained it within an AppArmor profile when installed systemwide and confirm that it runs inside of xpra for X11 sandboxing. The xpra sandboxing causes some display issues with text labels on QT menu items. I think this must be a QT/xpra issue. None the less - this means that Ricochet is much more contained than when I started.

The main concern that I have is that Ricochet is much harder to sandbox than it should be - pulseaudio access means that it can potentially use that access to listen to the microphone when we only want to do notification of messaging. The fact that it runs Tor rather than connecting to a control port that can be filtered with a control port filter is much the same. Furthermore, I really think it would be good if Ricochet used the UnixSocket SOCKS5 code rather than using TCP/IP to talk to that Tor - regardless of Ricochet launching Tor or using a system Tor.

My future goals including running Ricochet inside of minijail ( ​https://chromium.googlesource.com/chromiumos/platform/minijail/ ) and generally approaching sandboxing as I describe in the Tor Messenger ticket on sandboxing ( https://trac.torproject.org/projects/tor/ticket/10943 ).

To make all of this easy to use - I've written an AppArmor policy file (to be installed manually or at make install time) and a very simple shell script that wraps Ricochet in xpra and could be expanded to cover OSX seatbelt sandboxing, etc.

special commented 9 years ago

when installed systemwide and confirm that it runs inside of xpra for X11 sandboxing. The xpra sandboxing causes some display issues with text labels on QT menu items.

There have been various issues with how Qt renders text, especially on Linux. The situation is improving in newer versions of Qt5. For what it's worth, I can run it under xpra on Fedora 21 with no trouble.

The main concern that I have is that Ricochet is much harder to sandbox than it should be - pulseaudio access means that it can potentially use that access to listen to the microphone when we only want to do notification of messaging

Wow, sounds like pulseaudio needs better policy support. Ricochet should function perfectly fine without it (minus the audio notifications). We should make sure Ricochet won't even connect to pulse unless those are enabled (#226).

The fact that it runs Tor rather than connecting to a control port that can be filtered with a control port filter is much the same.

This theoretically works, but there's no UI exposed to configure it, and no documentation on how. In practice, it usually fails because of the hidden service directory ownership. ADD_ONION support will help here.

Furthermore, I really think it would be good if Ricochet used the UnixSocket SOCKS5 code rather than using TCP/IP to talk to that Tor - regardless of Ricochet launching Tor or using a system Tor.

224, #225

To make all of this easy to use - I've written an AppArmor policy file (to be installed manually or at make install time) and a very simple shell script that wraps Ricochet in xpra and could be expanded to cover OSX seatbelt sandboxing, etc.

Great! Please submit a pull request for that. We can put these in a contrib/ sort of directory for now, and include apparmor in a .deb once there is one.

ioerror commented 9 years ago

I spent some time today working on sandboxing Ricochet with minijail. It was absurdly hilariously annoying. I opened #232 to contribute some basic minijail policies. I've also included an AppArmor profile and an example of using xpra to sandbox Ricochet.

special commented 9 years ago

For Windows, see https://github.com/MalwareTech/AppContainerSandbox