For some reason, the udevd rule is run for lo and eth0 but not for wlan0 even though its driver is loaded, so this is WIP.

I don't have a Labeled IPSec, CIPSO or CALIPSO setup to test this with but maybe they would not benefit from interface specific rules anyway, because it's not possible to specify the interface for netlabelctl [map|cipso|calipso]. Perhaps map should allow binding rules to interfaces in addition to or in place of address:<ADDR>[/MASK].

I tested a bit by removing and inserting a module and it seems that the rules are applied.

But one finding is that the current syntax for /etc/netlabel.rules does not cover well the case where the name of the interface changes (for example wlan0 -> wlan1 due to module reinsertion). For that the syntax should allow for example pattern match capabilities (wlan* or wlan.*). This probably does not apply to persistent naming scheme (enp0s1). I suppose that in organizational setting it would be also desirable to blacklist some interface types, like USB network dongles and while this would also benefit from simple pattern matching, a more robust method would be to classify interface types by their bus and other characteristics of the network interface. Perhaps udevd rules should be used for that, also systemd-networkd has some matching features.

Also for my setup, a simple set of rules which just use DEFAULT catch-all seems to work better than this dynamic method considering the above.

Another issue is that (at least in my setup) the netlabel rules should be complemented with similar per-interface type rules, installed by semanage interface -a -t type. These rules aren't installed automatically either, failure to do so breaks network access and there's no catch-all rule. This is a separate issue for other tools though.

Hi @topimiettinen, thank you very much for working on this! My udev knowledge is pretty weak, so I appreciate the help.

On just a quick look the diff looks reasonable, but I'm a little concerned about the "wlan0" problem; does that still remain an unexplained issue?

But one finding is that the current syntax for /etc/netlabel.rules does not cover well the case where the name of the interface changes (for example wlan0 -> wlan1 due to module reinsertion) ...

Perhaps a good first step is to simply make sure everything works without wildcards/regex/etc. and we can see additional matching people want.

Another issue is that (at least in my setup) the netlabel rules should be complemented with similar per-interface type rules, installed by semanage interface -a -t type ...

Agreed, that is a separate tool issue. It may be that better integration with the various different network management tools is ultimately the best way to solve this. I'm really not sure at this point.

On just a quick look the diff looks reasonable, but I'm a little concerned about the "wlan0" problem; does that still remain an unexplained issue?

Udev calls netlabel-config correctly but there seems to be unrelated issues on how the interfaces are managed on my system. Some interfaces are also renamed by systemd-networkd, and if this happens while netlabelctl is managing the interface, it can fail. Maybe systemd-udevd or systemd-networkd should avoid this situation or perhaps it's not OK to do this kind of setup via udev. I'll have to dive deeper.

There's another problem that there's no locking and the reset functions are not atomic. They read current status as a list and then loop over it to perform resets. Meanwhile another instance of netlabel-config could be started by udevd and this could race to add some configuration faster, only to be deleted by the reset loop later. I think this can happen when there is a udev remove event followed rapidly by an add event and indeed in the logs show this for wlan0. Though the timestamps are separated by 1.1 seconds, which should be plenty even for shell.

Thanks @topimiettinen for looking into this; I see you've also posted on a similar issue to the SELinux list:

• https://lore.kernel.org/selinux/06f4b748-470d-8774-ffbb-5e342f6fcba8@gmail.com

Yes, if the issue is more general, perhaps there could be also more general solutions, like kernel changes, or changes to multiple tools which may require some coordination.

Reopening as this was unfortunately closed when I changed the default branch to "main".

Reopening as this was unfortunately closed when I changed the default branch to "main".

... and that failed as the "master" branch was deleted.

I'm sorry @topimiettinen, I didn't mean to kill your PR. However, based on the discussions on the SELinux mailing list I think this PR is not likely to go much further, yes?

No problem. I haven't found any good solution yet. I'd prefer something where the TE rules don't need updating on every change and Netlabel (also Netfilter SECMARK) rules would be great in this regard, but let's see what solutions there could be.

Okay, thanks.