fix(remove-system.map): continue past undeletable files

The deletion loop called `exit 0` on the first System.map that `[ -w ]`
rejected, so copies in later locations were never shredded. Where
`[ -w ]` passed but shred failed anyway, shred ran as a bare command and
tripped the ERR trap that pre.bsh installs, aborting with a "## Please
report this bug!" banner and exit 1.

Branch on shred's exit status instead of `[ -w ]`, which does not
predict removability. Unlinking depends on write permission on the
parent directory rather than on the file itself, and an append-only file
passes the test yet cannot be unlinked at all. For a full-capability
root process the check is also true on a mode 444 file, so it only ever
failed on read-only file systems and on files carrying the immutable
attribute.

Clear the immutable and append-only attributes before each attempt. Per
review, a System.map should never be immutable and `chattr +i` would
possibly complicate kernel package removal; append-only is cleared on
the same grounds, since it blocks removal without affecting `[ -w ]`.

Report the files that remain once at the end, under a single wiki link
rather than repeating it on every line, and withhold "Done. Success."
when anything failed. A file reachable under two names, such as
/lib/modules/<version>/build and the source symlink beside it, is listed
under each, since both matched and both failed.

Iterate an array rather than word-splitting a string with IFS, which a
/etc/remove-system.map_pre.d drop-in can set; under `IFS=:` the globs
matched nothing, so the script deleted nothing and still exited 0.

The removal loop no longer exits early on failure and the script ends in
an explicit `exit 0`; a non-zero status would fail the kernel package's
postinst hook and the oneshot unit on every boot.

Author: maybebyte

usr/libexec/security-misc/remove-system.map#security-misc-shared

@@ -12,31 +12,44 @@ fi
 
 shopt -s nullglob
 
-system_map_location="/boot/System.map* /usr/src/*/System.map* /lib/modules/*/*/System.map* /System.map*"
+system_map_list=( /boot/System.map* /usr/src/*/System.map* /lib/modules/*/*/System.map* /System.map* )
 
-counter=0
-for filename in ${system_map_location} ; do
-   counter=$(( counter + 1 ))
-done
-
-if [ "$counter" -ge "1" ]; then
+if (( ${#system_map_list[@]} > 0 )); then
    echo "INFO: Deleting system.map files..."
 fi
 
+failed_list=()
+
 ## Removes the System.map files as they are only used for debugging or malware.
-for filename in ${system_map_location} ; do
-   if [ -f "${filename}" ]; then
-      if [ -w "${filename}" ]; then
-         ## 'shred' with '--verbose' is too chatty. (7 lines)
-         shred --force --zero -u "${filename}"
-         echo "INFO: removed '${filename}'"
-      else
-         echo "NOTE: Cannot delete '${filename}' - read-only. For details, see: https://www.kicksecure.com/wiki/security-misc#system_map"
-         exit 0
-      fi
+for filename in "${system_map_list[@]}"; do
+   if [[ ! -f "${filename}" ]]; then
+      continue
    fi
+   ## The immutable and append-only file attributes ('chattr +i', 'chattr +a')
+   ## prevent deletion. Clear them. A System.map file has no legitimate
+   ## reason to carry either and they would possibly complicate kernel
+   ## package removal.
+   chattr -ia -- "${filename}" &>/dev/null || true
+
+   ## 'shred' with '--verbose' is too chatty. (7 lines)
+   ## 'shred' stderr is suppressed because failure is expected on read-only
+   ## file systems. Failures are reported below instead.
+   if shred --force --zero -u -- "${filename}" 2>/dev/null; then
+      echo "INFO: removed '${filename}'"
+      continue
+   fi
+   failed_list+=( "${filename}" )
 done
 
-if [ "$counter" -ge "1" ]; then
+if (( ${#failed_list[@]} > 0 )); then
+   for filename in "${failed_list[@]}"; do
+      echo "NOTE: Could not remove '${filename}'."
+   done
+   echo "NOTE: For details, see: https://www.kicksecure.com/wiki/security-misc#system_map"
+elif (( ${#system_map_list[@]} > 0 )); then
    echo "INFO: Done. Success."
 fi
+
+## Deliberately exits 0 even on partial failure. A non-zero exit code would fail
+## the kernel package's postinst hook and the oneshot unit on every boot.
+exit 0