Root login Rapsberry Pi

Man sollte nur einzelne Befehle per root durchführen und nicht dauerhaft 
als root arbeiten.

Thomas O. schrieb:
> Man sollte nur einzelne Befehle per root durchführen und nicht
> dauerhaft als root arbeiten.

ist das ein neuer Arbeitsschutzparagraph? Sowas wie Zwangspausen? Nach 
wieviel Befehlen muss ich mich denn jeweils neu anmelden?

Bauform B. schrieb:
> Thomas O. schrieb:
>> Man sollte nur einzelne Befehle per root durchführen und nicht
>> dauerhaft als root arbeiten.
>
> ist das ein neuer Arbeitsschutzparagraph? Sowas wie Zwangspausen? Nach
> wieviel Befehlen muss ich mich denn jeweils neu anmelden?

Unwissenheit, Ignoranz und Selbstüberschätzung sind Grundlage für 
erfolgreiche Angriffe auf Computersysteme. Aber ja, muss jeder selber 
wissen…

J0h4nn35 schrieb:
> Reicht es, wenn ich PermitRootLogin auf yes
> setze?

Ja, reicht.

Aber warum willst Du Dich direkt als root und mit Passwort einloggen?
Natürlich wird so ein Raspi selten als NAS für Staatsgeheimnisse 
eingesetzt, und vielleicht hat er ja nicht einmal Internet-Zugang.
Aber "eigentlich" macht man das eine Nummer sicherer, selbst dann, wenn 
man es "eigentlich" nicht braucht. (Zumindest weiß man dann, wie's 
geht.)

Z.B.: Einloggen als user (gerne mit ssh Key) und dann Wechsel nach root.
Oder, wenn man denn unbedingt direkt als root einloggen will:

PermitRootLogin prohibit-password

PubkeyAuthentication yes #ist Standard

und den eigenen ssh public key auf dem raspi in

1

/root/.ssh/authorized_keys

.

Np R. schrieb:
> Aber warum willst Du Dich direkt als root und mit Passwort einloggen?

Gegen den direkten Root-Login spricht aus Sicherheitssicht nichts, 
sofern man a) dafür Sorge trägt, dass der adäquat abgesichert ist (lies: 
mit einem Schlüsselpaar, dessen privater Teil seinerseits mit einer 
ordentlichen Passphrase gesichert ist) und b) sich beim Hantieren mit 
dieser UID auf Sachen beschränkt, für die die damit einhergehenden 
Rechte notwendig sind (i.e. keinen normalen Userkram wie Downloader und 
Bastelsachen und so als Root ausführt).

Je nach Sichtweise könnte es gar der sicherere Weg sein, wenn man nur 
den direkten Login von Root mittels Schlüssel erlaubt, und lokal auf der 
Maschine sowohl das Passwort für Root unbrauchbar macht, als auch die 
unsägliche Defaultkonfiguration (beim RaspberryOS) von ›sudo‹ so fixt, 
dass kein User überhaupt irgendwie irgendwas mit Rootrechten ausführen 
kann. Immerhin kommen die meisten Angreifer zunächst über einen weniger 
privilegierten Account auf die Kiste.

wenn die Kiste so konfiguriert ist das jeder user sudo ohne 
Passwortabfrage verwenden kann, ja dann kann man gleich als admin mit 
Rootrechten arbeiten.

Marcus schrieb:
> Mit diesem Befehl kannst du dich als roof einloggen.

Allerdings nur, wenn du ein Dachdeckermeister oder Schornsteinfeger 
bist...

c-hater schrieb:
> Das ist der Punkt. Besser ein wirklich gut abgesicherter root-Zugang
> (der dann natürlich auch nur auschließlich zu administrativen Zwecken
> verwendet wird) als dieses schwachsinnige Gewichse mit sudo.

Auf Systemen, die keinen besonderen Sicherheitsanforderungen genügen 
müssen, ist sudo(1) eine sehr feine Sache. Allerdings wissen auch 
erfahrene UNIX-Sysops oft nicht, was damit alles möglich ist. Obendrein 
ist heutzutage ohnehin der Nutzer meistens die mit Abstand größte aller 
Schwachstellen.

> Das Problem ist halt nur, dass selbst dieses Grundkonzept nicht wirklich
> die Lösung für alle Probleme sein kann. Immer dann, wenn teilweise
> "Delegierungen" von administrativen Aufgaben erforderlich werden, muss
> man zwangsweise auf sudo und Konsorten zurückgreifen.

Technologien wie RSBAC, SE-Linux, AppArmor, Contol Groups, Namespaces, 
File Access Control Lists und Extended File Attributes existieren. Man 
müßte sie nur benutzen, aber meistens ist das gar nicht nötig.

Ansonsten erhöht das Einhalten der Best Common Practices das 
Sicherheitsniveau (nicht nur, aber auch von Linux-Systemen) deutlich. Zu 
diesen Best Common Practices gehört, daß der privilegierte Benutzer root 
sich niemals und unter keinen Umständen unmittelbar von einem 
Remotesystem aus anmelden darf, und nein, auch nicht mit einer stark 
verschlüsselten Verbindungstechnologie wie SSH.

Für einen direkten Remote-Login als privilegierter Benutzer root gibt es 
auch keinen Bedarf. Wie bereits erwähnt, gibt es vorhandene und 
funktionierende Technlogien zur Privilegienseparation und -Erweiterung. 
Man muß sie halt konfigurieren und nutzen, wenn man glaubt, ein solch 
hohes Sicherheitsniveau zu benötigen.

Ein T. schrieb:
> wenn man glaubt, ein solch hohes Sicherheitsniveau zu benötigen.

Geglaubt wird in der Kirche.

Als alleiniger Benutzer meiner Geräte (also, als Privatuser) braucht man 
"ein solch hohes Sicherheitsniveau" (frei nach Guttenberg: 
umgangssprachlich kann man auch root-Rechte sagen).
Außer ich gebe mich mit dem Auslieferungszustand meiner Distribution 
zufrieden.

Ein T. schrieb:
> Zu diesen Best Common Practices gehört, daß der privilegierte Benutzer
> root sich niemals und unter keinen Umständen unmittelbar von einem
> Remotesystem aus anmelden darf,

Ich bin ja ein Fan von BestPractises, aber in dem konkreten Fall seh ich 
den Nachteil nicht.
Wir reden von einem Pi wo per default sudo kein PW braucht.

Ist halt die Frage: willst du Admin-Fachsimpelei im Elfenbeinturm führen 
oder dem TE weiterhelfen?

Hans schrieb:
> Nur_ein_schaumschläger sondert mal wieder seinen Sondermüll ab

Hans schrieb:
> Willst du uns gleich wieder was von deinem poor man’s 2FA erzählen?

Sieh an, mein Stalker darf heute länger aufbleiben.

Peter Pan schrieb:
> Nenn mir doch bitte das Risiko eines root Zugangs per SSH Key mit einem
> sauber konfigurierten SSH Server.

1. Der "sauber konfigurierte SSH Server".
2. Mögliche Schwachstellen in der Verschlüsselung des SSH Private Key.
3. Mögliche Schwachstellen in der Verschlüsselung des SSH-Protokolls.
4. Mögliche Kompromittierung des Admin-Desktops.

Zu 2. und 3.: es ist schon sehr erstaunlich, wie schnell die Community 
die Lehren aus der Heartbleed-Geschichte vergessen hat. :-(

Leute, Leute, Leute... seid mir nicht böse, aber bei einem direkten 
Root-Login über SSH steht und fällt die Sicherheit der Sache in einer 
einzigen Schicht. "Richtige" Sicherheit geht aber davon aus, daß 
Sicherheitsschichten versagen können, deswegen ist ein mehrschichtiger 
Ansatz sinnvoller, um das Sicherheitsniveau zu erhöhen.

Le X. schrieb:
> Ein T. schrieb:
>> wenn man glaubt, ein solch hohes Sicherheitsniveau zu benötigen.
>
> Geglaubt wird in der Kirche.

Gut erkannt, genau deswegen hatte ich diese Formulierung gewählt.

> Als alleiniger Benutzer meiner Geräte (also, als Privatuser) braucht man
> "ein solch hohes Sicherheitsniveau" (frei nach Guttenberg:
> umgangssprachlich kann man auch root-Rechte sagen).

Ja, schon klar, alle wollen total sicher sein. Aus meiner Perspektive 
beginnt Sicherheit aber mit einer Risikoanalyse. Bitte korrigiere mich, 
wenn ich falsch liege, aber das Sicherheitsniveau eines Paketfilter- 
oder Proxy-Firewall, oder eines Onlinebanking-Servers mit PCI-DSS, oder 
eines Systems, das den Regelungen der BaFin oder des HIPAA Act 
unterliegt, wirst Du auf Deinem Desktop wohl nicht benötigen, oder?

> Ich bin ja ein Fan von BestPractises, aber in dem konkreten Fall seh ich
> den Nachteil nicht.
> Wir reden von einem Pi wo per default sudo kein PW braucht.

Das halte ich tatsächlich für eine Fehlkonfiguration, ist aber 
sicherlich dem Umstand geschuldet, daß ein überwiegender Teil der 
RasPi-Nutzer keine erfahrenen UNIX- oder Linux-Experten sind. Ich selbst 
ändere diese Konfiguration schon vor einem ersten Login, meist sogar 
direkt nach dem Beschreiben der SD-Karte mit dem gewünschten 
Betriebssystemimage.

> Ist halt die Frage: willst du Admin-Fachsimpelei im Elfenbeinturm führen
> oder dem TE weiterhelfen?

Es erscheint mir durchaus hilfreich für den TO, ihm den Rat zu geben, 
das, was er sich da vorstellt, nicht zu machen. Dies insbesondere auch, 
weil es hier so viele "Experten" wie c-hater und sogar echte Fachleute 
wie Jack gibt, die kein Problem in einer solchen Konfiguration sehen 
können oder wollen.

Dabei liegt zumindest Jack nicht vollkommen daneben, setzt aber leider 
voraus, daß der TO ein erfahrener Admin sei und die von ihm erwähnten 
zusätzlichen Maßnahmen zur Absicherung durchführen könne. Diese Prämisse 
halte ich für problematisch, weil die Frage des TO und seine 
ausdrückliche Aussage, er sei Linux-Anfänger, eine derartige Expertise 
keinesfalls vermuten läßt.

Insofern finde ich, ja, ein Hinweis auf die Best Common Practices, 
nämlich sein Vorhaben nicht umzusetzen und keinen direkten Remote-Login 
als privilegierter Benutzer root zuzulassen, wie das aus guten Gründen 
ja auch auf vielen anderen Linux- und UNIX-Systemen die 
Standardeinstellung ist, stellt für den TO eine sinnvolle Hilfestellung 
dar.

Edit: vergessenes Wort ergänzt.

Ein T. schrieb:
> Leute, Leute, Leute... seid mir nicht böse, aber bei einem direkten
> Root-Login über SSH steht und fällt die Sicherheit der Sache in einer
> einzigen Schicht.

Dank der bei den einschlägigen Distris verwendeten kaputten sudo-Config 
wäre die „zweite Schicht“ in dem von dir gezeichneten Szenario, in dem 
SSH selbst der Einfallsvektor ist, halt auch eher Dekoration als echter 
Schutz: Jemand, der erstmal Zugriff mit Userrechten auf so einem System 
erlangt hat, kann im nächsten Schritt im Normalfall problemlos das für 
›sudo‹ genutzte Passwort (üblicherweise ja das Userpasswort) abgreifen, 
und hat (in der kaputten Config, wohlgemerkt) dann direkt volle 
Rootrechte – so what?

Ein noch schlechterer Schutz als ein nichtvorhandener Schutz ist ein 
eingebildeter Schutz.

Und im Gegensatz zu der Variante, bei der sich Root nur von außen 
einloggen kann, ist’s bei der Variante, den Root-Login zu verbieten und 
die Rechte nur lokal zu erlangen, dann auch egal, wie der Bösling 
Zugriff mit den Userrechten erlangt hat – reicht, dass er drauf ist. 
Wenn ich abschätzen sollte, ob „Useraccount kompromittiert“ oder „SSH 
kaputt“ häufiger vorkommt, würde ich dann doch deutlich zu Ersterem 
tendieren.


Best Practice hängt jedoch immer auch ein wenig vom Kontext ab. Einen 
normalen Pi im LAN, der vielleicht noch etwas Wölkchen für unterwegs 
anbietet und daher exponiert ist, wird man ganz sicher nicht mit der 
vollen Packung Sicherheitskonzept belegen, die ein Admin auffahren kann, 
der geschäftskritische Firmen-IT betreut, und für die Zeit Geld bekommt. 
Letztlich gibt es auch nicht das eine Konzept, das für jeden passt.


OT: warum hast du dir eigentlich ’nen neuen Account geklickt? Ich fand 
die Verwechselungen eigentlich immer recht witzig

> Jemand, der erstmal Zugriff mit Userrechten auf so einem System
> erlangt hat, kann im nächsten Schritt im Normalfall problemlos das für
> ›sudo‹ genutzte Passwort (üblicherweise ja das Userpasswort) abgreifen,
> und hat (in der kaputten Config, wohlgemerkt) dann direkt volle
> Rootrechte – so what?

Für sudo muss man aber (zumindest ist es bei mir so) das Root-Passwort 
eingeben.
Bei meinem Server geht das SSH Login auch nicht mit root, allerdings 
nutze ich sudo eher selten und wechsle meist mit "su -" zum 
Root-Account.

Jörg

Joerg W. schrieb:
> Für sudo muss man aber (zumindest ist es bei mir so) das Root-Passwort
> eingeben.

Hier gehts um Raspberry Pi OS (ehemals Raspbian).
Da erfordert sudo im default kein PW.

Dave schrieb:
> Mal drei Gründe FÜR sudo:
> […]

Der erste und der letzte Punkt setzen voraus, dass jemand sudo 
konfiguriert hat, der sich damit auskennt – und dann ist’s, wie sudo 
tatsächlich gedacht war und auch genutzt werden sollte. Und dann kann 
sudo tatsächlich einen Sicherheitsgewinn mit sich bringen.

Der mittlere Punkt ist hingegen alleinestehend untauglich: wer 
Userzugriff hat, kann auch das Passwort abgreifen. Nicht sofort, aber 
sobald der User sudo das nächste Mal ausführt. Wenn der dritte Punkt 
jedoch sauber umgesetzt worden ist, hält sich der Schaden auch hier in 
Grenzen.

Gibt halt kein Setup, das für jeden gleichermaßen passt. Gibt aber 
welche, die aus Sicherheitssicht universell untauglich sind, und einem 
User via sudo sämtliche Rechte einzuräumen, gehört dazu – aber darum 
ging’s hier ja eigentlich gar nicht, und diese Diskussion gab’s ja auch 
schon oft genug.

Jack V. schrieb:
> Jemand, der erstmal Zugriff mit Userrechten auf so einem System
> erlangt hat, kann im nächsten Schritt im Normalfall problemlos das für
> ›sudo‹ genutzte Passwort (üblicherweise ja das Userpasswort) abgreifen,

Erstmal muß er Benutzerrechte auf dem System bekommen, und dann muß er 
auch noch unbemerkt das Paßwort abgreifen. Beides ist keineswegs so 
trivial, wie es sich bei Dir liest, insbesondere dann, wenn es unbemerkt 
geschehen muß.

> Ein noch schlechterer Schutz als ein nichtvorhandener Schutz ist ein
> eingebildeter Schutz.

Das ist zweifellos richtig, Stichwort Risikokompensation, aber sudo(1) 
IST in dem hier diskutierten Fall eine vorhandene Hürde, die ein 
Angreifer erst einmal unter überwinden muß. Jede zusätzliche Hürde, auch 
eine niedrige, erhöht für den Angreifer das Entdeckungsrisiko und den 
Aufwand -- und damit die Wahrscheinlichkeit, daß er sich ein leichteres 
Opfer sucht. Ob Du mit der Default-Konfiguration von sudo(1) in den 
verbreiteten Distributionen glücklich bist, spielt dabei keine Rolle, 
und wenn Du sicherheitsbewußt und -informiert bist, diese Konfiguration 
zu kennen, kannst Du sie binnen weniger Sekunden nach Deinen Wünschen 
ändern.

> Und im Gegensatz zu der Variante, bei der sich Root nur von außen
> einloggen kann, ist’s bei der Variante, den Root-Login zu verbieten und
> die Rechte nur lokal zu erlangen, dann auch egal, wie der Bösling
> Zugriff mit den Userrechten erlangt hat – reicht, dass er drauf ist.

Ganz so egal ist das nicht, wie der User die Userrechte erlangt hat, und 
wenn er die erlangt hat, ist es ohnehin zu spät und das Kind liegt tot 
im Brunnen. Zudem wird ein Angreifer, der Userrechte auf dem System 
erlangt hat, sich vermutlich nicht zu lange mit dem Abgreifen von 
Paßworten aufhalten, sondern die Privilegienerweiterung über einen 
lokalen Exploit zu erlangen versuchen.

> Wenn ich abschätzen sollte, ob „Useraccount kompromittiert“ oder „SSH
> kaputt“ häufiger vorkommt, würde ich dann doch deutlich zu Ersterem
> tendieren.

Da bin ich ganz bei Dir, keine Frage. Hatte ich ja oben schon 
geschrieben: das mit Abstand größte Sicherheitsrisiko sind die Benutzer.

> Best Practice hängt jedoch immer auch ein wenig vom Kontext ab. Einen
> normalen Pi im LAN, der vielleicht noch etwas Wölkchen für unterwegs
> anbietet und daher exponiert ist, wird man ganz sicher nicht mit der
> vollen Packung Sicherheitskonzept belegen, die ein Admin auffahren kann,
> der geschäftskritische Firmen-IT betreut, und für die Zeit Geld bekommt.
> Letztlich gibt es auch nicht das eine Konzept, das für jeden passt.

Ja, natürlich -- aber wenn das Maschinchen sogar von extern erreichbar 
ist, dann gelten erhöhte Sicherheitsanforderungen -- wie bei jedem 
System, das von extern erreichbar ist. Deswegen steckt man solche 
Systeme üblicherweise in ein eigenes Netzwerksegment, die 
Demilitarisierte Zone (DMZ). Aber das weißt Du ja selbst.

Joerg W. schrieb:
> Für sudo muss man aber (zumindest ist es bei mir so) das Root-Passwort
> eingeben.

...oder halt das Nutzerpaßwort, das ist bei vielen Distributionen heute 
bereits so voreingestellt. Ich persönlich finde das bei Weitem nicht so 
schlimm wie andere Benutzer hier und sehe zumindest noch einen zweiten 
Vorteil: durch die Abfrage des Paßwortes wird unbedarften und / oder 
unkonzentrierten Benutzern noch einmal klar verdeutlicht, daß sie jetzt 
den Komfortbereich verlassen und aufpassen müssen, was sie tun.

Matthias schrieb:
> Joerg W. schrieb:
>> Für sudo muss man aber (zumindest ist es bei mir so) das Root-Passwort
>> eingeben.
>> Bei meinem Server geht das SSH Login auch nicht mit root, allerdings
>> nutze ich sudo eher selten und wechsle meist mit "su -" zum
>> Root-Account.
>
> Der Punkt ist aber, dass ein Angreifer, der bereits als User angemeldet
> ist, auch die PATH Variable deiner Shell ändern kann.

Nein, kann er nicht. Als User kann er höchstens SEINE PATH-Variable 
manipulieren. MEINE kann er nur dann manipulieren, wenn er MEINEN 
Benutzeraccount übernommen hat, und das sudo(1) (oder, angelegentlich: 
das SSH-Binary) kann er dann durch eine manipulierte Version ersetzen, 
wenn er bereits root-Privilegien hat und die Sache ohnehin schon aus 
meiner Sicht maximal verkackt ist.

> Damit könnte er
> ein falsches sudo ablegen, das das eingegebene Passwort im Klartext
> speichert. Der Angreifer muss zwar warten, bis sich der Admin wieder
> anmeldet, ab dann hilft das aber auch nicht mehr.

All diese Annahmen gehen davon aus, daß ein Angreifer meinen 
User-Account knacken und an meinem Environment herumfummeln konnte. Aber 
so einfach ist das gar nicht, den Useraccount auf einem Linux zu 
übernehmen, langfristig zu behalten, dann auch noch die gewünschte 
Information (das Paßwort) irgendwohin zu verschieben oder abzugreifen -- 
und das alles, ohne daß der User etwas davon mitbekommt. Und dann, wie 
schon eben erwähnt: wenn ein User MEINEN Account auf MEINEM System 
knacken konnte, ist sicherheitstechnisch schon sehr massiv etwas 
schiefgelaufen und meine RasPis mein allerkleinstes Problem.

Ein T. schrieb:
> durch die Abfrage des Paßwortes wird unbedarften und / oder
> unkonzentrierten Benutzern noch einmal klar verdeutlicht, daß sie jetzt
> den Komfortbereich verlassen und aufpassen müssen, was sie tun.

Wenn’s denn so wäre: in der Praxis geben die Buntu-User (mal 
stellvertretend, weil Ubuntu das nunmal salonfähig gemacht hat) beim 
ersten Befehl ihr Passwort ein, und schreiben dann vor jedem Befehl ihr 
›sudo‹ – für die scheint es für „führe aus:“ zu stehen, und nach dem 
Passwort wird dann auch erstmal nicht mehr gefragt.

Und es ist auch absolut nicht schwer, die .bashrc (oder das Äquivalent 
der benutzten Shell) so zu erweitern, dass das beim Aufruf von sudo 
eingegebene Passwort ausgeleitet wird, ohne dass der User es merkt – 
einen Proof of Concept hat mir ein User vor Jahren schon in einem 
anderen Forum geschickt, mögliche Wege sind weiter oben hier im Thread 
skizziert. Man muss es nicht mal sonderlich verstecken, weil diese 
Usergruppe, die ›sudo‹ selbst vor ›ls‹ im ~ schreibt, sicher nicht in 
die entsprechenen Files guckt, oder gar ein IDS laufen hat, das bei 
solchen Änderungen Alarm schlagen würde.

Aber wie gesagt – die sudo-Diskussion hatten wir schon. Da warst du noch 
mit dem anderen Account unterwegs. Da gab’s damals keinen Konsens, und 
so wird es auch hier keinen geben.

imonbln schrieb:
> Auf der anderen Seite bietet sich ein Key basierter SSH Zugang für Root,
> vor allen dann an, wenn es regelmäßig automatisierte Aufgaben gibt,
> welche ein Remote Server auf den Raspberry Pi erledigen muss.

Für so etwas gibt es Lösungen wie Ansible oder Fabric, die sich als 
unprivilegierter Benutzer einloggen und dann per sudo(1) die nötigen 
Privilegien verschaffen können.

Le X. schrieb:
> Joerg W. schrieb:
>> Für sudo muss man aber (zumindest ist es bei mir so) das Root-Passwort
>> eingeben.
>
> Hier gehts um Raspberry Pi OS (ehemals Raspbian).
> Da erfordert sudo im default kein PW.

...und die Credentials des Standardbenutzers sind bekannt. Aus 
Sicherheitssicht ist das keine besonders sinnvolle Konfiguration, nein. 
Aber die Antwort darauf kann ja nicht sein, die Best Common Practices 
einfach mal komplett über Bord zu werden, und die Konfiguration noch 
unsicherer zu machen.

Jack V. schrieb:
> Der erste und der letzte Punkt setzen voraus, dass jemand sudo
> konfiguriert hat, der sich damit auskennt

Dein Vorschlag setzt aber voraus, daß sich jemand mit SSH inklusive 
ssh-keygen(1) und ssh-agent(1) auskennt und das konfiguriert. Wenn das 
nicht gegeben, reißt Du mit Deiner Empfehlung eine zusätzliche 
Sicherheitslücke auf, ohne die vorhandene -- die schwache 
sudo(1)-Konfiguration zu beheben. Am Ende hat der User also zwei 
Probleme anstatt nur eines Problems... ob das so eine gute Idee ist?

Jack V. schrieb:
> Wenn’s denn so wäre: in der Praxis geben die Buntu-User (mal
> stellvertretend, weil Ubuntu das nunmal salonfähig gemacht hat) beim
> ersten Befehl ihr Passwort ein, und schreiben dann vor jedem Befehl ihr
> ›sudo‹ – für die scheint es für „führe aus:“ zu stehen, und nach dem
> Passwort wird dann auch erstmal nicht mehr gefragt.

Das ist nicht schön, und noch viel schlimmer: wenn sie solcherart über 
sudo(1) Dateien oder Verzeichnisse anlegen, gehören die root und sie 
brauchen dann immer wieder sudo(1), um sie zu bearbeiten.

> Und es ist auch absolut nicht schwer, die .bashrc (oder das Äquivalent
> der benutzten Shell) so zu erweitern, dass das beim Aufruf von sudo
> eingegebene Passwort ausgeleitet wird, ohne dass der User es merkt –
> einen Proof of Concept hat mir ein User vor Jahren schon in einem
> anderen Forum geschickt, mögliche Wege sind weiter oben hier im Thread
> skizziert.

Doch, das ist ziemlich schwer, sonst würde es ja alle naselang 
passieren, und die Blogs, Zeitungen, Fernsehnachrichten, Twitter und 
Youtube wären voll mit Idioten, die "Linux ist unsicher" schreien 
würden. Das ist aber nicht so -- und jetzt rate, warum? Genau: weil es 
gar nicht so einfach ist, einen Useraccount auf einem Linux unbemerkt zu 
kompromittieren, dort Dat(ei)en zu manipulieren, Daten auszuleiten, und 
so weiter -- und da alles dauerhaft zumindest so lange, bis der User 
sich wieder mal erweiterte Privilegien verschafft. Übrigens: wenn ich 
$PATH manipulieren kann, greif ich das Paßwort mit einem manipulierten 
su(1) ab... auch nix gewonnen, oder?

> Aber wie gesagt – die sudo-Diskussion hatten wir schon. Da warst du noch
> mit dem anderen Account unterwegs. Da gab’s damals keinen Konsens, und
> so wird es auch hier keinen geben.

Hier geht es ja um den privilegierten Remote-Zugang. Warum einige User 
das jetzt wieder zu einer Diskussion über sudo(1) gemacht haben, ist mir 
schleierhaft. Und diese sudo(1)-Diskussion spielt auch keine Rolle, denn 
die Aussage "also dies und jenes ist unsicher, da kann der Rest ruhig 
auch noch unsicherer gemacht und der übliche Stand der Technik ignoriert 
werden" ist ja wohl nicht ernst gemeint.

Ein T. schrieb:
> Hier geht es ja um den privilegierten Remote-Zugang.

Genau, und deswegen:

Ein T. schrieb:
> Übrigens: wenn ich
> $PATH manipulieren kann, greif ich das Paßwort mit einem manipulierten
> su(1) ab... auch nix gewonnen, oder?

→ wenn ich aber vollständig verhindere, dass ein User lokal via Passwort 
Rootrechte erlangen kann, indem ich nämlich root nur den direkten Login 
mit sicherem Schlüssel erlaube, dann bin ich all diese Szenarien, in 
denen ein kompromittierter Useraccount durch Abgreifen des Passworts als 
Sprungbrett dient, schonmal los. Denn entgegen deiner Darstellung ist’s 
eben nicht schwer: wer Userrechte erlangt hat, kann die entsprechenden 
Änderungen vornehmen – ob nun PATH, ~/.bashrc oder irgendwas Anderes, 
ist dabei egal. Und wenn der User lokal zu Root werden kann, kann der 
Angreifer, der den Useraccount kompromittiert hat, das nunmal auch.

Dass es nicht alle Nase lang passiert, liegt eher daran, dass es häufig 
nicht gar so leicht ist, überhaupt erstmal an den Useraccount zu kommen. 
Dass man kaum was über die Fälle liest, in denen es doch passiert ist, 
liegt dann wieder eher daran, dass die betreffenden User das gar nicht 
mitbekommen. Damals™, in längst verjährter Zeit, hatte ich ’nen Stapel 
dedizierter Server zur Hand, für die andere Leute bezahlt haben. So 
Leute vom Typ „ich hab zwar gar keine Ahnung von Linux, aber ich kann 
mir ja einfach ’nen eigenen Gameserver klicken – muss man ja gar nix für 
können!!k“. Solange man nicht übertrieben hat und vor allem keine 
„unerklärlichen” Fehler oder gar Abuse-Mails an den Provider provoziert 
hat, ist’s denen nie aufgefallen.

Jack V. schrieb:
> → wenn ich aber vollständig verhindere, dass ein User lokal via Passwort
> Rootrechte erlangen kann, indem ich nämlich root nur den direkten Login
> mit sicherem Schlüssel erlaube, dann bin ich all diese Szenarien, in
> denen ein kompromittierter Useraccount durch Abgreifen des Passworts als
> Sprungbrett dient, schonmal los.

Dann benutzt der Angreifer eben einen lokalen Exploit, die sind ja auch 
nicht sooo selten. Daher, wie gesagt: wenn ein Useraccount 
kompromittiert wurde, ist der Drops schon gelutscht, und es ist zu spät!

> Denn entgegen deiner Darstellung ist’s
> eben nicht schwer: wer Userrechte erlangt hat, kann die entsprechenden
> Änderungen vornehmen – ob nun PATH, ~/.bashrc oder irgendwas Anderes,
> ist dabei egal. Und wenn der User lokal zu Root werden kann, kann der
> Angreifer, der den Useraccount kompromittiert hat, das nunmal auch.

Der Angreifer muß erstmal die Rechte des richtigen Users erlangen. Und 
wenn der Angreifer $PATH manipulieren kann und Du sicherheitssensitive 
Programme nicht über deren absoluten Pfad aufrufst, die Shell also $PATH 
benutzt, dann kann er Dir auch ein gefaketes ssh(1)-, ssh-keygen(1), 
ssh-agent(1), gtksu(1), kdesu(1) oder <you name it> unterjubeln, und auf 
diese Weise Deine Paßworte oder eventuell sogar eine entschlüsselte 
Kopie Deines privaten SSH-Schlüssels abgreifen. Die Sicherheit der 
ganzen Angelegenheit steht und fällt also offensichtlich mit Deinem 
Useraccount -- und sudo(1) spielt dabei nur eine sehr überschaubare 
Rolle.

> Dass es nicht alle Nase lang passiert, liegt eher daran, dass es häufig
> nicht gar so leicht ist, überhaupt erstmal an den Useraccount zu kommen.

Mein Reden... ;-) ...und genau darum geht's ja.

Außerdem dürfen wir ja nicht vergessen, daß wir hier von zwei (2) 
Systemen reden: vom lokalen Admin-Desktop und vom Remote-Server, hier 
dem RasPi. Wenn der Desktop des Admins geknackt ist, ist es ohnehin 
vorbei mit der Sicherheit, denn wie oben schon gesagt: die Möglichkeiten 
des Angreifers zum Abgreifen von Paßworten sind in diesem Fall nahezu 
unbegrenzt und beileibe nicht auf sudo(1) beschränkt. Und mit Deiner 
Idee, root nur remote mit verschlüsseltem SSH Private Key reinzulassen, 
ist der Sicherheit deswegen nicht gedient. Etwas anderes wäre es mit 
einer MFA -- mit einem externen Authentifikator, in diesem Fall...

Übrigens wird der RasPi meines Wissens mit einem Standardbenutzer "pi" 
und einem Standardpaßwort "raspberry" ausgeliefert. Das finde ich 
wesentlich gravierender als die sudo(1)-Konfiguration, insbesondere aber 
in Kombination damit...

Hans schrieb im Beitrag #7143624:
> Da lieferst du gerade selbst das beste Argument dafür, dass ein direkter
> root Login gar kein Problem ist, da die zusätzliche Schickt eines
> Useraccounts nichts bringt.

Aha: weil es für den Angreifer mehrere Möglichkeiten zur 
Privilegienerweiterung gibt, wenn er bereits einen Useraccount kapern 
konnte, verzichten wir einfach anderswo auch noch auf ein höheres 
Schutzniveau...

> Ein T. schrieb:
>> sudo(1)
>
> Was soll eigentlich die schwachsinnige (1)? Richtig wäre sudo(8).

Auch wenn die meisten Linux-Distributoren die Manpage in die Sektion 8 
installieren, würde sie korrekt in Sektion 1 einsortiert -- wie die 
Manpage von su(1).

Ein T. schrieb:
>> Ein T. schrieb:
>>> sudo(1)
>>
>> Was soll eigentlich die schwachsinnige (1)? Richtig wäre sudo(8).
>
> Auch wenn die meisten Linux-Distributoren die Manpage in die Sektion 8
> installieren, würde sie korrekt in Sektion 1 einsortiert -- wie die
> Manpage von su(1).

Nö. Wir haben doch gerade gelernt, dass nur ein sorgfältig 
konfiguriertes sudo ein gutes sudo ist. Also (8). Ganz richtig wäre (1) 
und (8), wozu gibt es SEE ALSO.

Und? Ich bin sicher, dass auch andere Leute als der TE aus diesem Thread 
Nutzen ziehen konnten.

Bauform B. schrieb:
> Nö. Wir haben doch gerade gelernt, dass nur ein sorgfältig
> konfiguriertes sudo ein gutes sudo ist. Also (8). Ganz richtig wäre (1)
> und (8), wozu gibt es SEE ALSO.

IMHO wären die Sektionen 1 für sudo(1) und sudoreplay(1), sowie 8 für 
visudo(8) korrekt. Aber ich glaube, das hat in diesem Thread nicht viel 
zu suchen.