pillar.get replaces lists, so once alerts queries are saved to pillar
from the SOC config UI, queries added to defaults later (e.g. the
licensed Group By Assessment, Name) never reach soc.json. Merge them by
name the same way availableModels are merged by id: pillar order and
edits are kept, and default queries missing from pillar are appended.
The assessment is a number, and SOC's missing bucket only works on keyword
fields, so the * made Elasticsearch fail parsing "__missing__" as a long.
Untriaged alerts now drop out of this view.
SOC (securityonion-soc#1363) now hides a query licensed for oai unless the
assistant is enabled and agentic, so the query editor's license help says so.
Claude-Session: https://claude.ai/code/session_01SZLcwj68A2wLo3F8TGKsLP
Groups alerts by the AI triage assessment, keeping untriaged alerts as a
missing bucket. Query entries take an optional license feature, which SOC uses
to hide this one on grids without OnionAI, and the query editor now shows it.
/opt/so/saltstack/default holds the source for every root-executed script --
/usr/sbin, the reactors, _runners/_modules/_beacons, the master engines and
salt-relay.sh -- plus every state the root master renders. SOC mounts
/opt/so/saltstack rw as uid 939, so root-owning /usr/sbin alone was not
enough: the next highstate would copy attacker-controlled bytes out of the
tree into the root-owned destination and run them.
SOC never writes under default/, it only reads it. Every SOC write targets
local/, which stays socore-owned, as does /opt/so/state. No mode is enforced
on default/ -- SOC reads that tree, and 750/640 would break its config load.
Also stops copy_new_files(), so-saltstack-update and setup from chowning the
tree back to socore, and replaces preserve: True in soup_scripts.sls, which
carried uid/gid in from the /tmp staging tree and would have undone the
ownership before the first post-soup highstate.
Salt installed the so-* scripts into /usr/sbin owned by unprivileged service
UIDs (939/socore, plus 930-960 per service) at mode 755, while root executes
those same files from cron, systemd and state cmd.run. Any file-write
primitive as one of those UIDs was therefore root.
Two mechanisms behind this are not visible in the diff:
file.recurse also manages the destination directory, so /usr/sbin itself was
chowned to whichever service UID ran last. A directory's owner may always
chmod it, so that UID could replace even the scripts already declared
user: root -- so-config-backup, so-suricata-eve-clean, so-nsm-mount-nvme.
usr_sbin_perms now pins the directory to root:root 555, the mode the
filesystem RPM ships.
Omitting user:/group: is a no-op on files that already exist, because
check_perms only chowns when a user is named. Explicit user: root is what
lets upgraded grids self-heal on the next highstate, and what makes a
revert chown back rather than silently do nothing.