Advanced Configuration and Maintenance

• 1: Avoiding Configuration Gaps
• 2: Protecting During Maintenance
• 3: Adjusting the Cache Size
• 4: File Backup and Versioning

1 - Avoiding Configuration Gaps

Overview: This is an advanced hardening guide. Lockdown seals HeartSuite Core Secure’s configuration with filesystem immutability, but programs like file editors and rm remain executable by default. For high-security environments, you can optionally restrict these tools during Lockdown to close additional attack surfaces. The Dashboard’s Maintenance screen ([t]) guides you through maintenance workflows, and the Mode Switch screen ([m]) manages Lockdown status.

Locking Down Maintenance Tools

• Programs like rm often need broad write access for maintenance.
• In production (lockdown), disable or restrict them to block misuse via vulnerabilities.

Example: Remove execution privileges from rm and make it immutable when Lockdown is applied. Restore access with hs-unlock for maintenance. The Dashboard displays the current lockdown status and guides you through unlocking when maintenance is needed.

Handling Programs Needing Write Access in Lockdown

• Database servers need write permissions to their data files/directories.
• Limit to specific paths—do not allow universal writes.
• Note: Database security is handled by the program itself, not HeartSuite Core Secure.

Optional Hardening: Programs Requiring Broad Access During Lockdown

Some programs (e.g., shutdown routines) need rm during operation, but you may want to restrict the full rm binary.

• Solution: Create a limited copy (limited_rm) with restricted permissions.
• Configure scripts to use the copy during Lockdown.

Setup steps:

1. Copy rm to limited_rm and rename original to rm-orig:

   # sudo cp /usr/bin/rm /usr/bin/limited_rm
   # sudo mv /usr/bin/rm /usr/bin/rm-orig
   # sudo ln -sf /usr/bin/limited_rm /usr/bin/rm
   

2. Reboot and allowlist limited_rm from the Dashboard’s Programs queue ([p]).
3. Update the Lockdown configuration to disable rm-orig and make both immutable.
4. Update hs-unlock configuration to restore access.

Restore full rm for maintenance:

# sudo mv /usr/bin/rm-orig /usr/bin/rm

Now, scripts call limited_rm with restricted access during lockdown.

2 - Protecting During Maintenance

Overview: Maintenance — such as installing packages, editing files, or applying updates — is the period during which you temporarily reduce HeartSuite Core Secure’s protection to make changes. The Dashboard’s Maintenance screen ([t]) guides you through the entire process, from safety preparation to returning to Secure Mode. The Maintenance screen appears only when the system is in Secure Mode, Secure Mode + Lockdown, or on the Non-HS kernel — it is not shown in Setup Mode, because in Setup Mode you are already in the maintenance-ready state.

Starting Maintenance

From the Dashboard in Secure Mode, select the Maintenance screen ([t]). The Dashboard automatically detects whether Lockdown is active and presents the correct path — you do not need to determine this yourself.

Safety Checklist

Before any mode change, the Maintenance screen presents a safety checklist. The Dashboard auto-detects system state where possible and shows the status of each item:

• Network isolation — disable network interfaces or restrict firewall rules to prevent remote access during maintenance
• Server processes — shut down daemons (e.g., web servers) to close attack vectors
• SSH access — no root login, key-based auth only, source IP restriction

The Dashboard shows green checkmarks for items that pass and amber warnings for items that need attention. Press [c] Confirmed to proceed or [s] Skip to continue without completing the checklist. If you skip, the Dashboard displays a persistent reminder throughout the maintenance period — it does not disappear until you return to Secure Mode.

Option 1: Switch to Setup Mode (No Lockdown)

This is the standard maintenance path. The HeartSuite Core Secure kernel stays active. Logging and backups remain fully operational.

After completing the safety checklist, the Maintenance screen explains what will change:

• Enforcement changes from blocking to logging only
• The HeartSuite Core Secure kernel remains active
• Backups continue running
• The existing allowlist is preserved
• New activity is logged, not blocked — it will appear in the review queues when you return to Secure Mode

Type YES (case-sensitive) to confirm the switch. The Dashboard reboots to apply the mode change.

After rebooting, the Dashboard shows Setup Mode is active with a Suggested Next Step. If the safety checklist was skipped, a persistent reminder appears. Make your changes — install packages, edit configuration, update software. HeartSuite Core Secure logs all new activity silently.

When finished, return to Secure Mode from the Dashboard. New events from the maintenance period appear in the review queues. Review and approve them through the standard allowlisting flow before enforcement resumes.

Option 2: Boot the Non-HS Kernel (Lockdown Active)

When Lockdown is active, the Maintenance screen does not offer the Setup Mode switch. Instead, it explains the situation and guides you through a 3-step process. This is the most complex journey in the product — it involves two reboots, a kernel selection at GRUB where the Dashboard cannot guide you, and a period where HeartSuite Core Secure is completely absent.

Step 1 of 3: Boot Non-HS Kernel and Remove Immutable Flags

After the safety checklist and typing YES to confirm, the Dashboard prepares you for the GRUB boot menu — the one moment where it cannot provide guidance. It shows the exact Non-HS kernel name to select and warns you not to select the HeartSuite Core Secure kernel. Press [r] to reboot.

The Dashboard saves your maintenance session state before rebooting. This state persists across reboots and kernel changes — the step counter (“Step X of 3”) follows you throughout the process.

After selecting the Non-HS kernel from GRUB, the Dashboard resumes automatically on login. It detects the absence of the HeartSuite Core Secure kernel module and adjusts its interface — actions that require the HeartSuite Core Secure kernel are hidden entirely, not greyed out. The Dashboard shows:

• “Non-HS kernel active. HeartSuite Core Secure is not loaded.”
• “No enforcement. No logging. No backups.”
• “Maintenance step 1 of 3: Remove immutable flags.”

Press [u] to remove the immutable flags set by Lockdown. After the flags are removed, the Dashboard presents the automatic Lockdown re-engagement choice:

• [d] Disable automatic Lockdown re-engagement — the startup script will no longer apply Lockdown on boot. You can re-enable this later. This simplifies future maintenance.
• [k] Keep automatic re-engagement — Lockdown will re-apply on every HeartSuite Core Secure kernel boot. Future maintenance will require this same process.

Both options carry equal weight — neither is recommended over the other. The choice depends on your operational needs.

Step 2 of 3: Make Your Changes

The Dashboard transitions to the maintenance workspace:

• “Maintenance step 2 of 3: Make your changes.”
• “You are on the Non-HS kernel. HeartSuite Core Secure is not active. Changes made now will not be logged.”

Make your changes — install software, update packages, modify configuration files. When finished, press [f] to prepare the return to the HeartSuite Core Secure kernel. The Dashboard pre-configures Setup Mode for the next boot.

Step 3 of 3: Boot HeartSuite Core Secure Kernel and Review

Select the HeartSuite Core Secure kernel from GRUB. The Dashboard appears automatically, showing Setup Mode is active and displaying the maintenance step counter. Software installed during maintenance may generate new log events — these appear in the review queues. Review and approve them, then return to Secure Mode from the Dashboard. If Lockdown was previously active and you kept automatic re-engagement, Lockdown will re-apply on the next reboot.

Lockdown and Filesystem Immutability

When Lockdown makes files immutable using chattr +i, those flags are stored at the filesystem level and persist across reboots — including reboots to the Non-HS kernel. If you attempt to modify a file that was made immutable during a previous Lockdown session, you will encounter an error such as “could not open file; errno:1.” The Maintenance screen’s [u] Remove immutable flags handles this automatically during Step 1 of the Lockdown path. For manual recovery outside the maintenance wizard, run hs-unlock.

3 - Adjusting the Cache Size

Overview: HeartSuite Core Secure caches allowlist entries in kernel memory for performance. Each cache slot holds one unique program or script. The default size works for most systems; adjust it only if you have an unusually large number of concurrent programs.

This is an advanced CLI tool — no Dashboard equivalent exists.

# hs-cache-size --help

• Range: 10-255 entries.
• Tune based on your server’s needs (more entries for varied workloads).

4 - File Backup and Versioning

Overview: Every time a file in a protected directory is modified, HeartSuite Core Secure automatically creates a versioned backup with a timestamp and file size. Only HeartSuite Core Secure can access the backups — no other program, including malware running as root, can read or destroy them. Versions are never automatically deleted.

How Backup Works

HeartSuite Core Secure monitors a list of protected directories. When any file in those directories (including subdirectories) is written, HeartSuite Core Secure silently creates a new versioned backup before the write completes. This runs automatically in both Setup Mode and Secure Mode — protection begins from first boot, before you have reviewed a single event.

By default, /home is configured for backup. You can add or remove directories from the Dashboard’s Backup screen.

Configuring Protected Directories

From the Dashboard, select the Backup screen ([b]). The screen shows your current backup configuration — which directories are protected and when they were last backed up.

From this screen you can:

• Add directories ([n]) — protect additional directories (e.g., /var/www, /etc, /usr/lib)
• Remove directories ([r]) — stop backing up a directory (removing a directory does not delete existing backups; existing versions are retained)

Recommended directories include those containing user documents, executable files, configuration, and shared libraries. Avoid high-churn directories like log directories — backup creates a new version on every write.

Restoring File Versions

If a file is compromised — for example, encrypted by ransomware — the Dashboard’s Backup screen lets you browse version history and restore any previous version of any file in a protected directory. The Backup screen offers two browse modes:

• File-first ([f]) — navigate by directory and file, then view versions of the selected file
• Timeline ([t]) — navigate by date, showing all files modified on a given day

To restore a single file, select it and choose the version to restore. Each version shows its timestamp and file size.

For ransomware recovery where many files were modified on the same date, use the Timeline view ([t]), press [d] to filter by date, review the affected files, and press [b] to batch restore all of them in one operation.

Lockdown and Backup

When Lockdown is active, the backup configuration file is sealed — no user or program, including root, can add or remove directories. This prevents an attacker who compromises a running process from silently disabling backup. To change the backup configuration, enter a maintenance period first (see Protecting During Maintenance).

Advanced: CLI Backup Management

For automation workflows, the underlying CLI tools are available:

# hs-backup-config-manager add /var/www
# hs-backup-config-manager remove /home
# hs-backup-config-manager list
# hs-version-manager list /home/user/document.txt
# hs-version-manager restore /home/user/document.txt --version 2023-11-01