[Bug Report] Inconsistent behavior for symlinked binaries between different ProcMonitorMethod

[LordGrimmauld]

Different definitions for ProcMonitorMethod treat symlinked binaries differently, causing non-obvious silent test failures on v1.7.0.0 update. eBPF backend treats binaries by their symlink path, while all other monitor methods treat binaries by their real absolute location.

Describe the bug:

Include the following information:

• OpenSnitch version: v1.7.0.0
• OS: NixOS
• OS version: 25.05, unstable (2025-06-03), repo hash: 308837b8e6393f121d0889a7e417d13072c33461
• Window Manager: None, headless VM test
• Kernel version: 6.12.30

To Reproduce:

Steps to reproduce the behavior:

1. Create a rule for an absolute binary path
2. Create a symlink to that binary
3. Load opensnitch and execute the symlinked binary from its symlink path
4. On eBPF ProcMonitorMethod: Rule does not attach. On all other ProcMonitorMethods: Rule applies.

This can also be reproduced in the VM test that is part of our NixOS CI.

The rule here is being created by absolute path in /nix/store/<curl-package>/bin/curl:
https://github.com/NixOS/nixpkgs/blob/7668dddecbe7732a86cacae2510b6d2ef6c710fa/nixos/tests/opensnitch.nix#L59

But the test executes curl by $PATH, which is a symlink in /run/current-system/sw/bin/curl:
https://github.com/NixOS/nixpkgs/blob/7668dddecbe7732a86cacae2510b6d2ef6c710fa/nixos/tests/opensnitch.nix#L80

Post error logs:

Not an error, but can provide debug logs if they are actually any useful.

Expected behavior (optional):

Rules should have consistent behavior between different monitoring methods. While arguably the new behavior can be useful for more granular control, it is an undocumented departure from 1.6.x behavior and inconsistent with the other monitor methods.

Ideally, old behavior could be restored.

Additional context:

Discovered during the v1.7.0.0 update in nixpkgs: NixOS/nixpkgs#412616
I had opened a discussion (#1356) before finally finally finding the issue. Probably a side effect of the cilium switch.

[gustavo-iniguez-goya]

I've just tested it and I think you're right, v1.6.x reports the cmdline + the real path, while v1.7.x only the cmdline. If the cmdline is a symlink we're not obtaining the real path of the binary.

I'll review it.

[LordGrimmauld]

With NixOS/nixpkgs@f394a43 the nixos VM tests do pass. But, arguably, the behavior is still inconsistent and should be fixed upstream, instead of just not testing the wonky behavior.

[egrieco]

I've just tested it and I think you're right, v1.6.x reports the cmdline + the real path, while v1.7.x only the cmdline. If the cmdline is a symlink we're not obtaining the real path of the binary.

Definitely keep the ability to set rules based off of the symlink. I've been having to re-create rules every time I update NixOS since the real paths to the executables include a hash based partially off config and dependencies in NixOS.

[gustavo-iniguez-goya]

@LordGrimmauld , I think this issue is fixed. Test it and let me know please if it's fixed or there're any other inconsistency.

In any case, this behaviour will change in the (near) future. Depending on what kernel function we hook, the absolute path of a binary may differ from what the user types or what's written to /proc.

[LordGrimmauld]

Depending on what kernel function we hook, the absolute path of a binary may differ from what the user types or what's written to /proc.

This is problematic. Part of the point is to not have programs make connections without the user asking. If a program can escape confinement by creating a symlink and then just spawning that, that defeats half of the point. Commonly, mandatory access controls (such as apparmor, with which i am quite familiar) usually match absolute paths for exactly that reason: It makes escaping harder.

[LordGrimmauld]

Anyways, thank you for taking care of this! I fetched the patch in NixOS/nixpkgs@ee9b4c7, and the VM test for eBPF backend now went green without further complaint. Good to see symlinks supported again :)