Ich muss einige Befehle mit sudo ausführen. Diese Befehle befinden sich entweder in .bashrcoder ~/binund sind in einem Git-Repository (d. h. Dotfiles) gespeichert.
Ich habe symbolische Links eingefügt, die ~rootauf meinen Benutzer verweisen $HOME, aber ich glaube, das ist aus Sicherheitsgründen nicht besonders gut, deshalb habe ich sie entfernt.
Meine Sorge ist, dass, wenn einnicht gerootedBenutzer haben Schreibberechtigungen für diese Dateien, ein Schadprogramm könnte eine Rechteausweitung durchführen. Dennoch finde ich viele Dotfiles-Repositorys, die meiner Meinung nach unsicher sind.
In .bashrc, sudo-Befehledürfen/etc/sudoersmit NOPASSWD eingeschaltet sein . Bei bin/*.shSkripten dachte ich daran, sudo aus Befehlen wegzulassen und sie an root zu senden, aber das kann ein Problem sein, da Git keine Eigentümerschaft speichert. (Fast) alle einzelnen Befehle erfordern sowieso sudo, also ist es technisch gesehen wohl dasselbe, außer dass es sicherer sein sollte, Skripte an root zu senden. Git würde wohl einige Probleme verursachen.
Ein Gedanke: Wenn ich jedem einzelnen Befehl NOPASSWD erteile /etc/sudoersund dann das Root-Passwort abfrage, würde ich riechen, dass etwas nicht stimmt.
Weitere Informationen:
- Dies gilt für einige lokale Einzelbenutzermaschinen.
- Unbefugter Zugriff auf meinen Desktop-Computer ist kein Problem, daher habe ich die automatische Anmeldung eingerichtet.
- Mein Laptop erfordert zum Starten einer Sitzung ein Kennwort.
Falls die Frage bis jetzt nicht klar ist, frage ich, wie ich diese Skripte/Befehle auf sichere Weise anordnen kann. Könnte eine Rechteausweitung mit Root schädlicher sein als ein Schadprogramm für die Daten meines eigenen Benutzers? Vielleicht mache ich mir einfach zu viele Gedanken?
Antwort1
Ein beschreibbares Skript kann in einer unaufmerksamen Situation durch etwas Bösartiges ersetzt werden, und wenn es von Root ausgeführt wird, ist das Spiel vorbei.
Stimmt, wenn Sie der einzige Benutzer des Rechners sind, ist das Risiko gering. Aber es ist oft einfacher, das Konto eines normalen Benutzers zu knacken (E-Mails mit Malware lesen, sich mit einer bösartigen Website verbinden, auf gut Glück eine zufällige Quelle kompilieren und ausführen, „um zu sehen, was sie tut“, ...), und dies würde eine Eskalation auf Root-Privilegien ermöglichen.
Antwort2
Unter Berücksichtigung aller mir bekannten Optionen ( /usr/local/bin, Eigentümer root, Entfernen der Schreibberechtigung) habe ich mich für das Flag „unveränderlich“ für jede versionierte Datei entschieden:
sudo chattr +i filename
Nicht-Root-Benutzer und nicht einmal der Eigentümer können das Flag zurücksetzen. Weder die Datei noch das übergeordnete Verzeichnis können entfernt oder ersetzt werden.
Um die Datei zu bearbeiten, habe ich die folgende Funktion hinzugefügt .bashrc:
editrc () {
sudo chattr -i $1
nano $1
sudo chattr +i $1
}
Auf anderen Computern muss ich die Dotfiles ziehen, das Flag muss vorher entfernt git pullund dann erneut angewendet werden. Habe eine Hilfsfunktion erstellt, die das Flag als Argument verwendet.
protect-config () {
FLAG=$1
FILES=$(git ls-files | xargs -I @ -- find @ -type f | xargs echo)
lsattr $FILES
if [ "$FLAG" ]; then
sudo chattr $FLAG $FILES
fi
}
Das heißt, ja, ich mache mir zu viele Gedanken darüber. Trotzdem ist es jetzt so. Hauptsächlich aus guter Gewohnheit.
BEARBEITEN: Ich verwende dies nicht mehr, da es eher unbequem war als das zusätzliche Sicherheitsgefühl.