Future plans?

[ei8fdb]

I'm really impressed with Opensnitch so far. I've used Lil' Snitch for 5-6 years very happily. I've moved from OS X to Ubuntu and Debian fully a few weeks ago.

I'm curious what are the future plans for Opensnitch? I've been using it for a few days and so far so good.

It would be great to see future development. I'm interested in contributing.

Well done on a good start!

[MarkoShiva]

Guys are we still going on the cpp version of the daemon? #20 cause I see that as resolved? Are you happy with python speed? @evilsocket @adisbladis @ei8fdb the idea was to make it as fast and robust as it can be also user friendly.

[adisbladis]

@in1t3r I'm not happy with Python for this, anything creating lots of connections (like nmap for example) is noticably slowed down and using a ton of cpu. It was good for prototyping but I see us rewriting that portion of the code. The UI I still want to keep in Python :)

I'm leaning quite heavily towards go instead of cpp. It's memory safe, a joy to write code in and it has great libraries for what we want to do.

[evilsocket]

@adisbladis actually, one reason I didn't start the rewrite yet is because I wanted to use Go, but I was afraid I would have been the only one ok with that :D If you feel comfortable coding in Go as well, thus you will keep contributing, then I say I can start the reimplementation very soon :)

[adisbladis]

@evilsocket Go it is then =)

[arcrose]

Just chiming in here because I'm really interested in having a replacement for LittleSnitch on my Ubuntu machine.

Go seems like a reasonable choice here, but I would like to raise the question: what needs does the daemon need to solve? Are the strict memory requirements? Would we like to be able to safely do concurrency without any risk of race conditions occurring? I don't want to be that guy, but if "bare-metal performance" may be a strict requirement at some point, and Go's runtime could potentially get in the way of that, is it worth considering an alternative? I'm personally privy to both Go and Rust in particular, and could imagine either being perfectly valid choices.

For the sake of this conversation, I myself would just like to know a little more about the specific expectations for the daemon software.

[adisbladis]

@zsck These are the tasks the daemon needs to do:

• Filter connections
• Manage rules database
• Collect DNS responses
• Monitor processes

I wouldn't say there are strict memory requirements, after all the primary target is desktop machines where you presumable have things like browsers and DEs running that would make Opensnitch pale in comparison.

I'm actually fine with the current Python implementation in terms of memory usage and I can only see this getting better with Go. What's not fine right now is the CPU usage that becomes a bottleneck when you want to quickly open a lot of connections. I have not yet profiled this but my intuition tells me this is probably because of excessive object allocation and garbage collection.

I do see race conditions as a bit of a risk going forward but this is manageable.

[MarkoShiva]

Also there are couple more of issues with the python implementation. opensnitch-qt does not properly run as sudo or doesn't read a tmp file where the status information is located. So many times not just for an udp packets but for many others, for example any tcp connection made as root like a tor client or made toward the privoxy is labeled as unknown which mean it cannot get all of the parameters and the cli. Well as usual just like when you are running netstat if you are unpriviledged user you cannot see privileged user root or other system user command line and by that you don't have cl nor pid. I think that is something that need to be changed if no one else do it I will as soon as I pass through the code because I only gave it a glance look. I think that part of the logic in proc.py and procmon.py is wrong. ;) When its about other languages I do think that C++ or C would be better then Go maybe rust is a good choice too.

[evilsocket]

I think that part of the logic in proc.py and procmon.py is wrong.

Could you elaborate it please? If it's wrong, I'd love to fix it :D

[adisbladis]

@in1t3r The qt client is not reading any process information. It's just being passed that from the daemon.

I was just checking how psutil is getting this information and it's getting it from /proc. https://github.com/giampaolo/psutil/blob/master/psutil/_pslinux.py#L711

Currently this daemon is running as your own user which means it may or may not have access to certain things in /proc depending on the setup.

By default on Ubuntu o procfs pid directory has 555(read/execute) and a file has 444(read) which means that it should always be possible to show a process commandline and network connections.

Are you using the hidepid procfs mount option perhaps? If so you need to run opensnitchd with a gid that has access to all /proc entries.

[CoalaJoe]

Just wanted to ask how this project is going. I could help with a cpp rewrite in Qt, develop a modern website or create documentation.