Ergänzung zu dem von @Gerry_Ghetto gesagtem:

a) Die hohe Anzahl der verwendeten sudo Aufrufe schreit geradezu danach, eben das ganze Skript als Superuser ausführen zu lassen.
z.B.: /usr/local/bin/vupd.sh root:root rwxr-x-r--
Ich weiß nicht, wie du sudo zur Erlangung von Rootrechten benutzt. Ob du es mit Paßwortabfrage machst. Oder - da du es ja ggf. automatisch mittels Keybinding als Normaluser benutzen willst - sogar per paßwortlosem sudo.
Letzteres ist halt absolut gefährlich wenn es global eingestellt wäre.

Sudo läßt such so konfigurieren, daß ein User nur genau den definierten Befehl als root ausführen darf, daß kann dann auch - unter kontrollierter Umgebung - paßwortlos sein. Anstatt nun deine Zillionen sudo-Aufrufe jeweils einzeln zu konfigurieren ist es eben sinnvoller das gesamte Skript als nur-root-ausführbar zu gestalten und dann für sudo genau nur diesen Skriptaufruf (paßwortlos) zu erlauben.

Das ist IMHO auch die einzig "richtige" Definition von sudo:
sudo soll einem User nicht mehr (Root)-Rechte geben, sondern etwaig notwendige Root-Rechte beschneiden/einschränken.

b) In einem Skript könntest du z.B. deine bisherigen Alias-Aktionen vulnchk, meltchk, rkhunt als Funktion definieren. Im Hauptteil des Skriptes würden diese Funktionen dann aufgerufen/verarbeitet. So hättest du deine gesamte "Logik" an einem Ort, es ist besser zu erweitern/warten und du könntest mit Variablen arbeiten.
Zur Ausgabe in eine Datei:
Wenn dein Skript all das in der gewünschten Form ausgibt, dann ist es ein Leichtes z.B. als Keybinding die gesamte Ausgabe des Skripts in eine Datei umzuleiten. Alternativ würde sich eine eigene Log-Funktion anbieten (z.B. mittels Skript-Option --log), wenn sich Skript-Ausgabe und gewünschte Datenaufbereitung im Logfile unterscheiden würden.

Also sowas wie:
sudo /usr/local/bin/vupd.sh
bzw.
sudo /usr/local/bin/vupd.sh > /pfad/zum/logfile
bzw.
sudo /usr/local/bin/vupd.sh --log

Weitere Tips:
Gerade am Anfang ist es oftmals hilfreich, nicht nur die Standardausgabe z.B. in eine Datei umzuleiten, sondern auch etwaige Meldungen die über die Fehlerausgabe(stderr) ausgegeben werden. Dazu kann stderr nach stdout umgeleitet werden bevor stdout selbst umgeleitet wird.
Beispiel: pacman -Sy als User wirft normalerweise eine Fehlermeldung.
pacman -Sy > /tmp/out
enthält diese Meldung nun nicht, da nur die Standardausgabe umgeleitet wurde.
pacman -Sy 2&> /tmp/out
enthält nun die Ausgaben von stdout und stderr

Ein hilfreiches Tool um sowohl Ausgaben durch ein Skript im Terminal zu haben (Standardausgabe, stdout) als auch z.B. in eine Datei umzuleiten ist /usr/bin/tee (siehe: man tee).
pacman -Sy 2>&1 | tee /tmp/out
gibt sowohl stdout/stderr ins Terminal aus als auch gleichzeitig in die Datei /tmp/out. Beachte die andere Syntax zur Umleitung von stderr nach stdout (2>&1), da hier eine Pipe(|) verwendet wird.

upps... ich glaube dann habe ich sudo wohl etwas zu sorglos eingesetzt.
Bisher habe ich Skripten geschrieben, in meinem /home/USER/skripten/ abgelegt und falls sudo benötigt wurde, mit visudo das Programm in "USER ALL=NOPASSWD:" eingetragen. Hat auch funktioniert, es waren ja immer nur vereinzelte sudo Aufrufe. Die "USER ALL=NOPASSWD:" Zeile geht mittlerweile schon über eine Bildschirmbreite hinaus. Dann werde ich wohl ein paar Skripten umschreiben müssen und die dann in /usr/local/bin/ ablegen.

Vielen Dank für die vielen Hinweise Leute.
Das hat mich weiter gebracht, werde die Hinweise Schritt für Schritt ausprobieren und mich nochmal melden wenn ich das Skript fertig habe.

    fdell Bisher habe ich Skripten geschrieben, in meinem /home/USER/skripten/ abgelegt und falls sudo benötigt wurde, mit visudo das Programm in "USER ALL=NOPASSWD:" eingetragen. Hat auch funktioniert, es waren ja immer nur vereinzelte sudo Aufrufe. Die "USER ALL=NOPASSWD:" Zeile geht mittlerweile schon über eine Bildschirmbreite hinaus. Dann werde ich wohl ein paar Skripten umschreiben müssen und die dann in /usr/local/bin/ ablegen.

    Da freut sich jeder Angreifer. Da kann der Angreifer mit ganz normalen Nutzerrechten dein Skript bearbeiten und es gleich auch ohne Passwort mit erhöhten Rechten ausführen.

      fdell Bisher habe ich Skripten geschrieben, in meinem /home/USER/skripten/ abgelegt und falls sudo benötigt wurde, mit visudo das Programm in "USER ALL=NOPASSWD:" eingetragen. Hat auch funktioniert, es waren ja immer nur vereinzelte sudo Aufrufe.

      Das ist dann aber IMHO (fast) richtig, da du NOPASSWD ja nur für einzelne Aktionen erlaubst.
      Schlimmer (desaströs) wäre es, der Bequemlichkeit halber
      USER ALL= NOPASSWD: ALL
      zu setzen, also jedes Kommando paßwortlos erlauben würdest.

      Nur: wenn du bisher dein gesamtes Skript als zulässig für paßwortloses Root eingetragen hast, dann birgt das IMHO viele Risiken:

      • verwenden eines falschen Befehls im Skript schützt nicht mehr vor einem "Disaster".
      • Mißbrauch deines Skripts wäre möglich, darin kann dann komplett als root agiert werden.

      Angenommen in einem Skript soll der User (per sudo)
      pacman -Sy
      ausführen können, also die Paketliste aktualisieren dürfen. Aber nur das, kein: pacman -Syu
      Wenn dein Skript gesamt nun per sudoers "freigeschaltet" wäre, dann könnte USER problemlos den Aufruf zu pacman -Syu ändern (oder anderes "Schlimmes" machen).
      Der bessere Ansatz wäre:
      USER ALL=(ALL) NOPASSWD: /usr/bin/pacman -Sy
      Also nur (ggf. exakt) den Befehl erlauben, für den Root-Rechte gebraucht werden.
      Dann braucht das Skript nicht per sudo gestartet zu werden, aber im Skript kann dann:
      sudo /usr/bin/pacman -Sy
      verwendet werden. Aber eben nicht: -Syu. Oder sowas wie:
      passwd root
      <grins>

      Das halte ich für den besseren Ansatz.
      Wenn die erlaubten Befehle unübersichtlich werden, schau dir ggf. mal Cmnd_Alias an. Damit könntest du "lange" Erlaubt-Zeilen mittels Alias reduzieren und diese Kommando(block)-Aliase ggf. auch in /etc/sudoers.d/ Einzeldateien auslagern.

        6 Tage später

        Hallo zusammen,
        ich habe das Skript nun unter /usr/local/bin abgelegt und "nur Besitzer" (root) Rechte gegeben.
        Jetzt überlege ich noch ob ich sudo (oder besser PKexec?) mit NOPASSWD einsetzen soll,
        damit ich es per Keybinding ausführen kann.

        Hier ist mein draft, würde mich über Verbesserungsvorschläge freuen, da einige Dinge noch nicht so gut laufen.

        #!/bin/sh
DATE=$(date +%d.%B.%Y@%HUhr%Mmin.%Ssek)
NAME="Security.Check.$DATE.log"

echo "*** 1. /sys/devices/system/cpu/vulnerabilities/ ***" > /home/USER/$NAME
echo "" >> /home/USER/$NAME
grep . /sys/devices/system/cpu/vulnerabilities/* >> /home/USER/$NAME
cd /usr/local/bin/spectre-meltdown-checker && wget https://meltdown.ovh -O spectre-meltdown-checker.sh
echo "" >> /home/USER/$NAME
echo "" >> /home/USER/$NAME
echo "" >> /home/USER/$NAME
echo "*** 2. /usr/local/bin/spectre-meltdown-checker ***" >> /home/USER/$NAME
echo "" >> /home/USER/$NAME
/usr/local/bin/spectre-meltdown-checker/spectre-meltdown-checker.sh >> /home/USER/$NAME
echo "" >> /home/USER/$NAME
echo "" >> /home/USER/$NAME
echo "" >> /home/USER/$NAME
rkhunter --update
rkhunter --propupd
rkhunter --config-check
echo "*** 3. /var/log/rkhunter.log ***" >> /home/USER/$NAME
echo "" >> /home/USER/$NAME
rkhunter --check --sk 
cat /var/log/rkhunter.log >> /home/USER/$NAME
chown USER:users /home/USER/$NAME
        1. Die Ausgabe von "spectre-meltdown-checker" zeigt komische Zeichen in der Logdatei an,
          in der Konsolenausgabe sind einige Zeichen farbig hinterlegt, liegt es daran?

        Spectre and Meltdown mitigation detection tool v0.42-1-g91d0699-dirty

        Checking for vulnerabilities on current system
        Kernel is [35mLinux 6.6.7-arch1-1 #1 SMP PREEMPT_DYNAMIC Thu, 14 Dec 2023 03:45:42 +0000 x86_64[0m
        CPU is [35mAMD Ryzen 5 5600G with Radeon Graphics[0m

        [1;34mHardware check[0m

        • Hardware support (CPU microcode) for mitigation techniques
          • Indirect Branch Restricted Speculation (IBRS)
          • SPEC_CTRL MSR is available: [42m[30m YES [0m
          • CPU indicates IBRS capability: [42m[30m YES [0m (IBRS_SUPPORT feature bit)
          • CPU indicates preferring IBRS always-on: [43m[30m NO [0m
          • CPU indicates preferring IBRS over retpoline: [42m[30m YES [0m
        1. RKhunter produziert massenhaft "warning" und "Warnung" Ausgaben in der Konsole, habe mich daher entschieden die Logdatei die RKhunter selbst erstellt zu verwenden.

        grep: Warnung: überzähliges \ vor +

        grep: Warnung: überzähliges \ vor !

        egrep: warning: egrep is obsolescent; using grep -E

        Das Problem wurde hier schon diskutiert, aber zumindest für die bei mir installierte Version nicht gelöst.
        https://bbs.archlinux.org/viewtopic.php?id=279670
        https://sourceforge.net/p/rkhunter/bugs/176/

          Variablen, die komplett gross geschrieben werden, sind eigentlich System- und Umgebungsvariablen. Du nutzt allerdings die Variablen nur lokal. Also solltest du auf die komplette Grossschreibung verzichten.

          echo ""
echo ""
echo ""

          kann man zu

          echo "\n\n"

          abkürzen.

          Da es sehr ungewöhnlich ist, dass es ein Verzeichnis "USER" unter /home gibt, gehe ich davon aus, dass du mit Handarbeit den eigentlichen Namen fürs Forum zensiert hast. Irgendwann vergisst du es in einer Zeile und das ganze Internet weiss dann, wie der Benutzer auf deinem System heisst. Du könntest in deinem Skript also auch eine Variable verwenden (vorausgesetzt der Benutzer hat die UID 1000):

          nutzer=$(getent passwd 1000 | cut -d':' -f1)

          Ausser du möchtest nicht komplett auf Handarbeit verzichten. Dann ginge auch:

          nutzer=USER

          fdell Die Ausgabe von "spectre-meltdown-checker" zeigt komische Zeichen in der Logdatei an,
          in der Konsolenausgabe sind einige Zeichen farbig hinterlegt, liegt es daran?

          Ja, das könnten ANSI codes sein. Wird die Ausgabe mit less -R test.log farbig dargestellt? Falls ja, könntest du zum Beispiel mit dem Programm ansifilter diese Zeichen aus dem Log entfernen.

            fdell Hier ist mein draft, würde mich über Verbesserungsvorschläge freuen, da einige Dinge noch nicht so gut laufen.

            Ich würde in NAME= (deine Ausgabedatei) noch den Pfad mit reinnehmen. Falls du diesen mal ändern wolltest müßtest du dich nur um eine Variable kümmern.
            Also z.B.:
            NAME="/home/USER/Security.Check.$DATE.log"
            oder z.B.:

            NAME="Security.Check.$DATE.log"
_DIR="/home/USER"
OUT="${_DIR}/${NAME}"

            und dann $OUT für alle Ausgabeumleitungen nutzen.
            Ein:
            echo -n "" > $gewählter-Ausgabedateiname
            am Anfang des Skripts erstellt die Ausgabedatei (leer). Dann kannst du in allen anderen Teilen des Skripts überall mit "Anhängen" arbeiten, also ">>". Das verhindert beim Umbauen/Erweitern des Skripts daß irgendwo versehentlich die Ausgabedatei neu angelegt würde.

            Mehrere Newlines in der Ausgabedatei kannst du per echo (zumindest für die bash shell) auch ggf. übersichtlicher durch:
            echo -e "\n\n\n" > ${OUT}
            lösen. Das erzeugt hier 3 Leerzeilen.

            Zum Problem 1 (spectre-meltdown-checker.sh):
            Du könntest prüfen, ob dieses Skript per Option ggf. eine Ausgabe ohne diese ANSI-Colorsequenzen ausgeben könnte. Alternativ kannst du diese rausfiltern:

            /usr/local/bin/spectre-meltdown-checker/spectre-meltdown-checker.sh \
   | sed 's/\[[0-9;]*m//g' \
   >> ${OUT}

            (Der Lesbarkeit halber in mehrere Zeilen aufgeteilt durch "\")
            Das filtert zumindest die gezeigten m-ANSI-Sequenzen, also z.B. "[1;34m" raus.

            //Edit: Ha, zu lange zum Tippen gebraucht... <g>

            • GerBra hat auf diesen Beitrag geantwortet.

                Danke für die Tipps.
                Habe soweit alles eingefügt, "less -R test.log" zeigt die Logdatei farbig an,
                ansifilter schaue ich mir noch an. Leider funktioniert
                echo "" /n/n nicht, denn es wird dann /n/n in die Logdatei geschrieben.

                #!/bin/bash
date=$(date +%d.%B.%Y@%HUhr%Mmin.%Ssek)
user=$(getent passwd 1000 | cut -d':' -f1)
name="/home/$user/Security.Check.$date.log"

echo -n "" > $name
echo "*** 1. /sys/devices/system/cpu/vulnerabilities/ ***" >> $name
echo "" >> $name
grep . /sys/devices/system/cpu/vulnerabilities/* >> $name

echo "\n\n" >> $name
echo "*** 2. /usr/local/bin/spectre-meltdown-checker ***" >> $name
echo "" >> $name
cd /usr/local/bin/spectre-meltdown-checker && wget https://meltdown.ovh -O spectre-meltdown-checker.sh
/usr/local/bin/spectre-meltdown-checker/spectre-meltdown-checker.sh >> $name

echo "\n\n" >> $name
echo "*** 3. /var/log/rkhunter.log ***" >> $name
echo "" >> $name
rkhunter --update
rkhunter --propupd
rkhunter --config-check
rkhunter --check --sk 
cat /var/log/rkhunter.log >> $name
chown $user:users $name
                • Martin-MS hat auf diesen Beitrag geantwortet.

                  fdell echo "" /n/n nicht, denn es wird dann /n/n in die Logdatei geschrieben.

                  Da fehlt die Option -e

                  enable interpretation of backslash escapes

                  und es müssen Backslashes und die Zeichenkette in Anführungszeichen eingeschlossen sein, also etwa so:

                  echo -e "\n\n"

                  um zwei leere Zeilen auszugeben

                  • fdell hat auf diesen Beitrag geantwortet.

                      Martin-MS upps, das hatte ich übersehen, mit der Option "-e" funktionert es.

                      Ich probiere die Lösungsvorschläge zu "spectre-meltdown-checker"jetzt aus.
                      Vielen Dank Leute, mit dem hier gelernten kann ich alle meine Skripten verbessern.

                      EDIT:
                      @GerBra
                      Der Filter funktioniert, die Logdatei ist jetzt 2kb kleiner.
                      Einige wenige unerwünschte Zeichen sind noch 1fach und 2fach vorhanden,
                      z.B. das "> Zeichen mit Unterstrich". Leider filtert die Forensoftware diese Zeichen heraus wenn ich ein "Zitat" oder "Code" einfüge um das Bsp. zu zeigen.

                      Aber weitestgehend funktioniert dieses Skript jetzt:

                      #!/bin/sh
date=$(date +%d.%B.%Y@%HUhr%Mmin.%Ssek)
user=$(getent passwd 1000 | cut -d':' -f1)
name="Security.Check.$date.log"
_dir="/home/$user"
out="${_dir}/${name}"


echo -n "" > ${out}
echo "*** 1. /sys/devices/system/cpu/vulnerabilities/ ***" >> ${out}
echo "" >> ${out}
grep . /sys/devices/system/cpu/vulnerabilities/* >> ${out}

echo -e "\n\n\n" >> ${out}
echo "*** 2. /usr/local/bin/spectre-meltdown-checker ***" >> ${out}
echo "" >> ${out}
cd /usr/local/bin/spectre-meltdown-checker && wget https://meltdown.ovh -O spectre-meltdown-checker.sh
/usr/local/bin/spectre-meltdown-checker/spectre-meltdown-checker.sh \
   | sed 's/\[[0-9;]*m//g' \
   >> ${out}

echo -e "\n\n\n" >> ${out}
echo "*** 3. /var/log/rkhunter.log ***" >> ${out}
echo "" >> ${out}
rkhunter --update
rkhunter --propupd
rkhunter --config-check
rkhunter --check --sk 
cat /var/log/rkhunter.log >> ${out}
chown $user:users ${out}

                      Vielen Dank an alle Unterstützer.
                      Durch das hier Gelernte kann ich alle meine Skripten sicherer und effizienter machen.
                      Da ich noch einige Skripte umschreiben muss, mache ich lieber einen neuen Thread
                      "Bash-Skripte, Anfängerfragen" auf.

                      • GerBra hat auf diesen Beitrag geantwortet.

                          fdell Einige wenige unerwünschte Zeichen sind noch 1fach und 2fach vorhanden,
                          z.B. das "> Zeichen mit Unterstrich". Leider filtert die Forensoftware diese Zeichen heraus wenn ich ein "Zitat" oder "Code" einfüge um das Bsp. zu zeigen.

                          Ich habe mir gerade mal das Skript spectre-meltdown-checker.sh angeschaut.

                          GerBra Du könntest prüfen, ob dieses Skript per Option ggf. eine Ausgabe ohne diese ANSI-Colorsequenzen ausgeben könnte.

                          Das Skript kann mit der Option --no-color gestartet werden. Das steht in der show_usage Funktion.
                          Diese Option findest du auch in der Hilfe, zu erreichen über:
                          sh /pfad/zum/spectre-meltdown-checker.sh --help
                          Daß sollte umfassender funktionieren als das "manuelle" sed-Konstrukt.

                          Ebenfalls interessant zum Experimentieren sind in diesem Skript die diversen --batch Varianten zur Steuerung der Ausgaben. Evtl. passen ja text/short/json besser für deine spätere Aufbereitung/Verwertung der Daten.

                              Danke dir, das werde ich mir genauer angucken.

                              EDIT:
                              Die Option "--no-color" liefert genau die gewünschte Ausgabe.
                              Dadurch kann ich den sed-Filter weglassen, aber den kann ich sehr gut für andere Dinge gebrauchen :-)

                              Die Option "--batch text" ist die by default eingestellte. Die Option "--verbose" liefert leider keine zusätzliche infos. Die Option "--explain" liefert leider keine zusätzliche infos. Außer einer Zeile die auf die "--explain" Option hinweist.

                              #!/bin/sh
date=$(date +%d.%B.%Y@%HUhr%Mmin.%Ssek)
user=$(getent passwd 1000 | cut -d':' -f1)
name="security-check.$date.log"
_dir="/home/$user"
out="${_dir}/${name}"


echo -n "Sicherheits-Checks vom $date" > ${out}
echo -e "\n\n\n" >> ${out}
echo "*** 1. /sys/devices/system/cpu/vulnerabilities/ ***" >> ${out}
echo "" >> ${out}
grep . /sys/devices/system/cpu/vulnerabilities/* >> ${out}

echo -e "\n\n\n" >> ${out}
echo "*** 2. /usr/local/bin/spectre-meltdown-checker ***" >> ${out}
echo "" >> ${out}
cd /usr/local/bin/spectre-meltdown-checker && wget https://meltdown.ovh -O spectre-meltdown-checker.sh
/usr/local/bin/spectre-meltdown-checker/spectre-meltdown-checker.sh --no-color >> ${out}

echo -e "\n\n\n" >> ${out}
echo "*** 3. /var/log/rkhunter.log ***" >> ${out}
echo "" >> ${out}
rkhunter --update
rkhunter --propupd
rkhunter --config-check
rkhunter --check --sk 
cat /var/log/rkhunter.log >> ${out}
chown $user:users ${out}

                              Ich finde es klasse, so lasse ich es erst einmal, bis mir was neues einfällt.
                              DANKE nochmals für die nette Unterstützung.