I have asked the Little Snitch development team at obdev about this issue. Here is the response:
In fact local traffic over AFP or SMB protocol is routed by the mach_kernel process on newer OS X systems.
It is defined as /mach_kernel on 10.10.x.
I'm on OS X 10.11.4 here, where the process path is now /System/Library/Kernels/kernel
Unfortunately it can not be treated the same way as other processes, but usually your local network rules should cover all relevant connections for it.
But I have to admit that I also remember a case where external connections are associated with the mach_kernel by mistake and it seems to happen when the tables in the Little Snitch Network Monitor cache got mixed somehow.
Do you perhaps experience such external connections associated with the mach_kernel process?
Possibly thats an issue of memory - happening when your system (including the Little Snitch Network Monitor) is up running for quite some time… I already talked to our developers about that and we will keep an eye on that issue.
"the tables in Little Snitch Network Monitor cache got mixed somehow"? Seriously?
It does indeed seem to happen after my machine has been running for days or weeks without reboot. And a reboot will fix it temporarily. It is possible that this is simply a bug in Little Snitch.
However, I find it dubious that traffic routed over
mach_kernel "cannot be treated the same way as other processes". I am not informed about how Little Snitch is architected. It may not be able to run in kernel space (ring 0), but I find it terribly convenient in today's climate of mass government spying that the OSX kernel can simply take over and get around Little Snitch. I believe
IPTables would have no such trouble in blocking traffic, but it is most certainly of a different architecture and user model altogether.
See here for additional reference: https://security.stackexchange.com/questions/58815/do-firewalls-always-run-in-userspace
Switching to FOSS/Linux is looking more and more like the path to be on.