An alternative that does not come with a potentially machine-bricking kernel panic bug is Opensnitch [1], last updated 14 months ago with a change to "funding.yaml" asking for donations.
A fork seems to be relatively alive [2] and I use it personally -- it works well, but is a bit of a PITA to build. Time to buy the devs a coffee...
I wouldn't call a kernel panic bug "machine-bricking", since after the panic happens, your system is usable again upon reboot. "Bricking" implies that wouldn't be the case.
I second that fork [2]. It is very actively developed and it's already a huge improvement over the original project. But why do you have to build it? It has rpm and deb packages readily available.
Privacy tooling should not come from a page that does not work without javascript. Moreover, this functionality is easy to achieve using user groups and the iptables owner module.
Here's an example that prevents atom from leaking telemetry.
# add group atomblind
sudo groupadd atomblind
# add your username to atomblind group
sudo usermod -a -G atomblind <username>
# do not allow outbound traffic from group atomblind
sudo iptables -I OUTPUT -m owner --gid-owner atomblind -j DROP
# overwrite atom binary with a hook
# atom_binary is absolute path to your atom binary
echo "#!/bin/bash" > atom_hook
echo "sg atomblind -c 'atom_binary'" >> atom_hook
chmod +x atom_hook
./atom_hook
An overlooked feature of opensnitch is that the packet filter can run on a gateway (say, OpenWRT) and the GUI on any station. That’s something I’m missing with little snitch.
I still think the new (since Catalina) macOS per-app, per-directory permissions is critical to avoid being vulnerable to ransomware. Not everything that runs as my uid should have access to everything my posix permissions allow, especially ~/Documents and such.
Dockerizing every GUI app I run is going to be a pain, otherwise.
For Linux, there's Flatseal for all Flatpak apps. Easy and simple GUI that allows you to set permissions for individual apps including network access, microphone/camera access and directories access.
It'd be nice to have both. But with Big Sur crippling Little Snitch, like rdn, I too am looking to bail from Apple. One can be selective in the apps one chooses to install, but one can no longer block Apple's telemetry and cloud stuff. Pity. I've been Apple-only since the Apple IIgs.
That first link is gold! The second one is bad because you can't disable the signed system (readonly) root without disabling FileVault and leaving it disabled, which is a showstopper for me.
Will 4.x be installable on ARM? I imagine the kernel extension needs to match the arch of the kernel, and because ARM macs don't run anything before Big Sur, I imagine only 5.x has ARM builds available?
Sort of. By default, most SELinux systems have users logged in as `unconfined_u`, which as the name implies receives nearly no confinement.
Any application that doesn't have a specific policy written for it will either inherit the domain that spawned it (in this case, `unconfined_u:unconfined_r:unconfined_t:s0:c0.c1023`) or receive some default domain (e.g., `system_u:system_r:unconfined_service_t` for systemd services, `initrc_t` for init daemons, etc.)
Because of this, most applications will end up inheriting the user's domain, which again is `unconfined_t` by default under the targeted policy.
Lots of common applications have policies so that they transition to their own domain and then execute under customized policy, but it's less common for user applications (and especially user applications that are not system tools) than for daemons so it's not generally safe to assume you're protected by selinux when going about typical user tasks.
However, writing SELinux policy isn't that hard (although it's a bit harder than just `audit2allow` to do it well) and it's a perfectly reasonable project for an afternoon to write a policy for an unconfined application you use, if you're willing to spend some time up front learning about SELinux policy language.
You can disable the unconfined_u user though, it's just stricter then the normal "targeted" policy which is common today. What I'm saying is we don't need a new technology here, we actually have the technology we just need to deploy it properly.
SELinux provides all the tools we need to implement the guarantees, just Linux distros don't currently have a stance on how they want to expose such a policy option.
<untrusted data from the netlink socket>
append_rule(activity->process_path, (activity->allowed == 1));
...
append_rule:
// Don't do anything if the process_path length is > PATH_LENGTH
if (strlen(process_path) > PATH_LENGTH)
return;
But nobody enforces the process_path has a terminating 0 byte, so likely it can be abused for all kinds of attacks on the kernel. Better don't run it anywhere you care about security.
I found this from about 2 minutes code reading, so likely there wasn't any code audit done ever.
The same reason that all new C projects aren’t being written in rust.
There is a lot of expertise floating around in the ~30ish years of netfilter so that is a ton of momentum in terms of the personal expertise of more experienced devs as well as the blogs/tutorials available when you search for “network filtering Linux”.
The default of kubernetes is still huge iptables chains and the only realistic ebpf alternative is mainly driven by a currently unsustainable startup (Cilium). The maturity just isn’t there yet.
Right!? That's the first thing I looked for in the project page. I'm really surprised it isn't using ebpf, but netfilter and a kernel module let them run back on 2.4 (but why?) I'm waiting for a bpf based solution to pop up as I think it will be superior in performance, ability, and maintainability.
if you have a huge size of iptables list yes bpf is important, bpf is more for performance reasons otherwise iptables suits the need just fine, in this case of personal firewall, iptables shall be good(and simple) enough
Do I get it correctly that the only reason for the kernel module is to be able to show GUI popup live when an app accesses the network for the first time? Because otherwise I believe it's easier to mark the packets with selinux and then filter them with netfilter.
> For us mortals, SELinux is a synonym for "complicated, scary thing that I don't know how to use properly".
This is true, but I was referring more to the underlying architecture of Douane: kernel module + daemon + dialog UI + configurator app. Is a kernel module less scary for mere mortals? Because the downsides of that path are stated in the banner on the main page which says about kernel panic.
> Can you link to something with minimal working "mark and block" examples?
I'm not aware of any myself, but like I said, I was mostly referring to implementation. I also don't quite get the threat/defense model here. It looks like the idea is to replicate something similar to iOS/Androind permissions ("do you allow this app to access the camera?") but for network this seems to be a bit weird. Making such decision for each application would be quite annoying, so you'd like like to have some defaults in this regard, which again is easier solved by two predefined selinux contexts (with/without networking) and some UI for the user to move apps between them.
But then again, if we decide not to ask for confirmation for each app at exactly the first moment it tries to access the network, we have access to a variety of tools to provide access control to the network. For example, we could use separate network namespaces for different processes, some of which wouldn't have access to networking. This has additional benefit of fine-grained control: "allow chrome to only access my.secure.server.com on port 433".
In fact, it goes beyond that: we can have different routing tables per app, we can setup traffic shaping between the apps ("put traffic from qBittorrent into low-priority queue"), we can bridge and mirror the traffic from an app, etc. This is for example what firejail does [1] and it has a UI as well [2]. This doesn't require any kernel modules or even selinux policies and doesn't bug the user 10 times a day.
Yeah, network namespaces are I think the best way to go. You can do so, so many things with netns, the abstraction is quite nice. BTW I think setns works on /threads/ if you wish. Not as secure but allows some interesting things.
And if you need to do real-time, specific packet validation, interface state, route change, just go full netlink. Not sure why more in-kernel code might help. There's already so much stuff available. Not often well documented but so much powerful stuff!
Recently I wanted better control over bonds, and I discovered teams. How the hell did I not find them when I was looking for ways to control bonds from userland. And when I wanted bonds in network namespaces...
Here's a short article on it by Dan "Mr. SELinux" Walsh himself [1].
To understand it, though, you need to understand at least a little bit about type enforcement, which is a somewhat steep learning curve to get over.
If you have nftables (replaces iptables, default back-end to firewalld in RHEL 8), you might consult /usr/share/doc/nftables/examples/secmark.nft but again, this requires some background on nftables (or iptables—they're both just front-ends to the kernel netfilter module) and are pretty similar.
However it's also worth noting that most one could also stand to learn a thing or two about netfilter if this is a topic they're interested in. For example, netfilter allows you to filter packets based on the user, group, or pid of the process.
I found this page [2] quite helpful, and especially the packet flow diagram contained within it.
User, group and pid of the process are available through iptables. Really a great, simple way (in addition to other stuff) to compartmentalize complex applications. Shame it doesn't cross machine boundaries :-) (I know it's stupid but I like the simple user+group abstraction.
Yeah, I'm not sure if it's clear but the iptables family and its replacement, nftables, are what I'm referring to when I say netfilter. iptables/nftables are userspace applications and netfilter is the underlying kernel module.
Sorry, of course. I meant the 'iptables' interface to netfilter can be enough for mere mortals that only use them once a year, and can filter on uid/gid/pid.
I'd like to find a real-world project to play with netfilter directly. Maybe when transitioning to 200GbE... Is it just for 'complex and numerous filtering rules' or are there other 'killer use cases' for using nftables directly?
My understanding is that nftables and iptables+ip6tables+arptables+ebtables are for exactly the same set of use cases, with the latter being deprecated in favor of the former as the new replacement.
RHEL 8 uses the nftables back end for firewalld by default.
The main difference that I have noticed is that writing configuration files for nftables is considerably more ergonomic than the iptables files which are essentially just unstructured lists of iptables commands.
Generally things like UFW or firewalld are sufficient for host firewalls, but they fall short for routing applications where it is more appropriate to use nftables (or historically, iptables) directly.
Kubernetes and docker both currently use iptables for their routing and will likely migrate to nftables. If/then those projects migrate to nftables I suspect it would also solve the issue where docker port mappings have the ability to unilaterally punch holes in host firewalls, e.g., UFW, because under nftables, tables are just namespaces for chains (with configurable priority) while on iptables the different tables meant specific things and docker made decisions in a branch off of the PREROUTING chain in the nat table, which was encountered before the FORWARD or INPUT chains on the filter table. In this way nftables makes certain expressions more ergonomic than iptables.
The underlying netfilter has not been deprecated; the userspace application for managing it is just changing from the iptables (and ip6tables, ebtables, arptables, etc.) to nftables.
A fork seems to be relatively alive [2] and I use it personally -- it works well, but is a bit of a PITA to build. Time to buy the devs a coffee...
[1] https://github.com/evilsocket/opensnitch [2] https://github.com/gustavo-iniguez-goya/opensnitch