Replies: 3 comments 2 replies
-
|
I'm totally in favor of this direction. If Roxy operates as a standalone server in the above manner, it would be better to prepare for emergencies since we can clearly control who accesses it and log the situation. |
Beta Was this translation helpful? Give feedback.
-
|
I just got around to reading this. I’m glad to hear that Roxy is evolving into a better daemon. I’m looking forward to the new version! |
Beta Was this translation helpful? Give feedback.
-
|
I want to double-check the scope around the helper library. When we move to |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
First off,
roxyhas served us well. It was the right solution to a pressing problem, allowing our agents to manage system settings when they needed to.As our ecosystem has grown, with more agents being deployed (sometimes several on a single machine), I think we've reached a natural point to reconsider Roxy's role and architecture for the long term. The current
setuidproxy model, while effective, means that every agent that calls it carries a degree of system-level responsibility.I'd like to propose that we evolve Roxy into a full-fledged, independent agent. Instead of a
setuidbinary that other processes call directly, Roxy would run as its own standalone daemon (e.g., a systemd service). The other agents on the machine would no longer have any direct system-control capabilities. The Roxy agent would be the only component on the system with the privileges to modify system configurations.Why I Believe This is the Right Direction:
Improved Security: This change would allow us to strictly adhere to the Principle of Least Privilege. Our other agents would run as simple, unprivileged users, unable to communicate with Roxy. This dramatically reduces the overall attack surface of our platform. We could focus all our security hardening and auditing efforts on this one, single agent, rather than on every agent that might need to call it.
Cleaner Architecture & Separation of Concerns: This move would decouple system management from the primary responsibilities of our other agents. Each agent could focus purely on its own domain (e.g., data collection, log shipping), making them simpler, lighter, and easier to develop and maintain.
What are your thoughts on this approach? I'm looking forward to hearing what everyone thinks.
Beta Was this translation helpful? Give feedback.
All reactions