Replies: 1 comment 1 reply
-
|
Hi @Quant-ux , It's not a bad idea, we have recently discussed about this feature but for other purposes: allow multiple users to view the GUI. So we could have some kind of users roles, authentication, etc. (i.e.: if user is not authenticated, don't allow changing daemon settings, etc). Recently I added an option to secure the communications with the daemon, that should partially solve this problem: without a client certificate you won't be able to connect (12b4cf3) and communications are ciphered. I need to adjust it to work for unix sockets too. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for taking the time to reply. I'm glad to read there are undergoing efforts to address the concern I'd raised in my proposal. I didn't expect a positive response but then again, I don't closely follow the project—let alone participate in its development. As for 12b4cf3, like you said, it only partially emulates the proposed mode of operation. On this account, I look forward to seeing further progress on this front. |
Beta Was this translation helpful? Give feedback.
-
I'm looking for ways to secure my desktop. So, when I'd found out about Opensnitch, I'd installed it and have been happily using it for some time. However, it was recently brought to my attention that any user-owned process can talk to the daemon via the same socket the GUI uses and therefore be able to do everything I can do. Now, I'm not a security researcher and, for this reason alone, this may not be as bad as I'm making it out to be but the way I see it, given that Opensnitch enables to carry out administrative, networking-related tasks that normally require elevated privileges—such as system firewall configuration—I'm concerned about the lack of stricter socket authentication and authorization. If I remember correctly, this had been brought up in the issue tracker before so I won't reiterate the same points that might've already been made, but—however you look at it—I can imagine the amount of work it would take to adequately tackle this from the security standpoint; therefore, I'd like to propose a simple solution for those of us with a finalized firewall rule set—a daemon configuration option dubbed "read-only mode" that controls whether the GUI can be used to modify rules or to only view them. Notifications with recently performed block actions would still be delivered, the user would be able to view events, active rules, etc. but they wouldn't be able to make any changes.
Depending on whom you ask, this idea could provide little value to the project. Moreover, I could've missed something that makes it impractical to implement, but nonetheless, I'd like to see it happen in the future.
Beta Was this translation helpful? Give feedback.
All reactions