Do not use root (even for daemon)

[adisbladis]

We can use the amazing Linux feature capabilities!

The only tricky bit is that the iptables CLI command is being called so ambient capabilities would have to be used. Currently opensnitch would have to use:

1. cap_dac_override (to enable ftrace via sysfs)
2. cap_net_admin (nfqueue, iptables)

Obviously this is blocked by #20 since without this you would have to set the capabilites for the Python interpreter.

[evilsocket]

Mmmm interesting, I know about linux caps but never used them honestly (i know i know, shame on me :D) ... so ideally we would just give such caps to the process and run it as a separate user?

[adisbladis]

Yes exactly like that. Running with the bare minimum of privileges to do what we need.

[eliasp]

IMHO iptables shouldn't be used, but opensnitchd should communicate with the Kernel through netlink instead. iptables is just an interface to the Kernel's packet filtering facilities, just in the same way opensnitchd will be.

When using iptables:

• every action has to be translated into an iptables command
• the execution of iptables involves a lot of context-switching
• complicates privilege separation/isolation
• execution of commands needs to be hardened against command injection
• using iptables is a one-way street

When using the Kernel's netlink interface:

• far more fine-grained control over actions
• make use of the nftables framework instead of the outdated netfilter framework
• place rules/hooks in the nftables Lua VM which act as a callback to opensnitchd to notify about events or trigger actions which require user-interactivity

The netfilter project also provides libraries to interact with the Kernel.

[evilsocket]

Any doc. on how to interact from python with netlink?

[eliasp]

There are a few Python netlink libraries, haven't worked with any of them, so I can't really tell how well they'd cover the required functionality, how well they're maintained, etc.

• https://github.com/facebook/gnlpy
• https://github.com/Robpol86/libnl
• http://docs.pyroute2.org/

[strazzere]

Agreed with @eliasp that having a userland daemon communicate with a kernel would be best. This is actually how LittleSnitch operates on osx, userland daemon connects to a kext that catching all outgoing sockets. This allows you to catch /everything/ from your user and others, while alerting and allowed the current user to decide an action to take.

I've not personally used netlink, so I cannot speak to that - though I was going to suggest using an LKM or some existing functionality for this or a netlink filter based approach -- since this would replicate the functionality a bit closer to LittleSnitch.

Sorry if this seems a bit tangental - I was trying to skim related issues rather than creating a new one which was just this suggestion.

[adisbladis]

Since https://github.com/evilsocket/opensnitch/pull/83 is merged this one is resolved.

[msva]

@adisbladis I'm not sure that using python-iptables is fully "resolves" this issue.

For example, I'd very like to see opensnitch to really directly talk with netfilter interface, but not the libraries from (still) deprecated iptables package.

This would help, as already said, to avoid multiple rules "translation" between subsystems (iptables uses a wrapper-subsystem on top of netfilter, that translates all the calls between native netfilter dialect and "old" iptables dialect), and many kernel context switches, which, in turn, would produce a dramatically high performance boost.