fix(remove-system.map): skip read-only files instead of aborting

[maybebyte]

Summary

remove-system.map shreds System.map* files because they expose a kernel
symbol-to-address map useful for exploitation. The deletion loop aborts on
the first read-only match, so writable copies in other locations are left on
disk while the run still reports success.

Changes

• Root cause: the read-only branch of the loop calls exit 0, which
  terminates the whole script on the first non-writable System.map (commonly
  /boot, which is often read-only). Later writable copies under /usr/src,
  /lib/modules, and / are then never shredded, and the Done. Success.
  summary is skipped even though the exit code reports success.
• Replace exit 0 with continue so each read-only file is noted and the
  loop proceeds through the remaining locations. The exit code is unchanged.

Testing

• Minimal reproduction of the loop's control flow: with exit 0 the run stops
  after the first read-only entry (no summary printed); with continue it
  processes the following writable entry and prints Done. Success.
• shellcheck on the modified script: no new findings (only a pre-existing
  SC1091 info note on the unrelated source line).
• No automated tests cover this script.

Notes for reviewers

• Behavior delta: on systems where an early System.map (e.g. under /boot)
  is read-only, writable copies elsewhere that were previously skipped will now
  be shredded — the tool's intended behavior.

[adrelanos]

If the first match cannot be deleted what's the point of attempting to delete others?

[maybebyte]

@adrelanos Let me see if I understand what you're saying here. You're saying that, if even one System.map file cannot be removed, it is pointless to try to delete the other ones?

Since we are running this service as root, semantics of [ -w ...] mean that we are essentially checking if it is on a read-only filesystem or immutable, if I understand correctly.

My thought process was that it isn't necessarily better to abort and keep other copies around. Better to reduce the total number of info leaks, even if it's not perfect. I didn't want to make invasive changes to try and ensure purity on a first pass.

I also find it a little surprising on the user end. If I have a tool that removes System.map files, what I would expect as the contract is that it does its best to do that, rather than aborting early. Does that reasoning hold up from your side or am I missing something?