Main logic and UI should be separated into a daemon and a dbus based UI process. about opensnitch

[taoeffect]

Comment:

opensnitchd will be a C++ daemon, running as root with the main logic. It'll fix this.

We're in 2017 now. There's little excuse to start new projects in C++ instead of Rust, especially if they're security critical.

[evilsocket]

jk, I'd love to have the time :(

[evilsocket]

I'll repost this here, just to have more feedback :)

Future Plan

• opensnitchd will be a C++ daemon, running as root with the main logic. It'll fix this.
• opensnitch-ui python (?) UI running as normal user, getting the daemon messages. Will fix this
• opensnitch-ruleman python (?) UI for rule editing.

Questions

1. What is the best IPC method in this case? I mean, if the daemon just creates a unix socket readable and writable by any user, any third party malicious software could access it and simply ACCEPT every packet ... dbus? No idea how it works honestly.

2. What's the best way in your opinion to keep all the involved/interested developers in sync and let them communicate without using github issues? Mailing list? Slack? Pigeons?

[taoeffect]

It's your project, you can do whatever you want with it of course, but in case it's at all helpful here are some possibly useful/interesting links:

• Rust for C++ programmers
• Rust from a C++ programmer's perspective

[evilsocket]

guys I just created a private Telegram channel for devs, where can I send you guys the invitation link?

[evilsocket]

No, it's not. For now, I'd rather just have a devs-only private channel, we're not ready to have a public chan with thousands of ppl asking for support :P

[adisbladis]

I would highly suggest going with dbus for IPC. It comes with a fully fledged SASL implementation for authentication, it's present on all distros and in wide use.
Don't re-invent the wheel :)

[WhyNotHugo]

Definitely no intention of reinventing the wheel, it's just a matter of choosing the right wheel and how to use it. 🙂

I was unaware that dbus provided the authentication we need. How does it avoid other [malicious] processes from messaging a certain interface?

[evilsocket]

@nmindz No, because if I'm user evilsocket and I get infected with malware, the malware will run with my user, therefore with my group.

[evilsocket]

Why are we still talking about polkit? Once IPC and authentication are implemented (correctly), the UI env. will not matter as OpenSnitch will be able to have different clients/UIs in different technologies.

Let's stop this here, no need for polemics at this stage of developement.

[holderbaum]

Cheers everyone,

what is the state of this project? Is the separation still in planning. If so, I would be happy to support. 👍

[adisbladis]

@holderbaum The state is slow and steady. Neither me nor @evilsocket has not had much time to work on this recently but I think we are both motivated to do it when there is time.

I have been working towards this for some time and it's almost there.
Lots of things have been logically separated already and we are using a bit of poor-mans "IPC".

As you can see in https://github.com/evilsocket/opensnitch/tree/master/opensnitch/ui all the ui code is now self-contained and separated.

The only place where this code is referenced outside of the ui directory is here: https://github.com/evilsocket/opensnitch/blob/master/opensnitch/snitch.py#L88

And here is our poor-mans IPC https://github.com/evilsocket/opensnitch/blob/master/opensnitch/ui/app.py#L46 https://github.com/evilsocket/opensnitch/blob/master/opensnitch/ui/dialog.py#L177

Here is what we need to do to get there:
We need to get things running as a non-root user to use the dbus session bus.
Using the System Bus is out of the question for now since it needs to be provided by a .service file on systemd based distros (which is great for us since it solves the issue of some malware impersonating opensnitch).
This would seriously hinder any development.

I was trying to use http://man7.org/linux/man-pages/man1/capsh.1.html to accomplish this but could not get it to work properly. If someone is more successful than me with this tool I think that is the ideal solution.
In the meantime I have started implementing a ctypes based capability interface.
If anyone else feels like they have more time than me with this here are the caps we need to run:
cap_net_raw,cap_dac_override,cap_net_admin.

After that it's "just" a matter of switching out these hacks with futures and Qt signals for dbus messages.

This should give you a pretty good image of where we are currently.
Sorry for the wall of text :)

[adisbladis]

There has been some solid progress in https://github.com/evilsocket/opensnitch/tree/dbus-ipc \o/

Things are mostly working though not thoroughly tested yet.
There are some minor remaining issues to iron out like implementing more error handling, transparently reconnect the ui in case the daemon gets restarted and so on.

#65 has also been fixed in that branch :)

Isn't this pretty much what Polkit is for?

See also https://news.ycombinator.com/item?id=14252265

[WhyNotHugo]

@voltagex Polkit is also for running GUI apps as root, this is what being advocated against here. Privilege separation is probably the cleanest approach.

[WhyNotHugo]

In response to your questions:

1. Probably making the socket writable by a group, and then users that are allowed to control the daemon should be members of that group. That doesn't exclude malicious apps though, but I can't think of anything. This'll probably require some research.

2. GitHub issues tends to work the best for projects of this size and age (a mailing list is a bit unfriendly to sum, and you might keep people off by it, TBH). Pidgeons won't scale if you have remote developers. 😛

[evilsocket]

@hobarrera Mmmm, about 1, from the bottom of my deep ignorance about UI and IPC on GNU/Linux, I was thinking about something like:

• Daemon runs a websocket (or similar streaming protocol) server with authentication on a unix socket.
• Authentication token/credentials are globally stored inside /etc/opensnitch/auth.conf or whatever.
• On first run, UI will ask the user for such credentials and use that to authenticate towards the daemon.

[WhyNotHugo]

On first run, UI will ask the user for such credentials and use that to authenticate towards the daemon.

How will the app store this? Or more importantly: what prevent malicious apps from reading what is stored?

A second, interesting, approach, is that the UI has a dedicated user, and installed as setuid. Probably worth some thought, but I might be missing something too.

[evilsocket]

How will the app store this? Or more importantly: what prevent malicious apps from reading what is stored?

Very good point, secure IPC is a bitch :P

A second, interesting, approach, is that the UI has a dedicated user, and installed as setuid. Probably worth some thought, but I might be missing something too.

Dunno, it might cause troubles for packaging and cross distribution compatibility :S

[WhyNotHugo]

Definitely (on both items). Packaging would need to be delicately documented in case that's actually a viable route.

[WhyNotHugo]

Is this channel open to anyone? If so, you can include a link in the README as well. :)

[eliasp]

DBus will also make it far easier to integrate it into various DEs (e.g. SNI-based systray), communicate with NetworkManager and/or systemd-networkd, have other people/tools interact with opensnitchd, etc.

[samis]

While it doesn't give you a solution to the authentication problem if you were of thinking of using an RPC-style interface, you may find Cap'n Proto to be useful. There's apparently a python implementation at https://jparyani.github.io/pycapnp/ and general documentation at https://capnproto.org/index.html

[evilsocket]

@samis I'm not concerned about the protocol, that can be websockets, protobufs over tcp, whatever ... I'm concerned about security, let me explain:

Scenario:

• OpenSnitch is running on /var/path/to/unix.socket which has to be readable by every user (because you don't know which one will start the X session).
• Computer gets infected.
• Malware kills UI, attaches to /var/path/to/unix.socket always responding allow:*.
• Malware talks with C&C server.
• Game Over

[evilsocket]

Bonus:

• Malware exploits that socket to gather EoP using OpenSnitch daemon.

:D

[evilsocket]

IDEA:

Maybe the UI could be signed somehow, with random keys generated during first boot, daemon keeps private key as root (thus protected from users) and verifies whoever connects to the unix socket ... i honestly don't know if this would work ...

[nmindz]

@evilsocket From your first bullet on the scenario description...

Wouldn't using Polkit and leaving the socket readable only to members of a specific group work and be enough to block alien processes or malware to read it without elevating privileges first?

[evilsocket]

Think to simple yet effective phishing scenarios like: someone sends you a .desktop file disguised for god-knows-what with command execution inside and comm. to CnC

[WhyNotHugo]

For now, the only solution is to have a dedicated user for the UI, and make the UI setuid. Then, make the socket-or-whatever writable by that user only.

[evilsocket]

Mmmm like, I don't know Rust and have no willing to learn it in the short term future?

[eliasp]

Think to simple yet effective phishing scenarios like: someone sends you a .desktop file disguised for god-knows-what with command execution inside and comm. to CnC

That's one of the points of polkit where system-provided policies define what gets executed, whether it requires interactive confirmation/authorization/password input etc.

[WhyNotHugo]

Just read the wikipedia page for polkit, and that made it a bit clearer for me.

So, the flow would be:

• User gets a popup (accept/deny).
• User clicks yes
• polkit jump up and prompts the user for credentials.
• polkit allows communicating with the daemon and sending the approval

Right?

[WhyNotHugo]

Do you have an example of a desktop application that uses polkit? Nothing in my system that requires it seems to prompt for any permissions under any scenario.

• colord
• gconf
• lib32-polkit
• modemmanager
• polkit-qt5
• rtkit
• udisks2

I also wonder a bit how polkit shows the dialog for prompting the password. Does the lib depend on gtk or something? Are developers responsible for that prompt?

[eliasp]

I also wonder a bit how polkit shows the dialog for prompting the password. Does the lib depend on gtk or something? Are developers responsible for that prompt?

The desktop environment is responsible for providing a corresponding agent.

[WhyNotHugo]

@eliasp Also, not a fan of having to run a second daemon for the opensnitch UI to work (my desktop doesn't have any such agent).

@evilsocket I just wanted to really confirm that we didn't have a better alternative to what we picked. :)

[n1nj4sec]

something like that ? https://github.com/subgraph/fw-daemon

[boramalper]

Hey! I'd love to know how did you solve the problem of a malicious application communicating with the daemon (and accepting every package). Thanks!

[evilsocket]

I did not, the software is simply not done to cover that scenario, if the machine is already compromised, a process running with the same privilege of the UI can just hijack it / kill it / you name it ... this is partially solved by the daemon having its rules indipendently and running as root, but for connections that do not match any of those rules, it'd have to ask the UI or, if the UI service is not running, it'd just allow that connection by default.

[boramalper]

The solution would be to start both the daemon and the GUI from a common program that

1. Generates a password that the daemon will use to authenticate the GUI
2. fork()-exec()s to start the daemon and the GUI
3. The GUI will drop the root privileges immediately
4. The GUI will authenticate itself using the shared password (either in every message, or simply at the very beginning if it's connection oriented)

Or, much better, instead of creating a parent starter (as described above), you can simply signal[0] the daemon to fork & exec the GUI, in a similar fashion. This would also allow the daemon to launch interactive prompts (like LittleSnitch).

Hope you'd find this useful. =)

[0]: Either through D-Bus, UNIX signals, a TCP server... whatever suits you best.