🔐 Security RFC: Hardening the Local Service

[stepmikhaylov]

Hey Everyone,

I'd like to open a discussion about strengthening the security posture of our local backend service. As our extension is expected to grows in adoption, I think it's the right time to be proactive here — especially since we're an open-source startup where trust is earned, not assumed.

🚨 Current Concerns

1. Running as root / administrator
   The backend currently runs with elevated privileges. This is a significant attack surface — if anything in the process is compromised, the attacker inherits full system access.
2. Mixed executable types (binaries, JARs, Python scripts)
   Unlike compiled binaries, Java libs and Python scripts are human-readable and trivially modifiable. A malicious actor — or a subtle supply chain injection — could tamper with them without obvious detection.
3. Open-source CI/CD supply chain risk
   We welcome community contributions, which is great — but our CI/CD pipeline may not catch every subtle malicious injection. This is a known and serious risk pattern.
4. Trust baseline
   We're not a large, established vendor with a long security track record. Our users are trusting us by installing and running a local service, and we owe them a hardened-by-default setup.

✅ Proposed Mitigations

Security issues present a vast array of approaches and solutions, but I would like to highlight the points which I believe should be prioritised:

1. Dedicated least-privilege service account
   Run the backend under a dedicated system account (e.g., 'rocketride-svc') auto-created at install time, with minimal filesystem and network permissions. No login shell, no sudo rights.
2. Filesystem sandboxing
   Restrict the service account's read/write access to only the directories it genuinely needs. Use OS-level controls: systemd service hardening on Linux (ProtectSystem=strict, PrivateTmp=true, etc.), macOS sandbox profiles, or Windows restricted service accounts with ACLs.
3. File integrity verification
   Ship and verify checksums (e.g., SHA-256) for all distributed artifacts — especially JARs and Python scripts — at startup. Alert or refuse to run if verification fails. Consider code-signing for binaries on all three platforms.

🤔 Marketing?

Not my area — open to pushback 😄 But one angle I believe has potential value: security transparency as a feature, not just a chore.
A lot of developer tools — especially lesser-known ones — get quietly dropped by teams or individuals the moment someone asks "wait, what does this thing actually run on my machine?" Having a clear, public answer to that question could be a genuine differentiator.

---

I'd love to hear comment, additions or pushback. Thanks 🙏