Die Technik ist sehr sinnvoll und sollte massiv eingesetzt werden. Autorisierte Nutzer sollten signierte Pakete aus gesicherten Quellen installieren dürfen. Bei einem Serversystem ist dies zwar nicht der Fall und sollte default off sein, bei einem Desktop System wo der Administrator auch der Benutzer ist und weiß was er macht, sollte in der Installation diese Option klar gewährt werden.
Bitte beachten: Es ging im signierte Pakete aus geprüften Quellen.
"bei einem Desktop System wo der Administrator auch der Benutzer ist und weiß was er macht, sollte in der Installation diese Option klar gewährt werden."
Sowas kann man aber auch nur bei Linux behaupten, und auch da eigentlich immer weniger
Es geht um signierte Pakete geprüfter Quellen. Das nennt man Komfort. Windows oder OS X bieten sowas nicht.
Der Laie der sich mit Paketinstallationen das System zerlegt weil er einfach keine Ahnung davon hat tut dies auch wenn er vor sein root pw eingeben muss.
Ein ausnutzbarer Root-Exploit in einem der drölftausend signierten Pakete und schon hat ein 08/15-Anwender Vollzugriff auf das System. Die Sicherheit des Systems wird massiv beeinträchtigt wenn plötzlich jedes signierte Paket eine Gefahr darstellt, unabhängig davon ob es überhaupt installiert ist oder nicht. Die Anzahl an Fehlerquellen wird dadurch um ein vielfaches erhöht.
wenn ein paket einen exploit aufweist, hast du mit und ohne passwort das problem, weil du im falle der installation das sowieso nicht weißt und wenn ein exploit bekannt sein sollte, darf das paket nicht installiert werden können. wie oben schon jmd. geschrieben hat, die meisten anweder geben einfach das passwort an, getreu dem motto "wird schon passen"... das passwort gaukelt eine pseudo-sicherheit vor!
Solange der Exploit bekannt, aber nicht behoben ist, kann jeder das entsprechende Paket installieren und ausnutzen. Das ist der Punkt.
Klar können Passwörter Sicherheit vorgaukeln, aber in der Regel haben Nutzer kein Root-Passwort, könnten jedoch dennoch derartige Lücken ausnutzen wenn sie (fast) jedes beliebige Paket installieren können.
Da gebe ich dir voll recht. Verstehe nicht was das ganze Geschrei soll. Kommt mir nen bisschen wie Wichtigtuerei und komischer "das war schon immer so" Konservatismus vor.
Von chefkoch123 am Mo, 23. November 2009 um 07:43 #
Das Sicherheitskonzept macht schon Sinn so wie es ist. Wenn der User selbst die Software installieren darf, muss er nur noch eine falsche Website aufrufen, die dann das passende Packet mit Exploid nachlädt und schon ist das System kompromitiert. Zugegeben - es ist unwahrscheinlich, weil die Lücken die bekannt werden genauso schnell auch wieder geschlossen werden - aber nicht jeder hält sein System aktuell. Außerdem ist es nur eine Möglichkeit von vielen wie sich diese Art der "Sicherheitsaufweichung" ausnutzen liese.
"... muss er nur noch eine falsche Website aufrufen, die dann das passende Packet mit Exploid nachlädt und schon ist das System kompromitiert." Webseiten können keine Pakete nachladen. Es gibt zwar ein PackageKit Browserplugin, aber das ist nicht von der laxen Sicherheitsrichtiline bertroffen.
Signierte Pakete hin oder her. Ich würde auch nicht wollen das irgendjemand Pakete auf meinem System installieren kann, während ich mal nicht vor dem Rechner sitze.
Auf meinem System hab ich nur Sicherheitsupdates ohne Passwort erlaubt, alles andere soll gefälligst nach einer Passwortabfrage schreien.
Was wirklich praktisch wäre ist ein zusätzliches Paketmanagemant pro user das nur das jeweilige $HOME voll müllt.
Man kann ja auch jetz schon ohne Compiler problemlos ein (deb,rpm,tgz) manuell in $HOME installieren. So ein Paketmanagement wäre halt einfach praktischer.
Wem das zu viel Platz verschwendet kann ja z.b. ein quota einrichten.
Von Verwundert am Mo, 23. November 2009 um 01:44 #
> Wenn du nicht vor dem Rechner sitzt, solltest du ihn sperren. > Sonst könnte bei dir auch jemand Dokumente, Mails, etc. einsehen und/oder > löschen.
Wie soll dass ein User der mit SEINEM Account eingeloggt ist verdammt nochmal können? Leute die noch nie einen Rechner gesehen haben wo es mehr als einen Account gibt sollten bei so Themen einfach dei Klappe halten!
Es macht einen gewaltigen Unterschied ob jemand mit SEINEM Account auf einer Maschine arbeiten kann oder gleich pakete installieren - Solange ich die betreue gibt es genau einen Menschen der darauf Pakete installiert und das ist der dem ich am Morgen die Zähne putze
> Wie soll dass ein User der mit SEINEM Account eingeloggt ist verdammt nochmal können?
Wie kommst du darauf, dass der User seinen eigenen Account bräuchte? Schon mal darüber nachgedacht, dass manche Leute ihren Arbeitsplatz verlassen und dabei vergessen, sich abzumelden oder zumindest den Rechner zu sperren? Und wenn derjenige das Recht hat, Pakete zu installieren, kann das Recht auch jeder, der am ungesicherten Rechner vorbeikommt, ausüben.
> Es macht einen gewaltigen Unterschied ob jemand mit SEINEM Account auf einer Maschine arbeiten kann oder gleich pakete installieren - Solange ich die betreue gibt es genau einen Menschen der darauf Pakete installiert und das ist der dem ich am Morgen die Zähne putze
Von Verwundert am Mo, 23. November 2009 um 12:58 #
> Wie kommst du darauf, dass der User seinen eigenen Account bräuchte?
Weil kein normaler Mensch andere mit seinem Account arbeiten lässt
> Schon mal darüber nachgedacht, dass manche Leute ihren Arbeitsplatz verlassen > und dabei vergessen, sich abzumelden oder zumindest den Rechner zu sperren?
Und das ist wo ein Problem des OS????
> Und wenn derjenige das Recht hat, Pakete zu installieren, kann das > Recht auch jeder, der am ungesicherten Rechner vorbeikommt, ausüben.
Darum gehts aber beim ganzen Thema nicht du Troll
> Dann setz die PolicyKit-Regel entsprechend!
DARUM gehts beim Thema dass die verdammt nochmal nach dem Setup nicht so eingerichtet zu sein hat dass man sie erst vernünftig setzen muss, wir sind hier nicht bei Windows verdammt noch mal
Wenn ein User - egal ob nun fälschlicherweise oder nicht - eine Quelle als vertrauenswürdig einstuft, dann wird er am Ende diese auch zur Installation verwenden, vollkommen egal, ob nun mit Passwort oder ohne.
Das "Ergebnis" wird also dann so oder so dasselbe sein.
Trotzdem finde ich die den Zwang zur Passworteingabe gut, genauso, wie ich persönlich sowieso finde, dass man Passwörter z.B. auch nicht irgendwo speichern sollte, also z.B. im browser, weils ja so bequem ist und so schnell geht.
Ich selber kann mir zwar auch nicht alle PW merken, dafür sinds zuviele, aber ich habe hier neben dem PC dafür eben eine Liste mit den Login-Daten für mehr als ein Dutzend Seiten, darunter auch seltener gebrauchte, wie die für Online-Shops und Co.
Und diese Liste ist aus Papier. - Ob nun etwas antiqiert oder nicht: Es funktioniert. :-)
Ehrlich gesagt war mein "Tip" mit den Zetteln am Bildschirmrand nicht ganz ernst gemeint und sollte lediglich illustrieren, dass Sicherheit durch Passwoerter sehr oft als Gaengelung des Benutzers angesehen werden, was in Firmen o.ae. durchaus fatal ist. Natuerlich sollte niemand seine Passwoerter auf Zetteln am Bildschirm fuer alle sichtbar befestigen. Privat zu hause ist das wahrscheinlich weniger problematisch.
> Ich selber kann mir zwar auch nicht alle PW merken, dafür sinds zuviele, aber ich habe hier neben dem PC dafür eben eine Liste mit den Login-Daten für mehr als ein Dutzend Seiten, darunter auch seltener gebrauchte, wie die für Online-Shops und Co.
Als ich noch jung war habe ich es auch so gemacht. Heute nutze ich KWallet, man lernt ja dazu.
Es kann sicherer sein die Passwörter gespeichert zu haben als sie einzutippen. Wenn man sich in öffentlichen Räumen befindet weiß man nicht ob da irgendwo eine Kamera steht. Auch merkt man es nicht so leicht ob einer beim eintippen zu schaut.
Das ist schon seltsam: Bei Vista hatten sich die Benutzer darüber aufgeregt, wenn das System bei jeder Änderung am System nach Erlaubniss fragte, bei Fedora regen sich die Anwender auf, wenn es das nicht tut.
Eine Abfrage die ausser Fragen genau gar nix tut nützt nix und wird abgeschaltet und eine nichtvorhandene Nachfrage die das Sicherheitskonzept aushebelt sind ungefähr gleicher Mist. Wenn man danach gefragt wird ein Passwort eingeben und dann installieren ist nicht so furchtbar stressig dass da irgendwo ein Kompromiss zu Lasten eines gut funktionierenden Sicherheitssystems notwendig wird.
Hmm wie wäre es denn wenn man das Feature per Häckchen aktiveren/ deaktivieren, leider finde ich die Methode mit Google und datei blabala editieren zu nervig. Policies müssen übersichtlich und einfach zu handhaben sein. Wenn das so wäre würde auch niemand rumquaken. Da sehe ich überhaupt das größte Problem bei Fedora. SELinuxintegration schön und gut, aber in der Praxis sind die meisten Admins doch recht faul, daher braucht es ein Konzept das sich leicht erstellen und dann auch noch einfach replizieren lässt. Schön wäre doch ein security-center in dem man div. Einstellungen vornimmt, z.b Root account aktivieren deaktiveren, root per ssh oder X (de)aktivieren und gleichzeitig die Firewall. Im Moment ist das alles sehr nervig, für ein privates System wird man sich die Mühe nicht machen weil die GUI fehlt und wer 400 Server hat, der wird zumindest (mal wieder!) über handgefrickelte Skripte das machen dürfen (leider in der Praxis auch viele zu faul!)
>SELinuxintegration schön und gut, aber in der Praxis sind die meisten Admins doch recht faul ... Glaube ich nicht. Es wird wohl eher daran liegen, dass SELinux in der Praxis oft totaler overkill ist. -> apparmor (Wer will, kann auch gerne Yast dafür nutzen.
http://opensuse.blip.tv/ AppArmor in der Paxis: http://blip.tv/file/2389093
Linux ist nicht Windows. Ist das so schwer zu verstehen? Wenn ich Windowsgepflogenheiten frönen möchte, dann brauche ich eigentlich kein Linux mehr zu benutzen.
Immer dieses Totschlagargument. Das die Möglichkeit besteht, das Feature X in Windows sinnvoller implementiert ist als in Linux besteht auf gar keinen Fall?
Welches "Feature" meinst du denn? Meinst du mit "Feature" etwa den AdminAccount als Standard User zu missbrauchen? Klar wird der User DANN nicht mehr so oft gefragt(!)
Man sollte bei der Installation gefragt werden, ob man eine Workstation Installation (mit unpriviligierten Benutzern) oder eine Desktop Installation vornimmt - oder das Feature auf bestimmte Benutzer beschränken (ließe sich z.b. über Gruppen machen)
Du soltest den Kontext der zu meiner Aussage führte beachten. (das Feature X in Windows) Also was hat dein Beitrag damit zu tun?
Ungeachtet dessen halte ich deinen Vorschlag für Stuss. Denn du kannst nun als User (ohne "extra" PW) ein ftp Server installieren, aber administrieren darfst du ihne immer noch nicht. Zudem ist es für Linux/Unix Anfänger sicherlich besser, wenn sie sich darüber bewust werden, dass sie NUN (PW Abfrage) etwas Systemweites ändern.
Und wenn du wirklich unbedingt ohne extra PW installieren willst, dann mach es mit sudo und gut ist. Aber sowas per default erlauben halte ich für schwachsinn (zb ftp server(!) ).
Und über die Sicherheitslücke bei Ubuntu redet natürlich keiner. Dort ist nämlich das Userpasswort in der Standardkonfiguration identisch mit dem sudo-Passwort. Desweiteren kann man dort das sudo-Kommando sogar ohne Passwort benutzen, wenn kurze Zeit vorher schonmal das sudo-Passwort benutzt wurde. Ein offenes Scheunentor für Maleware.
Naja, dass sudo für 15 Minuten kein Kennwort verlangt, kann man schon als Sicherheitslücke betrachten. Man sollte nach Abschluss der Administrationsarbeiten "sudo -K" ausführen, damit anschließend (innerhalb des 15-Min.-Zeitintervalls) ausgeführte Shell-Skripts oder Programme nicht heimlich sudo zur Erlangungen von root-Rechten ausführen können.
Von Verwundert am Mo, 23. November 2009 um 15:32 #
> Und über die Sicherheitslücke bei Ubuntu redet natürlich keiner.
Die da wäre?
> Dort ist nämlich das Userpasswort in der Standardkonfiguration identisch > mit dem sudo-Passwort.
Ach? RTFM! Welches Passwort sollte den sudo von heute auf morgen abfragen wenn es a) keinen anderen User gibt unter Ubuntu und b) sudo IMMER UND ÜBERALL das Passwort des aktuellen Users abfragt der dazu auch in der /etc/sudoers stehen muss?
> Desweiteren kann man dort das sudo-Kommando sogar ohne Passwort benutzen, > wenn kurze Zeit vorher schonmal das sudo-Passwort benutzt wurde. Ein offenes > Scheunentor für Maleware.
Das nächste mal bitte auf dem Weg vom Stein unter dem du hevorgekrochen bist bis zum Forum erstmal Manuals lesen oder einfach ruhig bleiben
Dass man das alles umkonfigurieren kann, ist mir klar. Aber man kann nicht von jedem User erwarten, dass er so weit denkt, die passende Doku liest und dann sein Ubuntu entsprechend umkonfiguriert. Und jetzt kommst du, Dummerchen!
Von mechanicus am Mo, 23. November 2009 um 08:45 #
Für den Privat-PC mit einem User mag das ja vielleicht noch angehen, aber wenn wie bei Linux üblich mehrere Nutzer einen Account haben, möchte ich dieses Verhalten nicht.
Es gibt mehrere Beispiele in der Vergangenheit, wo neuere Pakete anders reagierten als erwartet. Diese wurden dann nach der Erprobung nicht im Produktivsystem installiert.
Wenn ich mir vorstelle, daß da jeder rangehen kann, bekomme ich eine Gänsehaut.
Ich verstehe nicht, weshalb man diese "Lösung" überhaupt erst umgesetzt hat - für User in einer admin-Gruppe wäre das ja noch OK, per default den ersten Benutzer in diese Gruppe - so ähnlich wie sudo z.B. bei Ubuntu verwendet wird...
Bitte beachten: Es ging im signierte Pakete aus geprüften Quellen.
Sowas kann man aber auch nur bei Linux behaupten, und auch da eigentlich immer weniger
Der Laie der sich mit Paketinstallationen das System zerlegt weil er einfach keine Ahnung davon hat tut dies auch wenn er vor sein root pw eingeben muss.
Klar können Passwörter Sicherheit vorgaukeln, aber in der Regel haben Nutzer kein Root-Passwort, könnten jedoch dennoch derartige Lücken ausnutzen wenn sie (fast) jedes beliebige Paket installieren können.
Wenn der User selbst die Software installieren darf, muss er nur noch eine falsche Website aufrufen, die dann das passende Packet mit Exploid nachlädt und schon ist das System kompromitiert.
Zugegeben - es ist unwahrscheinlich, weil die Lücken die bekannt werden genauso schnell auch wieder geschlossen werden - aber nicht jeder hält sein System aktuell.
Außerdem ist es nur eine Möglichkeit von vielen wie sich diese Art der "Sicherheitsaufweichung" ausnutzen liese.
Webseiten können keine Pakete nachladen. Es gibt zwar ein PackageKit Browserplugin, aber das ist nicht von der laxen Sicherheitsrichtiline bertroffen.
Auf meinem System hab ich nur Sicherheitsupdates ohne Passwort erlaubt, alles andere soll gefälligst nach einer Passwortabfrage schreien.
Man kann ja auch jetz schon ohne Compiler problemlos ein (deb,rpm,tgz) manuell in $HOME installieren. So ein Paketmanagement wäre halt einfach praktischer.
Wem das zu viel Platz verschwendet kann ja z.b. ein quota einrichten.
Wenn du nicht vor dem Rechner sitzt, solltest du ihn sperren. Sonst könnte bei dir auch jemand Dokumente, Mails, etc. einsehen und/oder löschen.
> Sonst könnte bei dir auch jemand Dokumente, Mails, etc. einsehen und/oder
> löschen.
Wie soll dass ein User der mit SEINEM Account eingeloggt ist verdammt nochmal können?
Leute die noch nie einen Rechner gesehen haben wo es mehr als einen Account gibt sollten bei so Themen einfach dei Klappe halten!
Es macht einen gewaltigen Unterschied ob jemand mit SEINEM Account auf einer Maschine arbeiten kann oder gleich pakete installieren - Solange ich die betreue gibt es genau einen Menschen der darauf Pakete installiert und das ist der dem ich am Morgen die Zähne putze
Und jetzt geh wo anders hin trollen!
Wie kommst du darauf, dass der User seinen eigenen Account bräuchte?
Schon mal darüber nachgedacht, dass manche Leute ihren Arbeitsplatz verlassen und dabei vergessen, sich abzumelden oder zumindest den Rechner zu sperren? Und wenn derjenige das Recht hat, Pakete zu installieren, kann das Recht auch jeder, der am ungesicherten Rechner vorbeikommt, ausüben.
> Es macht einen gewaltigen Unterschied ob jemand mit SEINEM Account auf einer Maschine arbeiten kann oder gleich pakete installieren - Solange ich die betreue gibt es genau einen Menschen der darauf Pakete installiert und das ist der dem ich am Morgen die Zähne putze
Dann setz die PolicyKit-Regel entsprechend!
Weil kein normaler Mensch andere mit seinem Account arbeiten lässt
> Schon mal darüber nachgedacht, dass manche Leute ihren Arbeitsplatz verlassen
> und dabei vergessen, sich abzumelden oder zumindest den Rechner zu sperren?
Und das ist wo ein Problem des OS????
> Und wenn derjenige das Recht hat, Pakete zu installieren, kann das
> Recht auch jeder, der am ungesicherten Rechner vorbeikommt, ausüben.
Darum gehts aber beim ganzen Thema nicht du Troll
> Dann setz die PolicyKit-Regel entsprechend!
DARUM gehts beim Thema dass die verdammt nochmal nach dem Setup nicht so eingerichtet zu sein hat dass man sie erst vernünftig setzen muss, wir sind hier nicht bei Windows verdammt noch mal
Also wo ist jetzt genau dein Problem alter?
Wenn ein User - egal ob nun fälschlicherweise oder nicht - eine Quelle als vertrauenswürdig einstuft, dann wird er am Ende diese auch zur Installation verwenden, vollkommen egal, ob nun mit Passwort oder ohne.
Das "Ergebnis" wird also dann so oder so dasselbe sein.
Trotzdem finde ich die den Zwang zur Passworteingabe gut, genauso, wie ich persönlich sowieso finde, dass man Passwörter z.B. auch nicht irgendwo speichern sollte, also z.B. im browser, weils ja so bequem ist und so schnell geht.
Ich selber kann mir zwar auch nicht alle PW merken, dafür sinds zuviele, aber ich habe hier neben dem PC dafür eben eine Liste mit den Login-Daten für mehr als ein Dutzend Seiten, darunter auch seltener gebrauchte, wie die für Online-Shops und Co.
Und diese Liste ist aus Papier. - Ob nun etwas antiqiert oder nicht: Es funktioniert. :-)
Sebalin.
Hast Du dazu einen tip?
"Nach ein paar Tagen laesst die Klebkraft nach.
Hast Du dazu einen tip?"
oder KNotes
Notizbuch mit allen Passwörtern + Abschließbare Schreibtischschublade. Dann erspart man sich den Unsinn mit den Post-It-Zetteln.
> oder KNotes
Super, dann kann man die Passwörter auch gleich alle im jeweiligen Programm abspeichern lassen. Das ist bequemer und kein bisschen unsicherer.
Als ich noch jung war habe ich es auch so gemacht.
Heute nutze ich KWallet, man lernt ja dazu.
Die Einstufung einer Quelle als vertrauenswürdig war nach wie vor an das root-Passwort geknüpft, also dem Administrator vorbehalten.
Da sehe ich überhaupt das größte Problem bei Fedora. SELinuxintegration schön und gut, aber in der Praxis sind die meisten Admins doch recht faul, daher braucht es ein Konzept das sich leicht erstellen und dann auch noch einfach replizieren lässt. Schön wäre doch ein security-center in dem man div. Einstellungen vornimmt, z.b
Root account aktivieren deaktiveren, root per ssh oder X (de)aktivieren und gleichzeitig die Firewall. Im Moment ist das alles sehr nervig, für ein privates System wird man sich die Mühe nicht machen weil die GUI fehlt und wer 400 Server hat, der wird zumindest (mal wieder!) über handgefrickelte Skripte das machen dürfen (leider in der Praxis auch viele zu faul!)
>SELinuxintegration schön und gut, aber in der Praxis sind die meisten Admins doch recht faul ...
Glaube ich nicht. Es wird wohl eher daran liegen, dass SELinux in der Praxis oft totaler overkill ist.
-> apparmor (Wer will, kann auch gerne Yast dafür nutzen.
http://opensuse.blip.tv/
AppArmor in der Paxis:
http://blip.tv/file/2389093
Ist das so schwer zu verstehen?
Wenn ich Windowsgepflogenheiten frönen möchte, dann brauche ich eigentlich kein Linux mehr zu benutzen.
Meinst du mit "Feature" etwa den AdminAccount als Standard User zu missbrauchen?
Klar wird der User DANN nicht mehr so oft gefragt(!)
Oder welches "Feature" meinst du?
Also was hat dein Beitrag damit zu tun?
Ungeachtet dessen halte ich deinen Vorschlag für Stuss. Denn du kannst nun als User (ohne "extra" PW) ein ftp Server installieren, aber administrieren darfst du ihne immer noch nicht.
Zudem ist es für Linux/Unix Anfänger sicherlich besser, wenn sie sich darüber bewust werden, dass sie NUN (PW Abfrage) etwas Systemweites ändern.
Und wenn du wirklich unbedingt ohne extra PW installieren willst, dann mach es mit sudo und gut ist. Aber sowas per default erlauben halte ich für schwachsinn (zb ftp server(!) ).
Danke!
Die da wäre?
> Dort ist nämlich das Userpasswort in der Standardkonfiguration identisch
> mit dem sudo-Passwort.
Ach?
RTFM!
Welches Passwort sollte den sudo von heute auf morgen abfragen wenn es a) keinen anderen User gibt unter Ubuntu und b) sudo IMMER UND ÜBERALL das Passwort des aktuellen Users abfragt der dazu auch in der /etc/sudoers stehen muss?
> Desweiteren kann man dort das sudo-Kommando sogar ohne Passwort benutzen,
> wenn kurze Zeit vorher schonmal das sudo-Passwort benutzt wurde. Ein offenes
> Scheunentor für Maleware.
Das nächste mal bitte auf dem Weg vom Stein unter dem du hevorgekrochen bist bis zum Forum erstmal Manuals lesen oder einfach ruhig bleiben
Es gibt mehrere Beispiele in der Vergangenheit, wo neuere Pakete anders reagierten als erwartet.
Diese wurden dann nach der Erprobung nicht im Produktivsystem installiert.
Wenn ich mir vorstelle, daß da jeder rangehen kann, bekomme ich eine Gänsehaut.