- 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.

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?

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.)

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.

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.

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.