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.
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.
Very nice. Can you elaborate why you chose mTLS authentication vs. SSH as a mean to deploy the policies.
Regarding the docs, the diagrams should really be replaced with something more familiar and readable such as Mermaid (currently it looks like a mixture of ad-hoc ASCII charts).
The general documentation is something that definitely needs a lot of improvement, but it's currently under active development.
Policies are delivered over a persistent gRPC stream, secured with mTLS, where each node gets it's own cert from Bor's built-in CA at enrollment - so there's no SSH key sprawl and no credentials on the server that could log into machines. Since agents connect outbound to the server, it works through NAT and firewalls without opening any inbound ports on desktops, and policy changes propagate in seconds over the already-open stream. SHH-push would have meant maintaining an inventory of searchable hosts and a server that can shell into the whole fleet - a much bigger attach surface for less capability.
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?
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.)
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?
Nice work on the mTLS/gRPC push design — the inotify drift-catch on parent dirs is a clean answer to the "revert happens before the user notices" problem, and I like that the audit trail
is server-side.
Question on the policy model: how do you handle conflicting policies across sources — say a package postinstall rewrites a managed file while a newer policy is mid-sync from the server, or
two policy types touch the same file? Does the agent queue and reconcile revisions, or last-write-wins?
Also curious: with LDAP-only auth, how do non-domain single-user laptops fit in? I manage a few personal machines that I'd love to centralize but they aren't LDAP-joined — is there a
lightweight path, or is the temp-token enrollment strictly for domain boxes?
The default enrollment is based on temporary (5 min lifetime)tokens, generated from the UI. Domain-joined machines use Kerberos, but this is optional. Using the temporary tokens, the admin have to execute the agent with a command-line option for enrollment.
About the files, most of the bor-managed files are not defaults, coming from the system packages. If a given file is overridden by a package, the Bor agent will immediately rollback the managed version.
Also, there is a priority value on each policy, if several policies have the same property.
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.
Would ansible meet some or all of your needs?
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.
Is there a reason you cannot use samba group policy objects, sssd or one of the other solutions out there?
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.
Very nice. Can you elaborate why you chose mTLS authentication vs. SSH as a mean to deploy the policies.
Regarding the docs, the diagrams should really be replaced with something more familiar and readable such as Mermaid (currently it looks like a mixture of ad-hoc ASCII charts).
The general documentation is something that definitely needs a lot of improvement, but it's currently under active development.
Policies are delivered over a persistent gRPC stream, secured with mTLS, where each node gets it's own cert from Bor's built-in CA at enrollment - so there's no SSH key sprawl and no credentials on the server that could log into machines. Since agents connect outbound to the server, it works through NAT and firewalls without opening any inbound ports on desktops, and policy changes propagate in seconds over the already-open stream. SHH-push would have meant maintaining an inventory of searchable hosts and a server that can shell into the whole fleet - a much bigger attach surface for less capability.
Some orgs might not want ssh running on user laptops/workstations, so I think that it's a plus to not have that requirement.
Is this a similar but more generic approach to cosmic sync[1] or more like a company deploys to many employees?
1: https://ostechnix.com/system76-cosmic-sync-linux-desktop-set...
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.)
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 is fantastic! I'd really love to see support for SCAP so it could be used to enforce DISA STIGs.
Love it!
Nice work on the mTLS/gRPC push design — the inotify drift-catch on parent dirs is a clean answer to the "revert happens before the user notices" problem, and I like that the audit trail is server-side. Question on the policy model: how do you handle conflicting policies across sources — say a package postinstall rewrites a managed file while a newer policy is mid-sync from the server, or two policy types touch the same file? Does the agent queue and reconcile revisions, or last-write-wins?
Also curious: with LDAP-only auth, how do non-domain single-user laptops fit in? I manage a few personal machines that I'd love to centralize but they aren't LDAP-joined — is there a lightweight path, or is the temp-token enrollment strictly for domain boxes?
The default enrollment is based on temporary (5 min lifetime)tokens, generated from the UI. Domain-joined machines use Kerberos, but this is optional. Using the temporary tokens, the admin have to execute the agent with a command-line option for enrollment.
About the files, most of the bor-managed files are not defaults, coming from the system packages. If a given file is overridden by a package, the Bor agent will immediately rollback the managed version.
Also, there is a priority value on each policy, if several policies have the same property.