[Bug 297373] [NEW PORT] sysutils/sysmanage-agent: Cross-platform system management agent for SysManage

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=297373

--- Comment #3 from Bryan Everly <[email protected]> ---
Created attachment 273642
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=273642&action=edit
sysutils/sysmanage 3.5.1.10 — git diff (poudriere + runtime tested)

Updated port for 3.5.1.10, attached as a git diff.

Thanks for the triage — the git-diff conversion and the sysutils/Makefile
SUBDIR entry are carried forward here, and $FreeBSD$ is gone from
files/sysmanage-agent.in.

As with sysutils/sysmanage, this revision is build- AND runtime-tested, and
the honest summary is that the version you triaged could not start: it built,
packaged, passed check-plist and stage-qa, installed — and the service never
came up, because the rc.d script passed a --config flag the program does not
parse, so it never found its configuration under ${PREFIX}/etc.

Changes since the previous attachment
-------------------------------------
rc.d script:
  * Exports SYSMANAGE_CONFIG (the override the agent honours) instead of
    passing --config, which was silently ignored.
  * Removed "daemon -u ${sysmanage_agent_user}".  ${name}_user is an rc.subr
    knob — run_rc_command already wraps the command in "su -m", so daemon(8)
    ran unprivileged and died in initgroups().  This was invisible while the
    default user was root, where both privilege drops are no-ops, but any
    admin lowering the rcvar got a service that silently refused to start.
  * pidfile moved into /var/run/sysmanage_agent/, created in start_precmd.
  * procname set to the interpreter, so onestatus/onestop report the truth.
  * Exports SYSMANAGE_DB_PATH and SYSMANAGE_LOG_DIR.  The agent's database
    path falls back to the process working directory, which daemon(8) -c sets
    to /, so as root it silently created /agent.db and unprivileged it could
    not create the database at all.

Packaging:
  * The agent now runs as a dedicated unprivileged account (USERS/GROUPS=
    sysmanage-agent, uid/gid 255 in ports/UIDs and ports/GIDs) and escalates
    through a sudoers policy installed 0440 root:wheel in
    ${PREFIX}/etc/sudoers.d.  RUN_DEPENDS gained security/sudo.
  * That account is deliberately NOT the "sysmanage" account used by the
    sysutils/sysmanage server port.  The policy is root-equivalent in
    practice, and sharing one account would let a compromise of that port's
    network-facing web application inherit these grants.
  * ${PREFIX}/etc/sysmanage-agent.yaml installs 0640 root:sysmanage-agent.
  * Writable state via @dir(): /var/db/sysmanage-agent and
    /var/log/sysmanage-agent.
  * pkg-message states plainly that the sudoers policy is not a security
    boundary — it grants install(1), chmod(1), chown(8), sed(1) and sysrc(8)
    with unrestricted arguments, each of which is by itself equivalent to
    root.  That is inherent to what the agent does (it installs packages,
    deploys files, manages services and reboots the host); the unprivileged
    deployment buys an audit trail through sudo, not containment.  The message
    also documents reverting to a root agent, in which case the policy is
    never consulted.

Testing
-------
  * portlint -AC: 0 fatal errors
  * make check-plist: clean
  * make stage-qa under DEVELOPER=yes: clean
  * poudriere testport: exit 0 in a clean 14.4-RELEASE amd64 jail
    (STRICT_DEPENDS=yes), including install and deinstall
  * Installed the resulting package on a 14.4-RELEASE host and confirmed: the
    service runs as the unprivileged sysmanage-agent account, the config and
    sudoers files land with the intended ownership and modes, "sudo -n -l"
    resolves the granted commands for that account, and the agent registers
    with a sysutils/sysmanage server and is manageable from it.

The previous attachments are marked obsolete.

-- 
You are receiving this mail because:
You are the assignee for the bug.