-
-
Notifications
You must be signed in to change notification settings - Fork 492
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
OpenSnitch lies about what rule caused packets to be approved #1140
Comments
Hi @redanaheim , Some questions/suggestions: Could you change the LogLevel to DEBUG, reproduce it and post the logs? By the way, silly question, but the daemon you're running is without modifications, right? compiled from latest sources. I've tried to reproduce it but it works as expected. ("lying" is maybe a strong word here :) opensnitch is not doing this on purpose, so if anything, it's not reporting the rule correctly, or allowing something that shouldn't.) |
Yes. Here's the log file:
The bug occurs with any application whatsoever (you can see some others in the log). I did test it with those, however, and the same thing occurs.
It was before, but I disabled it and the same issue occurs.
Done.
I realized it was not before, but I rebuilt from latest sources and the issue still appears the exact same way.
I will try to get a minimal NixOS VM going to reproduce the issue. |
@gustavo-iniguez-goya : I created a minimal vm that reproduces the issue. https://github.com/redanaheim/opensnitch_nixos_vm If you want to see for yourself:
|
Also, if qemu aarch64 is too slow, you should be able to just find and replace with x86_64 to build the exact same VM for x86_64. Nix is awesome! |
thank you @redanaheim , I've reproduced the issue. Did you create the rule from the GUI or manually? On the one hand, the vscodium_openvsx.json's "created" field is invalid, instead of a timestamp the expected value is a date, for example: "2024-05-30T01:18:24.270461895+02:00" . The rule fails to load: "Error parsing rule..." Take a look at this example: https://github.com/evilsocket/opensnitch/wiki/Rules#format On the other hand, the "data" field containing the plain json is only meant to be used as a temporary value between the daemon and the GUI. When the daemon receives a rule from the GUI, it expands that flat json to a structured json, but when loading a rule it doesn't parse that field. This behaviour was changed on v1.7.0 here b930510 , but it has not been ported to v1.6.x. So you have 2 options:
"operator": {
"operand": "list",
"data": "[{\"type\": \"simple\", \"operand\": \"process.path\", \"data\": \"/nix/store/iy0wwrvrysml9x8m916dnnrlzg0w62ha-vscodium-1.88.1.24104/lib/vscode/codium\", \"sensitive\": false}, {\"type\": \"simple\", \"operand\": \"dest.host\", \"data\": \"open-vsx.org\", \"sensitive\": false}]",
"type": "list",
"list": [
{
"operand": "process.path",
"data": "/nix/store/iy0wwrvrysml9x8m916dnnrlzg0w62ha-vscodium-1.88.1.24104/lib/vscode/codium",
"type": "simple",
"list": null,
"sensitive": false
},
{
"operand": "dest.host",
"data": "open-vsx.org",
"type": "simple",
"list": null,
"sensitive": false
}
],
"sensitive": false
}, |
@gustavo-iniguez-goya thanks! The rules are generated into the rules directory by nix expressions so I can easily modify them to include the additional structured JSON field. However, I still think the behavior here is issue-worthy. Presumably when a rule fails to parse, it should not behave this way and instead should not use the rule at all, right? Also, is there any reason why the client is designed to create the data field instead of creating the structured form directly? If there is, maybe additional documentation explaining how that works is a good idea, because the reason I had Nix generate the data field that way is because (iirc) copying the rule to clipboard yielded that form for list operators, so it's a little confusing that it doesn't work if you copy what the client gives you directly. I could PR that if you wanted. |
Oh wait, I now see the commit and issue addressing the string thing. Ignore that part of my comment since it's fixed. |
Yeah, if the rule fails to load then it's not added to the list of rules. It's not used. However if the "created" field is formatted correctly, but the rule has no Operators, then the rule is an empty rule. From the GUI you can't create a rule without Operators, but for the daemon is a valid rule. I opted for this behaviour a long time ago on purpose, if I remember correctly, to avoid "empty" rules created by accident. But there's more. The confusing behaviour is (v1.7.0):
On the other hand, the option "Export to clipboard" writes a generic datetime, which json.Unmarshall() doesn't validate (because the reason explained above). I'll push a fix for the latter, and I think I'll export the rules always as RFC3339, instead of timestamp.
|
We were not formatting the "created" date field properly. More info: #1140 (comment)
very dramatic title, much wow. |
We were not formatting the "created" date field properly. More info: #1140 (comment) (cherry picked from commit b096e66)
When exporting rules from the GUI, the Created field was exported as timestamp. Importing rules worked fine, because json.Marshall() accepts the timestamp format. However, when the daemon was loading a rule with the Created field as timestamp, since the field was defined as time.Time, it expected a RFC3339 string (https://pkg.go.dev/time#Time.UnmarshalJSON) so it failed to parse the timestamp and the rule was not loaded. Now the field is defined as string, it's always saved as RFC3339, and if we fail to parse these fields we'll use a temporary date instead of failing loading the rule. More info: #1140 (comment) (cherry picked from commit 58aa979)
Describe the bug
The OpenSnitch UI statistics panel is lying about what rule caused connections to be allowed.
This also has the catastrophic effect that nothing at all is blocked or prompted.
Steps to reproduce the behavior:
NixOS module:
That is,
InterceptUnknown
as true,ProcMonitorMethod
as"proc"
, and everything else set to the default.Also, place the following set of rules in /var/lib/opensnitch/rules to replicate the rules generated by Nix:
(directly exported from OpenSnitch)
vscodium_openvsx.json
vscodium_github.json
systemd-timesyncd_all.json
systemd-resolved_all.json
openvpn_all.json
mullvad_all.json
git-remote-http_github.json
firefox_all.json
evolution-data-server_umich-instructure.json
evolution-data-server_google-calendar.json
dhcpcd_all.json
avahi-daemon_all.json
Start the OpenSnitch daemon and UI.
Turn off all VPNs.
ping google.com
. Notice that instead of prompting you to allow or deny the connection, OpenSnitch allows it and for some reason attributes it to the last alphabetical rule,vscodium_openvsx
.Expected behavior (optional)
OpenSnitch prompts me to allow or deny the connection or correctly labels it according to a rule that actually applies.
Screenshots
Attached below:
The text was updated successfully, but these errors were encountered: