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.

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.

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

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

[evilsocket]

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

[WhyNotHugo]

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.

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