> 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...
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.
[1] https://firejail.wordpress.com/documentation-2/basic-usage/#... [2] https://github.com/netblue30/firetools