Hacker News new | ask | show | jobs
Show HN: Bor – Open-source policy management for Linux desktops (getbor.dev)
56 points by eniac111 3 hours ago
Hi HN! I've been working on Bor, an open-source system for centralized Linux desktop management.

Bor consists of a lightweight Go agent and a central server. Policies are streamed to clients over mTLS/gRPC in real time—no polling—and currently support Firefox, Chrome, KDE, dconf, polkit and package management, with more coming.

Version 0.8 introduces several new policy types - Thunderbird, Microsoft Edge for Business and FirewallD zones, along with a number of improvements and fixes.

I'd love feedback on the architecture, policy model, and whether this is something you'd consider for managing Linux workstations.

5 comments

Can this be used to enforce “screen time” for laptops given to children, hopefully in a more effective way than the equivalent systems on iOS and Android?
Not directly. This might be somehow configured with PAM. It's a good use case, thanks for the idea!

It could easily block porn, enforcing DNS over HTTPS in the web browsers, using providers with adult content protection.

This looks really close to what I need. I manage a few laptops for a non-profit. For now, it is all done by hand, since I haven't found a good solution for Linux and I will kill myself before using Windows and Intune again.

I would love to see configurations for Linux Mint's Cinnamon. Is there a way to execute custom scripts? How does the user mapping work exactly? Could I create a user in Authentik with a laptop-permission and this would map to a Linux user account?

Nonetheless, this is really great work so far, and if you keep it as nice and tidy as it currently looks, then you might make a nice niche for yourself. I can't wait to try it out.

Unfortunately, only LDAP is currently supported. There is no implementation of Enterprise SSO like Oauth/SAML. It's planned for the future, but not in priority for now.

I have never tested Cinnamon, but it should work in theory, because it stores most of it's settings in dconf.

Custom scripts: deliberately not, so far. Once a management agent runs arbitrary scripts as root, it stops being a policy system and becomes remote-code-execution-as-a-service — the security review, the audit story, and the "what exactly is enforced on this machine?" It may be implemented in the future, but with a ENV variable/config property from the application configuration. The same goes for configuration management systems like Ansible.

Thank you for the interest! I'm interested in developing a community around the software.

Would ansible meet some or all of your needs?
This is cool. I’m getting into this type of management for the first time after being in software development for a long time. What other open source or enterprise solutions is this potentially competing with? What made you write your own, as in, what you weren’t able to do or didn’t like about existing solutions?
- Samba already supports policies for Linux, but it's not a "finished product", not actively maintained and it does not have Bor's tamper protection of the managed files. - IaC tools like Ansible/Puppet are good alternatives, but coding the whole configuration is not comfortable for some system administrations. Especially those with Windows Server AD background. Also, setting up strict policies avoids running of arbitrary code on the target systems, which is good for enterprise compliance certification. - It's not a domain controller because there are no user entities, only nodes. Bor works together with Windows AD/ Samba or FreeIPA. It supports LDAP and Kerberos authentication. Domain-joined machines could automatically enroll without setting the temporary token, issued from the UI.
How is configuration drift / policy enforcement handled if there's no polling interval? Like suppose a user changes a setting, does it revert back to the enforced setting, if so, when and how?
I would hope that it locks some of these policies. No user should be able to make changes to policies set by the administrator
Delivery is push, not pull. Each agent holds a persistent gRPC stream to the server (mTLS). Policy changes are broadcast over that stream the moment they're released — agents apply them in real time. If the connection drops, the agent reconnects with backoff and sends its last-known revision; the server replays exactly what it missed (or a full snapshot). So there's no "check every N minutes" anywhere in the design. Most user changes never stick in the first place. Where the desktop stack has a native lockdown mechanism, Bor uses it: dconf keys are written together with a dconf locks file, so a locked setting simply can't be changed from GNOME's UI; KDE settings are written with the Kiosk [$i] immutability marker, which KDE itself enforces; and everything else (Firefox/Chrome/Edge policies.json, polkit rules, firewalld zones) lives in root-owned files under /etc that an unprivileged user can't touch. Those applications treat managed policy as non-overridable by design. Root-level drift is caught by inotify, not a timer. For every file it manages, the agent watches the parent directory via inotify (parent dir, so atomically-renamed replacements are caught too). If anything external modifies or deletes a managed file — a curious admin with sudo, a config-management tool, a package postinstall script — the watcher fires immediately and the agent rewrites the file from its cached policy state and re-reports compliance to the server. In practice the revert happens within milliseconds of the write, and the tamper event is visible server-side, so drift isn't just corrected — it's auditable. (The agent suppresses events from its own writes, so it doesn't fight itself.)
Love it!