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

[tidux]

Running an X application as root destroys any shred of security the Linux desktop might otherwise have. A root-privileged daemon and an unprivileged user interface talking across a Unix socket or some other form of IPC would be far more reasonable for a security application.

[voltagex]

Isn't this pretty much what Polkit is for?

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

[hobarrera]

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

[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?

[hobarrera]

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.

[hobarrera]

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

[hobarrera]

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

[evilsocket]

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

[hobarrera]

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

[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 :)

[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.

[hobarrera]

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?

[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]

@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]

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

[hobarrera]

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.

[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]

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

[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]

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

[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.

[hobarrera]

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?

[hobarrera]

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.

[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.

[hobarrera]

@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