Request for classic confinement: sentinelscan (read-only Ubuntu security scanner)

store-requests classic-confinement
1

  • name: sentinelscan

  • description: sentinelscan is a read-only Linux security scanner focused on Ubuntu. It runs a series of lightweight checks and reports misconfigurations with severity, evidence, and remediation. It does not modify the system.

  • Checks include:

    OS / kernel info (EOL detection)
Pending package & security updates (APT)
Firewall status (UFW / firewalld)
Network listeners (via ss)
SSH server hardening (`/etc/ssh/sshd_config`)
SUID/SGID binaries (selected system paths)
World-writable directories in sensitive paths
Home `~/.ssh` permissions
Output: human-friendly (`--pretty`) and JSON (`--json`) for CI; optional `--fail-on LEVEL` exit code gating.

  • snapcraft: sentinelscan/snap at main · shashank381/sentinelscan · GitHub

  • upstream: GitHub - shashank381/sentinelscan

  • upstream-relation: I am the upstream author and maintainer.

  • supported-category: System utilities requiring direct host access (security auditing tools). This fits the “classic-required system utilities” class. The application needs broad, non-enumerable read access across the host and must invoke host tools to produce accurate results.

  • reasoning: why strict + interfaces are insufficient):

    sentinelscan is read-only, but it must:

  1. Read arbitrarily across the host filesystem to audit configuration and permissions:
  • /etc/ssh/sshd_config, /etc, /usr/*, /var/lib/dpkg/, /proc/*, and users’ $HOME/.ssh/*. These paths are numerous/dynamic and cannot be practically enumerated via system-files/personal-files without frequent updates and store approvals.
  1. Use host networking/process tooling to produce truthful results:
  • ss -tulpn to list network listeners (requires visibility into host namespaces and /proc),
  • ufw status or firewall-cmd --state for firewall,
  • apt list/upgrade -s to assess updates/security pocket,
  • find across system paths for SUID/SGID and world-writable directories. Under strict confinement, these tools either are not accessible, are namespaced, or their outputs are incomplete due to sandbox restrictions.
  1. Assess file permissions exactly as seen by the host, not inside a sandbox.

Interfaces tested / considered: system-observe, hardware-observe, network-observe, mount-observe, process-control, personal-files/system-files (for selected paths). Even with generous plugs, strict confinement still blocks:

  • Access to many non-enumerable system locations needed for holistic auditing,
  • Comprehensive /proc visibility for listener/process mapping,
  • Stable access to host tools like ufw in a way that reflects the real system state.

Because the scanner’s value depends on complete, host-level visibility, classic confinement is required. The snap does not run a daemon, and it does not write to the system—only reads and reports.

[ :white_check_mark:] I understand that strict confinement is generally preferred over classic.

[ :white_check_mark:] I’ve tried the existing interfaces to make the snap to work under strict confinement.

2

Hey @ShashankSathola,

IMO this tool doesnt qualify for the classic snap and doesnt fit into any existing category. I checked the repo and it is just one python script which performs all basic checks by executing system commands. I would suggest you to use some existing python libraries and if required, use the system-backup interface to perform checks instead of classic

thanks

3

This request has been added to the queue for review by the @reviewers team.