Freeze on xfce4-startup

[christianhauff]

I am running opensnitch on manjaro with xfce4, and in the past it has been working without a problem. One day when booting my system, I entered my password on the login screen of xfce, my desktop background appears and then nothing happens anymore, no matter how long you wait.

I bootet into a live-system, entered chroot and studied the logs. Unfortunately, that's a few months ago, and I can't tell anymore what led me to assume that opensnitchd is responsible, but I disabled the systemctl-service for it and after that, my xfce started without any problems.

Since then, I always started the opensnitchd-service manually on every startup (with sudo systemctl start opensnitchd.service) and that was running without any issues, when I tried enabeling it on startup again today, the issue occured again, service enabled on startup -> xfce freezes after login, live system, chroot, disable service, reboot -> everything works again.

In my journalctl is nothing but the Starting opensnitch-daemon v1.5.8 and Loading rules from /etc/opensnitchd/rules ...

There is nothing of interest in /var/log/opensnitchd.log either

2023-07-05 06:11:20 Start writing logs to /var/log/opensnitchd.log
2023-07-05 06:11:20 fw configuration loaded
2023-07-05 06:11:20 Using iptables firewall
2023-07-05 06:11:20 Running on netfilter queue #0 ...

I am running Manjaro Linux with xfce4, Kernel Version 6.1.31-2-MANJARO (I changed the kernel since the problem initially occured and it is still present).

Steps to reproduce the behavior:

1. sudo systemctl enable opensnitchd.service
2. reboot
3. Enter Password on Login screen -> Desktop Background appears -> nothing happens anymore

Maybe anyone has an idea on how to debug that issue

[gustavo-iniguez-goya]

Hi @christianhauff ,

This issue will be probably caused by localhost connections being blocked. Could you save the following rule under /etc/opensnitchd/rules/000-allow-localhost.json and see if that's solves the problem?

{
  "created": "2023-07-05T10:46:47.904024069+01:00",
  "updated": "2023-07-05T10:46:47.921828104+01:00",
  "name": "000-aallow-localhost",
  "enabled": true,
  "precedence": true,
  "action": "allow",
  "duration": "always",
  "operator": {
    "type": "regexp",
    "operand": "dest.ip",
    "sensitive": false,
    "data": "^(127\\.0\\.0\\.1|::1)$",
    "list": []
  }
}

[christianhauff]

Thank you, that solved it!

There was an allow-event logged now, /usr/bin/xbrlapi (which has something to do with X11) accessed Port 4101 on localhost, that was it. I'll probably restrict your rule a bit more as soon as I'm sure that no other port is needed by that process, but your hint helped a lot!

[gustavo-iniguez-goya]

I'll probably restrict your rule a bit more as soon as I'm sure that no other port is needed by that process,

that's a wise decision :)

There're certain binaries that communicate in localhost: xbrlapi, dirmngr, kwin, kdeinit5, and some others. Some are part of the Xorg/Desktop Environments and causes these issues.

We've been recently discussing if distributing by default a rule to allow localhost connections: #965

I think it's time to do it.

[christianhauff]

I guess there are also situations where you don't want a program to communicate with a specific localhost port, so allowing localhost in general is probably also not the best solution, but that's a discussion for the issue you referred to...