Appendix B. Permissions, roles and four-eyes
This guide describes Lawliet 1.5.13.s (the current release). Screens, commands and procedures may change in later versions; the usage guide is updated with each release. Check the version your server runs under Settings > Platform or with ./lawliet version, and see the Releases page for what changed.
Every permission in the role editor (Settings > Access control > Roles), what it allows, which built-in roles hold it, and which critical actions need a second administrator. The list is taken from the platform's permission catalogue; the role editor and the server read the same list.
How permissions combine and how to change them: 1.2 Roles and permissions and 15. Users, roles and approvals.
B.1 The built-in roles#
| Short name used below | Role | Holds |
|---|---|---|
| SA | Super administrator | Every permission. Protected: cannot be edited or deleted |
| LSO | Left security officer | Every permission. Critical actions approved by the RSO |
| RSO | Right security officer | Every permission. Critical actions approved by the LSO |
| Adm | Administrator | Every permission. For sites that do not use the officer pair |
| An | Analyst | Every view permission except View users and View the audit trail, plus Run scans, Triage findings, Run forensics, Work the review queue, Manage evidence, Manage honeypots |
| Aud | Auditor | Every view permission, including View users and View the audit trail. Changes nothing |
| Vw | Viewer | Every view permission except View users and View the audit trail |
"All admin roles" below means SA, LSO, RSO and Adm.
A user can also be given single grants or denials on top of the role (15.2). A denial always wins. An API key is governed only by its scope, never by a role (15.7).
B.2 Every permission#
The Four-eyes column names the critical action the permission's changes fall under, and whether it needs a second signature by default. Each one can be switched on or off in Settings > Access control > Dual control, except "Change the dual-control policy", which is always on while dual control is on. "-" means no action under this permission is critical.
Overview#
| Permission | Key | What it allows | Built-in roles | Four-eyes |
|---|---|---|---|---|
| View the overview | view_dashboard | The Overview page and its figures, the wall (20) | All roles | - |
Fleet#
| Permission | Key | What it allows | Built-in roles | Four-eyes |
|---|---|---|---|---|
| View agents | view_agents | Environment > Hosts, the agent drawer, host health; the Assets page (10, 38) | All roles | - |
| Manage agents | manage_agents | Enrol agents, see the filled-in install command, send commands, turn self-protection on and off, revoke an agent's token, run protection drills, sync assets from agents, see Agent versions; also needed with Delete agents to remove a host (10, 16) | All admin roles | - |
| Delete agents | delete_agents | Remove a host or delete it with its records (with Manage agents), issue uninstall and stop codes, decommission every agent (10.7, 16) | All admin roles | Delete an agent (on) |
| Publish agent releases | manage_agent_releases | Import bundled agents, register, publish, unpublish, delete releases, roll out and upgrade one host (10.8) | All admin roles | Publish an agent release (on): publish, roll out, upgrade one host |
| Manage deployment credentials | manage_deployment | Add, edit and delete SSH and WinRM credentials, Kerberos realms, cancel deployments and tests. Testing a credential also needs Deploy agents remotely (13) | All admin roles | Deploy agents remotely (on): saving Kerberos realms and weakening a WinRM credential |
| Deploy agents remotely | deploy_agents | Deploy agents over SSH or WinRM, retry a host, test a credential (with Manage deployment credentials), make offline packages and revoke their codes (11.3, 13) | All admin roles | Deploy agents remotely (on): deploy, retry, test, offline package |
Compliance#
| Permission | Key | What it allows | Built-in roles | Four-eyes |
|---|---|---|---|---|
| View compliance | view_compliance | Scans and results, frameworks, schedules, drift, heatmap, trends, attestations, exceptions, reports; generate a report now; request an exception; AD assessment (read) (22-25, 14.5) | All roles | - |
| Run scans | run_compliance_scan | Start scans, create and manage compliance schedules, compare two scans, record and revoke attestations, create evidence bundles (22, 23, 25, 27) | All admin roles, An | - |
| Manage compliance | manage_compliance | Approve and revoke exceptions, revoke attestations, register AD domains and collect them (25.2, 14.5) | All admin roles | - (approving an exception is always someone other than the requester) |
| View hardening | view_hardening | The Hardening page, runs and their steps (26) | All roles | - |
| Run hardening | run_hardening | Create a run from a Fix plan, approve and execute, roll back, cancel; issue and download recovery artifacts (26) | All admin roles | Execute remediation (on): approve and execute, roll back, recovery issue and download |
| View evidence | view_evidence | The Evidence page, bundle details, JSON and HTML export, verification by API (27) | All roles | - |
| Manage evidence | manage_evidence | Listed in the role editor ("Create and export evidence bundles"). No screen checks it in this release: creating a bundle checks Run scans, exporting checks View evidence | All admin roles, An | - |
| Delete evidence | delete_evidence | Delete an evidence bundle (27.5) | All admin roles | - |
| Manage reports | manage_reports | Create and delete report schedules (25.3) | All admin roles | - |
Investigation#
| Permission | Key | What it allows | Built-in roles | Four-eyes |
|---|---|---|---|---|
| View findings | view_threats | Listed in the role editor ("DLP incidents, FIM events and detections"). No screen checks it in this release: DLP, FIM and Logs check View DLP, View FIM and Search logs | All roles | - |
| Triage findings | manage_threats | Set the status and note of DLP incidents and FIM events (32.2, 33.4) | All admin roles, An | - |
| View forensics | view_forensics | Cases, evidence, timelines, hunts and their results; parse indicators and validate YARA (34) | All roles | - |
| Run forensics | run_forensics | Open cases, collect, upload, download artifacts, export timelines, start and cancel hunts, escalate alerts, open an investigation from a story (34, 31.3, 38.2) | All admin roles, An | - |
| View active defence | view_defense | The Defense page, the action catalog and history (36) | All roles | - |
| Execute containment | execute_defense | Dispatch and undo containment actions, run a command, isolate a host from a review item, response from a case, auto-remediate an incident (36, 34.7, 39.1) | All admin roles | Run a containment action (on) |
| View honeypots | view_honeypots | Decoys and trips (35) | All roles | - |
| Manage honeypots | manage_honeypots | Create, deploy, undeploy and delete decoys, set a trip's status, turn on auto-contain (35) | All admin roles, An | - (auto-contain blocks run without a second signature; see 35.5) |
| View the review queue | view_review_queue | The Review queue, Stories and Playbooks pages (21, 37, 38) | All roles | - |
| Work the review queue | manage_review_queue | Change status, assign, comment, resolve, accept risk, suppress; triage detection alerts (21, 31.3) | All admin roles, An | - |
| Manage playbooks | manage_playbooks | Create, edit, enable and dry-run playbooks; ask again for a step's approval (37) | All admin roles | - (each containment step always needs a second signature) |
Logs#
| Permission | Key | What it allows | Built-in roles | Four-eyes |
|---|---|---|---|---|
| Search logs | view_logs | Search, saved searches, dashboards, alerts, entities, ATT&CK; preview and test rules; translate Sigma (30, 31) | All roles | - |
| Manage log sources | manage_log_sources | Add and delete syslog and HTTP sources (30.5) | All admin roles | - |
| Manage detection rules | manage_detections | Create, edit, enable, disable, run, restore and delete rules; import Sigma; suppress an alert subject; recompute entities (31) | All admin roles | - |
| Manage SIEM forwarding | manage_siem | See and change Settings > SIEM forwarding destinations, send test events (39.7) | All admin roles | Change SIEM forwarding (off) |
Network and data#
| Permission | Key | What it allows | Built-in roles | Four-eyes |
|---|---|---|---|---|
| View network | view_network | The map, nodes, discovery runs, exposure; export the topology (28) | All roles | - |
| Manage network | manage_network | Server-side discovery scans, rescan a node, remove hidden internet endpoints (28) | All admin roles | - |
| View firewall | view_firewall | Devices, rules, findings, plans, versions, monitoring, exports (29) | All roles | - |
| Manage firewall | manage_firewall | Connect a firewall, import a file, test, read now, make plans, set a baseline, start and stop monitoring, count hits from logs (29) | All admin roles | - |
| Push firewall policy | apply_firewall | Apply an approved plan to a live firewall (29.6) | All admin roles | Push a firewall policy (on) |
| View DLP | view_dlp | Incidents, policies, inventory, schedules, enforcement status (32) | All roles | - |
| Manage DLP | manage_dlp | Create, change, disable and delete DLP policies; test them; run and schedule discovery; locate files (32) | All admin roles | - |
| View FIM | view_fim | FIM events, policies, baselines, coverage (33) | All roles | - |
| Manage FIM | manage_fim | Create, change, disable and delete FIM policies; build baselines; verify; accept changes into the baseline (33) | All admin roles | - |
| View assets | view_intelligence | Listed in the role editor ("Asset profiles and business processes"). No screen checks it in this release: the Assets page checks View agents | All roles | - |
| Manage assets | manage_intelligence | Change an asset's criticality and environment (38.1) | All admin roles | - |
| Write to Active Directory | ad_write | Create or link a GPO on a domain controller (Deploy agents via GPO) (14.5) | All admin roles | Write to Active Directory (on) |
Administration#
| Permission | Key | What it allows | Built-in roles | Four-eyes |
|---|---|---|---|---|
| View users | view_users | Settings > Users (read) (15.2) | All admin roles, Aud | - |
| Manage users | manage_users | Create, change, disable and delete users, adjust permissions, reset two-factor; directory sign-in and Windows sign-in settings (15.2, 14) | All admin roles | Change users (on) |
| Manage roles | manage_roles | Create, change and delete custom roles (15.3) | All admin roles | Change roles (on) |
| Approve critical actions | approve_actions | Sign off another person's critical request, in a role the policy lets approve that requester (15.6) | All admin roles | - |
| Configure dual control | configure_dual_control | Change the dual-control policy (15.4) | All admin roles | Change the dual-control policy (always) |
| View the audit trail | view_audit | Settings > Audit trail and its verification (15.8) | All admin roles, Aud | - |
| Manage API keys | manage_api_keys | Issue and revoke service-account keys (15.7) | All admin roles | Change API keys (on) |
| Manage the licence | manage_licence | Activate or replace the licence (2.10) | All admin roles | Change the licence (on) |
| Manage platform updates | manage_updates | Check for, stage, upload and discard platform updates (4.4) | All admin roles | Stage a platform update (on) |
| Manage settings | manage_settings | Platform settings not covered by a narrower permission: the certificate card, the sandbox tab, diagnostics for support (39) | All admin roles | - |
| Manage demo data | manage_demo | Seed and clear the sandbox dataset (39.9) | All admin roles | Clear or seed demo data (off) |
B.3 Critical actions (four-eyes)#
While dual control is on, each action below is held until a second administrator signs it. The requester then executes it from Approvals > My requests (15.6). Who may approve whom is set by the policy: by default the LSO and RSO approve each other, and a super administrator approves anyone else.
| Critical action | Covers | Default | Guide |
|---|---|---|---|
| Change users | Create, delete or disable a user; change a role or single permissions; reset two-factor; directory and Windows sign-in settings | on | 15.2, 14 |
| Change roles | Create, edit or delete a role | on | 15.3 |
| Change the dual-control policy | Switch approval on or off for an action, change who approves | always | 15.4 |
| Run a containment action | Isolate, kill, block, quarantine, disable an account, reset credentials, undo them, run a command, auto-remediate | on | 36 |
| Execute remediation | Approve and execute a hardening run, roll it back, issue or download a recovery artifact | on | 26 |
| Push a firewall policy | Apply a plan to a live firewall | on | 29.6 |
| Delete an agent | Remove a host, or delete it with its records; issue an uninstall or stop code; decommission all agents. Revoking a token is not included | on | 10.7, 16 |
| Change the licence | Activate, replace or deactivate the licence | on | 2.10 |
| Stage a platform update | Download or upload a new platform version | on | 4.4 |
| Change API keys | Create or revoke a service-account key | on | 15.7 |
| Change SIEM forwarding | Add, edit or remove a SIEM destination | off | 39.7 |
| Publish an agent release | Publish a release, roll it out, upgrade one host | on | 10.8 |
| Deploy agents remotely | Deploy or retry over SSH/WinRM, test a credential, weaken a WinRM credential, save Kerberos realms, make an offline package | on | 13, 11.3 |
| Clear or seed demo data | Seed or clear the sandbox dataset | off | 39.9 |
| Write to Active Directory | Create or link a GPO on a domain controller | on | 14.5 |
A critical action also needs its own permission: for example removing a host needs Manage agents for the screen and Delete agents for the critical action.
Two more rules sit outside this table:
- A playbook's containment step always needs a second signature, whatever the policy says (37.1).
- An exception is always approved by someone other than the person who requested it (25.2).
On a new installation, while no two approvers exist who could sign for each other, an approver's critical actions run on one signature and are recorded as dual_control_bypassed (15.4).