noisefloor
Anmeldungsdatum: 6. Juni 2006
Beiträge: 29567
|
Hallo,
Mein Versuch eine Art Fußnote zu gestalten "Man kann sich davor schützen ..." ist irgendwie gescheitert.
Wir benutzen ja auch grundsätzlich keine... BTW, den Abschnitt mit dem BIOS schützen und hacken finde ich ein wenig... übertrieben. Sollten wir den nicht noch etwas "harmloser" Schreiben? Gruß, noisefloor
|
kaputtnik
Anmeldungsdatum: 31. Dezember 2007
Beiträge: 9245
|
Sehr schön. Ein paar Dinge sind mir aufgefallen:
" So sehr sich Susi auch mit dem System auskennen mag - sie kann Stefans Dateien nicht löschen oder lesen, solange dieser ihr die Dateien nicht zugänglich macht." → Der Satz ist mißverständlich: Mit "dieser" ist der Admin gemeint, nicht Stefan. "Typische Unixsysteme stehen z.B. in Universitäten herum." → Muss das "herum" sein? 😉 Zur besseren Übersicht sollte man die zwei Teile in Allegemeines zur Sicherheit mit Überschriften abgrenzen. ZB: "Server" und "Privatsystem" "Daher bitte niemals unter der grafischen Oberfläche als Benutzer root anmelden!" Warum hier allgemein "grafische Benutzeroberfläche" und oberhalbr im Artikel gehts nur ums Surfen und unten wird trotz der Warnung beschrieben, wie man Root unter der grafischen Benutzeroberfläche wird? Das passt iwie nicht. In der "Achtungsbox" im Abschnitt Baustelle/sudo (Abschnitt „Sudo-Der-Standard-unter-Ubuntu“): Dort wird verlangt, das man sich mittels gksudo rootrechte in der Gui holen soll, im ganzen Rest des Artikels wird nur von gksu gesprochen. Was nu: gksu oder gksudo? Wo liegen die Unterschiede? " (Hintergrund ist, dass sudo normalerweise nicht die Umgebungsvariable HOME verändert. Dadurch werden eventuell zugriffsbeschränkte Dateien im Homeverzeichnis des Nutzers erzeugt, die später von den Programmen nicht mehr verändert werden können, wenn diese ohne sudo laufen.)" Die Begründung, oder der Hintergrund, ist in meinen Augen ein wenig schwach. Kann man nicht etwas drastischeres finden? Oder die Auswirkungen drastischer beschreiben?
Ich denke der Teil kann gestrichen werden. Von dem Problem mit k3b habe ich schon ewig nichts mehr gehört.
|
user_unknown
Anmeldungsdatum: 10. August 2005
Beiträge: 17586
Wohnort: Berlin
|
kaputtnik schrieb: Sehr schön. Ein paar Dinge sind mir aufgefallen:
" So sehr sich Susi auch mit dem System auskennen mag - sie kann Stefans Dateien nicht löschen oder lesen, solange dieser ihr die Dateien nicht zugänglich macht." → Der Satz ist mißverständlich: Mit "dieser" ist der Admin gemeint, nicht Stefan.
Nein, es ist wirklich Stefan gemeint. Ein User kann anderen Usern Zugriff auf seine Daten gewähren.
Das soll dem ganzen die feierliche Würde nehmen, und mehr die Meinung befördern, daß diese letztlich auch nur mit Wasser kochen.
Was mir nicht recht gelungen ist, ist, darzustellen, wo dieser root herkommt. Es geht nicht darum einem Admin in der Uni seinen Job zu erklären, sondern dem User an einem Einzelplatzrechner zu erklären, daß das System, mit dem er umgeht, aus einer Multiuserumgebung abstammt (daß es auch heute noch so eingesetzt wird, das ist so, aber derjenige wird mehr Unterrichtsmaterial als unser Wiki benötigen, sondern soll sich gefälligst ein Buch kaufen). Damit man das große System versteht wollte ich den Blick auf die Entstehungsgeschichte werfen, damit man sich seine Linuxwelt besser erklären kann. Dann geht es aber recht holprig um sudo - die gksu(do)s und Anverwandte, und daß man nicht dies und das soll - es ist nicht mehr aus einem Guss.
"Daher bitte niemals unter der grafischen Oberfläche als Benutzer root anmelden!" Warum hier allgemein "grafische Benutzeroberfläche" und oberhalbr im Artikel gehts nur ums Surfen und unten wird trotz der Warnung beschrieben, wie man Root unter der grafischen Benutzeroberfläche wird? Das passt iwie nicht.
Ja, da bin ich auch mehrfach gestolpert, und habe erwartet, daß eine Erklärung kommt, wieso man nicht als root unter grafischer Oberfläche arbeiten soll, aber dann kommt, daß man nicht mit sudo, sondern mit 'gksu' als root unter d. grafischen Oberfläche arbeiten soll. Vorher stand dort, daß das Arbeiten als Root gefährlich sei, aber das Arbeiten als Root ist nicht gefährlich. Root kann zwar alles löschen, aber alles, was wirklich wertvoll ist, kann der User selbst löschen - abgesehen von Multiusersystemen, die es in Familien ja sicher auch ein paar Mal gibt, wo man die Daten der anderen User als Root natürlich mitgefährdet, wenn man etwas falsch macht.
Da bin ich leider auch nicht firm. Alle 2 Jahre mache ich mal ein
gksu edit /etc/fstab - da lernt man nicht viel. ☺
" (Hintergrund ist, dass sudo normalerweise nicht die Umgebungsvariable HOME verändert. Dadurch werden eventuell zugriffsbeschränkte Dateien im Homeverzeichnis des Nutzers erzeugt, die später von den Programmen nicht mehr verändert werden können, wenn diese ohne sudo laufen.)" Die Begründung, oder der Hintergrund, ist in meinen Augen ein wenig schwach. Kann man nicht etwas drastischeres finden? Oder die Auswirkungen drastischer beschreiben?
Die Begründung soll nicht in erster Linie stark oder schwach, sondern richtig sein, oder? Wenn Du mitten in der Arbeit die Fontgröße in einem Programm ändern willst, und es geht nicht mehr, weil sudo zuletzt mit dem Programm gearbeitet hat, und die Datei jetzt für Dich nicht mehr beschreibbar ist, das ist schon sehr nervig - Du kommst aus dem Arbeitsfluß raus, überlegst einen Bugreport zu schreiben, suchst bei ubuntuusers, ob Du der erste bist, dem das auffällt ...
Ich hänge auch nicht dran. ☺
|
user_unknown
Anmeldungsdatum: 10. August 2005
Beiträge: 17586
Wohnort: Berlin
|
noisefloor schrieb: Hallo,
Mein Versuch eine Art Fußnote zu gestalten "Man kann sich davor schützen ..." ist irgendwie gescheitert.
Wir benutzen ja auch grundsätzlich keine... BTW, den Abschnitt mit dem BIOS schützen und hacken finde ich ein wenig... übertrieben. Sollten wir den nicht noch etwas "harmloser" Schreiben?
harmloser? Ich hätte es gerne zur Seite geschoben, weil es zu umfangreich wird, die Diskussionen aber gerne darauf hinauslaufen, und man es so abkürzen könnte. Viele User sind überrascht wie leicht man an Ihre Daten kommt, wo sie doch ständig von diesen Passwortabfragen heimgesucht und drangsaliert werden. Und dann schützt das alles nicht mal davor, um von der eigenen Tochter gehackt zu werden? Man kann da den Leuten nur möglichst früh reinen Wein einschenken.
|
user_unknown
Anmeldungsdatum: 10. August 2005
Beiträge: 17586
Wohnort: Berlin
|
Am ehesten schien mir die Vorlage "Hinweis" für diese Anmerkung geeignet - in dezentem Grau drängelt sie sich nicht so nach vorne.
|
kaputtnik
Anmeldungsdatum: 31. Dezember 2007
Beiträge: 9245
|
user unknown schrieb: kaputtnik schrieb: " So sehr sich Susi auch mit dem System auskennen mag - sie kann Stefans Dateien nicht löschen oder lesen, solange dieser ihr die Dateien nicht zugänglich macht." → Der Satz ist mißverständlich: Mit "dieser" ist der Admin gemeint, nicht Stefan.
Nein, es ist wirklich Stefan gemeint. Ein User kann anderen Usern Zugriff auf seine Daten gewähren.
❓ Durch verraten des Passwortes?
Das soll dem ganzen die feierliche Würde nehmen, und mehr die Meinung befördern, daß diese letztlich auch nur mit Wasser kochen.
Liest sich aber sehr ... hmmm.... ... und welche feierlich Würde?
Was mir nicht recht gelungen ist, ist, darzustellen, wo dieser root herkommt. Es geht nicht darum einem Admin in der Uni seinen Job zu erklären, sondern dem User an einem Einzelplatzrechner zu erklären, daß das System, mit dem er umgeht, aus einer Multiuserumgebung abstammt (daß es auch heute noch so eingesetzt wird, das ist so, aber derjenige wird mehr Unterrichtsmaterial als unser Wiki benötigen, sondern soll sich gefälligst ein Buch kaufen). Damit man das große System versteht wollte ich den Blick auf die Entstehungsgeschichte werfen, damit man sich seine Linuxwelt besser erklären kann.
Dann schreib doch "Mehrbenutzersystem". Vergleich: Dateisystem (Abschnitt „Warum-braucht-Linux-ein-spezielles-Dateisystem“)
Dann geht es aber recht holprig um sudo - die gksu(do)s und Anverwandte, und daß man nicht dies und das soll - es ist nicht mehr aus einem Guss.
Du meinst das ganze root-Konzept?
"Daher bitte niemals unter der grafischen Oberfläche als Benutzer root anmelden!" Warum hier allgemein "grafische Benutzeroberfläche" und oberhalbr im Artikel gehts nur ums Surfen und unten wird trotz der Warnung beschrieben, wie man Root unter der grafischen Benutzeroberfläche wird? Das passt iwie nicht.
Ja, da bin ich auch mehrfach gestolpert, und habe erwartet, daß eine Erklärung kommt, wieso man nicht als root unter grafischer Oberfläche arbeiten soll, aber dann kommt, daß man nicht mit sudo, sondern mit 'gksu' als root unter d. grafischen Oberfläche arbeiten soll.
Eine diesbezügliche Diskussion gabs neulich mal irgendwo. Tenor war, das man sich das dann angewöhnt und ständig als root unterwegs ist. Dies wurde als potenzielle Gefahr betrachtet.... BTW: Vllt wäre mal ein Artikel angebracht, der den Mythos "Das Root-konzept macht Linux sicher!" entzaubert bzw aufklärt.
Vorher stand dort, daß das Arbeiten als Root gefährlich sei, aber das Arbeiten als Root ist nicht gefährlich. Root kann zwar alles löschen, aber alles, was wirklich wertvoll ist, kann der User selbst löschen - abgesehen von Multiusersystemen, die es in Familien ja sicher auch ein paar Mal gibt, wo man die Daten der anderen User als Root natürlich mitgefährdet, wenn man etwas falsch macht.
Da bin ich leider auch nicht firm.
In Anbetracht der Tatsache, das im gesamten Wiki eigentlich immer gksudo verwendet wird (zB: Editor, pptpconfig,iceWM, Thunderbird/Installation ) , würde ich das hier auch gerne sehen wollen. Die zusätzliche Verwendung von gksu verwirrt sonst nur.
" (Hintergrund ist, dass sudo normalerweise nicht die Umgebungsvariable HOME verändert. Dadurch werden eventuell zugriffsbeschränkte Dateien im Homeverzeichnis des Nutzers erzeugt, die später von den Programmen nicht mehr verändert werden können, wenn diese ohne sudo laufen.)" Die Begründung, oder der Hintergrund, ist in meinen Augen ein wenig schwach. Kann man nicht etwas drastischeres finden? Oder die Auswirkungen drastischer beschreiben?
Die Begründung soll nicht in erster Linie stark oder schwach, sondern richtig sein, oder?
Ja klar, aber in dieser Form kann "man" sich kaum etwas darunter vorstellen... Wenn Du mitten in der Arbeit die Fontgröße in einem Programm ändern willst, und es geht nicht mehr, weil sudo zuletzt mit dem Programm gearbeitet hat, und die Datei jetzt für Dich nicht mehr beschreibbar ist, das ist schon sehr nervig
Eben, ein Beispiel fehlt...
Ich hänge auch nicht dran. ☺
Ausserdem gehört das eher in den K3b-Artikel.
|
user_unknown
Anmeldungsdatum: 10. August 2005
Beiträge: 17586
Wohnort: Berlin
|
kaputtnik schrieb: Oioioi - 100 Sachen! ☺ Ich will ja Feedback, aber doch nicht sooo viel. ☺
user unknown schrieb: kaputtnik schrieb: " So sehr sich Susi auch mit dem System auskennen mag - sie kann Stefans Dateien nicht löschen oder lesen, solange dieser ihr die Dateien nicht zugänglich macht." → Der Satz ist mißverständlich: Mit "dieser" ist der Admin gemeint, nicht Stefan.
Nein, es ist wirklich Stefan gemeint. Ein User kann anderen Usern Zugriff auf seine Daten gewähren.
❓ Durch verraten des Passwortes?
Nun - bei meinen früheren Distributionen war es so, daß ein User in der Primärgruppe 'users' war, wodurch alle User gegenseitig ihre Daten lesen konnten. Bei Ubuntu ist User x immer zuerst in der Gruppe x, und damit ist das Zugänglichmachen erstmal blockiert - mit chown kann man die Datei herschenken, aber hat dann selbst keinen guten Zugriff mehr. Man muß also root bitten eine Gruppe 'grafiker' anzulegen, die Personen a, b und c zu grafikern zu erklären, und kann dann ganze Verzeichnisse der Gruppe grafiker zuordnen, und dann können die anderen User auch darauf zugreifen.
Das soll dem ganzen die feierliche Würde nehmen, und mehr die Meinung befördern, daß diese letztlich auch nur mit Wasser kochen.
Liest sich aber sehr ... hmmm.... ... und welche feierlich Würde?
Dann mach's weg.
Was mir nicht recht gelungen ist, ist, darzustellen, wo dieser root herkommt. Es geht nicht darum einem Admin in der Uni seinen Job zu erklären, sondern dem User an einem Einzelplatzrechner zu erklären, daß das System, mit dem er umgeht, aus einer Multiuserumgebung abstammt (daß es auch heute noch so eingesetzt wird, das ist so, aber derjenige wird mehr Unterrichtsmaterial als unser Wiki benötigen, sondern soll sich gefälligst ein Buch kaufen). Damit man das große System versteht wollte ich den Blick auf die Entstehungsgeschichte werfen, damit man sich seine Linuxwelt besser erklären kann.
Dann schreib doch "Mehrbenutzersystem". Vergleich: Dateisystem (Abschnitt „Warum-braucht-Linux-ein-spezielles-Dateisystem“)
Du meinst ich soll das eine Wort schreiben, und dann fällt es dem User wie Schuppen von den Augen?
Dann geht es aber recht holprig um sudo - die gksu(do)s und Anverwandte, und daß man nicht dies und das soll - es ist nicht mehr aus einem Guss.
Du meinst das ganze root-Konzept?
Ich meine den Artikel - der ist nicht mehr aus einem Guss - war aber vor meinem Eingriff auch nicht besser.
"Daher bitte niemals unter der grafischen Oberfläche als Benutzer root anmelden!" Warum hier allgemein "grafische Benutzeroberfläche" und oberhalbr im Artikel gehts nur ums Surfen und unten wird trotz der Warnung beschrieben, wie man Root unter der grafischen Benutzeroberfläche wird? Das passt iwie nicht.
Ja, da bin ich auch mehrfach gestolpert, und habe erwartet, daß eine Erklärung kommt, wieso man nicht als root unter grafischer Oberfläche arbeiten soll, aber dann kommt, daß man nicht mit sudo, sondern mit 'gksu' als root unter d. grafischen Oberfläche arbeiten soll.
Eine diesbezügliche Diskussion gabs neulich mal irgendwo. Tenor war, das man sich das dann angewöhnt und ständig als root unterwegs ist. Dies wurde als potenzielle Gefahr betrachtet....
Es gibt nach dem Booten einen Loginscreen. Ich glaube der Artikel will sagen, daß man sich da nicht als root anmelden soll. Aber die Option gibt es eh nicht. Ein User müßte schon recht fortgeschritten sein (auf dem Pfad der Untugend) wenn er einen derartigen Account für Root eingerichtet hätte.
BTW: Vllt wäre mal ein Artikel angebracht, der den Mythos "Das Root-konzept macht Linux sicher!" entzaubert bzw aufklärt.
Ja sehr. Nur fragt sich dann, was Linux sicher macht. Ich würde auch sagen, daß die Trennung der Accounts und sudo die Sicherheit mitbefördern, aber sie sind nur ein Mosaiksteinchen, und eine zu simplifizierende Dartstellung wird dann falsch. Wenn root stundenlang Musik-CDs unter X hört besteht nicht eine magische Gefahr.
Da bin ich leider auch nicht firm.
In Anbetracht der Tatsache, das im gesamten Wiki eigentlich immer gksudo verwendet wird (zB: Editor, pptpconfig,iceWM, Thunderbird/Installation ) , würde ich das hier auch gerne sehen wollen. Die zusätzliche Verwendung von gksu verwirrt sonst nur.
Bitte - es ist ein Wiki - ☺ - ändere es!
" (Hintergrund ist, dass sudo normalerweise nicht die Umgebungsvariable HOME verändert. Dadurch werden eventuell zugriffsbeschränkte Dateien im Homeverzeichnis des Nutzers erzeugt, die später von den Programmen nicht mehr verändert werden können, wenn diese ohne sudo laufen.)" Die Begründung, oder der Hintergrund, ist in meinen Augen ein wenig schwach. Kann man nicht etwas drastischeres finden? Oder die Auswirkungen drastischer beschreiben?
Die Begründung soll nicht in erster Linie stark oder schwach, sondern richtig sein, oder?
Ja klar, aber in dieser Form kann "man" sich kaum etwas darunter vorstellen... Wenn Du mitten in der Arbeit die Fontgröße in einem Programm ändern willst, und es geht nicht mehr, weil sudo zuletzt mit dem Programm gearbeitet hat, und die Datei jetzt für Dich nicht mehr beschreibbar ist, das ist schon sehr nervig
Eben, ein Beispiel fehlt...
Sollen wir das nehmen?
Ich hänge auch nicht dran. ☺
Ausserdem gehört das eher in den K3b-Artikel.
Siehe oben - ein Wiki! ☺
|
kaputtnik
Anmeldungsdatum: 31. Dezember 2007
Beiträge: 9245
|
user unknown schrieb: kaputtnik schrieb: Oioioi - 100 Sachen! ☺ Ich will ja Feedback, aber doch nicht sooo viel. ☺
100 Sachen warens jetzt auch nicht 😉
user unknown schrieb: kaputtnik schrieb:
Nein, es ist wirklich Stefan gemeint. Ein User kann anderen Usern Zugriff auf seine Daten gewähren.
❓ Durch verraten des Passwortes?
Nun - bei meinen früheren Distributionen war es so, daß ein User in der Primärgruppe 'users' war, wodurch alle User gegenseitig ihre Daten lesen konnten. Bei Ubuntu ist User x immer zuerst in der Gruppe x, und damit ist das Zugänglichmachen erstmal blockiert - mit chown kann man die Datei herschenken, aber hat dann selbst keinen guten Zugriff mehr.
Man muß also root bitten eine Gruppe 'grafiker' anzulegen, die Personen a, b und c zu grafikern zu erklären, und kann dann ganze Verzeichnisse der Gruppe grafiker zuordnen, und dann können die anderen User auch darauf zugreifen.
Somit kann Stefan nicht den Zugriff gewähren, es sei denn er wäre gleichzeitig Admin, bzw in der Admin-Gruppe.
Dann mach's weg.
Ok...
Dann schreib doch "Mehrbenutzersystem". Vergleich: Dateisystem (Abschnitt „Warum-braucht-Linux-ein-spezielles-Dateisystem“)
Du meinst ich soll das eine Wort schreiben, und dann fällt es dem User wie Schuppen von den Augen?
😊 Naja, zumidest kann man sich mehr darunter vorstellen, als um den heißen Brei herum zu reden. Ich mach mal was...
Dann geht es aber recht holprig um sudo - die gksu(do)s und Anverwandte, und daß man nicht dies und das soll - es ist nicht mehr aus einem Guss.
Du meinst das ganze root-Konzept?
Ich meine den Artikel - der ist nicht mehr aus einem Guss - war aber vor meinem Eingriff auch nicht besser.
Ich dachte Du wolltest den "ganzen Artikel umbauen" (http://forum.ubuntuusers.de/post/2394867/) . 😉
"Daher bitte niemals unter der grafischen Oberfläche als Benutzer root anmelden!" Warum hier allgemein "grafische Benutzeroberfläche" und oberhalbr im Artikel gehts nur ums Surfen und unten wird trotz der Warnung beschrieben, wie man Root unter der grafischen Benutzeroberfläche wird? Das passt iwie nicht.
Ja, da bin ich auch mehrfach gestolpert, und habe erwartet, daß eine Erklärung kommt, wieso man nicht als root unter grafischer Oberfläche arbeiten soll, aber dann kommt, daß man nicht mit sudo, sondern mit 'gksu' als root unter d. grafischen Oberfläche arbeiten soll.
Eine diesbezügliche Diskussion gabs neulich mal irgendwo. Tenor war, das man sich das dann angewöhnt und ständig als root unterwegs ist. Dies wurde als potenzielle Gefahr betrachtet....
Es gibt nach dem Booten einen Loginscreen. Ich glaube der Artikel will sagen, daß man sich da nicht als root anmelden soll. Aber die Option gibt es eh nicht. Ein User müßte schon recht fortgeschritten sein (auf dem Pfad der Untugend) wenn er einen derartigen Account für Root eingerichtet hätte.
Nein, das glaube ich nicht. Gemeint ist tatsächlich, das man sich sich nur in Notfällen ein root-Gui besorgen sollte. Warum auch immer... ich persönlich habe nichts dagegen, wenn man sich per kdesudo dolphin kurzzeitig rootrechte besorgt, um bequem per Gui die Rechte an gewissen Dateien/Verzeichnissen ändert. Das alles unter "/" (ausser /~) dabei tabu ist, sollte klar sein. Vllt sollte man das so sagen... 😕
BTW: Vllt wäre mal ein Artikel angebracht, der den Mythos "Das Root-konzept macht Linux sicher!" entzaubert bzw aufklärt.
Ja sehr. Nur fragt sich dann, was Linux sicher macht. Ich würde auch sagen, daß die Trennung der Accounts und sudo die Sicherheit mitbefördern, aber sie sind nur ein Mosaiksteinchen, und eine zu simplifizierende Dartstellung wird dann falsch. Wenn root stundenlang Musik-CDs unter X hört besteht nicht eine magische Gefahr.
Leider fehlt mir für solch einen Artikel die Erfahrung bzw das Hintergrundwissen...
Bitte - es ist ein Wiki - ☺ - ändere es!
ok...
Eben, ein Beispiel fehlt...
Sollen wir das nehmen?
Rethorische Frage? 😉 Vorschlag:
kdesudo/gksudo ändert die Umgebungsvariable HOME auf den Pfad "/root". Somit werden programmspezifische Einstellungen (wie Zb Schriftgrößen, Fenstereinstellungen, ?? ...) dort abgespeichert und nicht im Homeordner des Users.
Bei Verwendung von sudo zeigt die Umgebungsvariable auf dem Homeordner des Benutzers und programmspezifische Einstellungen werden dort mit Rootrechten abgespeichert. Diese Einstellungen können dann vom Benutzer nicht mehr geändert werden.
Hmmm... is jetzt auch nicht "rund" 😊
|
user_unknown
Anmeldungsdatum: 10. August 2005
Beiträge: 17586
Wohnort: Berlin
|
kaputtnik schrieb:
Somit kann Stefan nicht den Zugriff gewähren, es sei denn er wäre gleichzeitig Admin, bzw in der Admin-Gruppe.
Erstens ist er das, ich kenne ihn. ☺ Zweitens: Ja, das muß irgendwann mal eingerichtet worden sein - da es ein Beispiel ist, kann das sein.
Ich dachte Du wolltest den "ganzen Artikel umbauen"
Ja, ich wollte mehr als nur die anfänglichen Punkte ändern, und habe so eine neue Einleitung geschrieben. Ich will aber nicht den Kern in der Mitte antasten, da ich mit gksu/gksudo/kdsu etc. nicht bewandert bin. Ich mache mein sudo und mein sudo su. Oder diese k3b-Geschichte.
Nein, das glaube ich nicht. Gemeint ist tatsächlich, das man sich sich nur in Notfällen ein root-Gui besorgen sollte. Warum auch immer... ich persönlich habe nichts dagegen, wenn man sich per kdesudo dolphin kurzzeitig rootrechte besorgt, um bequem per Gui die Rechte an gewissen Dateien/Verzeichnissen ändert. Das alles unter "/" (ausser /~) dabei tabu ist, sollte klar sein. Vllt sollte man das so sagen... 😕
Was will man denn sagen? Man will etwas richtiges sagen, was für Anfänger verständlich und klar ist.
Leider fehlt mir für solch einen Artikel die Erfahrung bzw das Hintergrundwissen...
Mir leider auch. ☺ Aber mit offensichtlich schwachen Erklärungen bin ich notorisch unzufrieden. Das macht mich ganz krank. ☺ Ich meine, daß man sein System nicht sonderlich gefährdet, wenn man als einziger Nutzer des Systems ständig als root arbeitet. Es ist einfach so, daß man mit dem Konzept des Multiusersystem mit separatem Rootaccount auch auf einem Einzelusersystem arbeiten kann, aber nicht umgekehrt. Wenn ich alleine im Netz surfe, und Firefox stürzt ab, und installiert einen Bot mit meinen Rechten mit autostart z.B. oder über Manipulation meiner .bashrc oder ähnliches - die Gefahr ist eigentlich nicht größer, wenn mir das als Root passiert. Außer ich habe weitere User auf der Plattform, die dann mitbetroffen sind. Für den User, der immer als Root unterwegs wäre, müßte die Konvention 'kein ssh-Zugang für root' durchbrochen werden, und wahrscheinlich gäbe es mehr Stellen, an denen dieses Vorgehen mehr Aufwand für die Dokumentation bedeutet, ohne jemandem viel zu bringen - man kann ja bei Bedarf root-Rechte erlangen.
Sollen wir das nehmen?
Rethorische Frage? 😉 Vorschlag:
kdesudo/gksudo ändert die Umgebungsvariable HOME auf den Pfad "/root". Somit werden programmspezifische Einstellungen (wie Zb Schriftgrößen, Fenstereinstellungen, ?? ...) dort abgespeichert und nicht im Homeordner des Users.
Bei Verwendung von sudo zeigt die Umgebungsvariable auf dem Homeordner des Benutzers und programmspezifische Einstellungen werden dort mit Rootrechten abgespeichert. Diese Einstellungen können dann vom Benutzer nicht mehr geändert werden.
Hmmm... is jetzt auch nicht "rund" 😊
Doch, doch. ☺ Sagen wir mal: Es ist ein Fortschritt.
|
kaputtnik
Anmeldungsdatum: 31. Dezember 2007
Beiträge: 9245
|
user unknown schrieb: kaputtnik schrieb:
Somit kann Stefan nicht den Zugriff gewähren, es sei denn er wäre gleichzeitig Admin, bzw in der Admin-Gruppe.
Erstens ist er das, ich kenne ihn. ☺
😊 Dann wirst Du Susi auch kennen 😀 Zweitens: Ja, das muß irgendwann mal eingerichtet worden sein - da es ein Beispiel ist, kann das sein.
Aber es geht aus dem Beispiel nicht klar hervor.
Ich will aber nicht den Kern in der Mitte antasten, da ich mit gksu/gksudo/kdsu etc. nicht bewandert bin.
Macht doch nix ☺
Was will man denn sagen?
Ich glaube genau das ist der Knackpunkt. Was will uns dieser Artikel sagen? Oder: Beibringen?
Leider fehlt mir für solch einen Artikel die Erfahrung bzw das Hintergrundwissen...
Mir leider auch. ☺ Aber mit offensichtlich schwachen Erklärungen bin ich notorisch unzufrieden.
Geht mir ähnlich 😉
Das macht mich ganz krank. ☺ Ich meine, daß man sein System nicht sonderlich gefährdet, wenn man als einziger Nutzer des Systems ständig als root arbeitet.
Diese (unsere) Ansicht sollte man durchaus diskutieren. Vllt schält sich dabei eine Linie heraus (aber ich glaube kaum...)
Es ist einfach so, daß man mit dem Konzept des Multiusersystem mit separatem Rootaccount auch auf einem Einzelusersystem arbeiten kann, aber nicht umgekehrt. Wenn ich alleine im Netz surfe, und Firefox stürzt ab, und installiert einen Bot mit meinen Rechten mit autostart z.B. oder über Manipulation meiner .bashrc oder ähnliches - die Gefahr ist eigentlich nicht größer, wenn mir das als Root passiert. Außer ich habe weitere User auf der Plattform, die dann mitbetroffen sind.
Für den User, der immer als Root unterwegs wäre, müßte die Konvention 'kein ssh-Zugang für root' durchbrochen werden, und wahrscheinlich gäbe es mehr Stellen, an denen dieses Vorgehen mehr Aufwand für die Dokumentation bedeutet, ohne jemandem viel zu bringen - man kann ja bei Bedarf root-Rechte erlangen.
Das ist mir jetzt zu hoch...
kdesudo/gksudo ändert die Umgebungsvariable HOME auf den Pfad "/root". Somit werden programmspezifische Einstellungen (wie Zb Schriftgrößen, Fenstereinstellungen, ?? ...) dort abgespeichert und nicht im Homeordner des Users.
Bei Verwendung von sudo zeigt die Umgebungsvariable auf dem Homeordner des Benutzers und programmspezifische Einstellungen werden dort mit Rootrechten abgespeichert. Diese Einstellungen können dann vom Benutzer nicht mehr geändert werden.
Hmmm... is jetzt auch nicht "rund" 😊
Doch, doch. ☺ Sagen wir mal: Es ist ein Fortschritt.
Ich kann mir nicht helfen, aber mir scheint, das eine grundsätzliche Betrachtung des Themas "Rootkonzept und Sicherheit" angestossen werden sollte... http://forum.ubuntuusers.de/topic/rootkonzept-und-sicherheit/
|
user_unknown
Anmeldungsdatum: 10. August 2005
Beiträge: 17586
Wohnort: Berlin
|
Das ist nicht zu hoch, sondern nur umständlich erklärt, so daß man am Anfang nicht weiß wo es hingeht, und am Ende, wo man herkam, weil zu viele Haken geschlagen werden. Man hat das Linuxsystem, welches unixoid ist, und für hunderte User ausgelegt. Aber die typischen Ubuntuuser nutzen es als Einzelusersystem oder vielleicht noch als Familienrechner für 2-3 Personen. Für diese sieht die Sicherheitslage anders aus. In einer Uni mit 10000 Usern probiert sicher einer mal ein rm -rf / aus - als Einzeluser ist man i.d.R. nicht so blöd. Also manche Mechanismen die für 1000 Leute sinnvoll sind sind für eine Person eigentlich überflüssig - sie stören aber auch nicht. – Früher war es auf Windows gang und gäbe, daß der User=Admin war, und dann mit dieser Unart das Linuxsystem erkundete, und meinte, er käme mit dieser Masche hier auch weiter. Und damals war es wichtig eine propagandistische Breitseite gegen diesen Vandalentypus aufzubauen, und aus allen Rohren zu feuern. Und das hat auch gewirkt. Aber heute - vielleicht irre ich mich da - hat sich auch auf der unterlegenen Plattform rumgesprochen, daß man administrative Aufgaben mit einem eigenen Account verrichtet, und ansonsten brav als Joe Doe dahinsurft. Das ist doch bei Vista und Vista7 so, oder? Mir fehlt da der Kontakt zu den NORMALOS. ☺ Ich meine man muß heute diese Breitseite nicht mehr aufbauen. Man sagt dem User, daß er die Lautstärke über den Mixer einstellt, daß er mit Firefox browsen kann, und mit sudo die Systemverwaltung erledigt. Für den User ist es gar nicht einfach sich als root einzuloggen, wenn er ein blutiger Anfänger ist, oder? Somit sind die roten Warnhinweise vielleicht etwas übertrieben, heute. Man könnte das eine Etage tiefer hängen. Vielleicht sollte man die ganze Sicherheitsdebatte aus dem Sudoartikel raushalten. So-und-so-macht-man-das, das-und-das-passiert, wenn man sich nicht an die Empfehlung hält (gksudo), und fertig. Und die Diskussion, wieso Linux sicher ist, und wann, an einer Extrastelle, vielleicht mit gesammelten, populären Behauptungen, und was dagegen spricht, mit einer Betrachtung der Historie, mehr mit Thesen und Fragen, als mit Antworten. Ich sehe eigentlich mehr Fragen.
|
Newubunti
Anmeldungsdatum: 16. Februar 2008
Beiträge: 5143
|
user unknown schrieb: Vielleicht sollte man die ganze Sicherheitsdebatte aus dem Sudoartikel raushalten. So-und-so-macht-man-das, das-und-das-passiert, wenn man sich nicht an die Empfehlung hält (gksudo), und fertig. Und die Diskussion, wieso Linux sicher ist, und wann, an einer Extrastelle, vielleicht mit gesammelten, populären Behauptungen, und was dagegen spricht, mit einer Betrachtung der Historie, mehr mit Thesen und Fragen, als mit Antworten. Ich sehe eigentlich mehr Fragen.
Ich sehe das auch so. So hat Allgemeines zur Sicherheit in dem Artikel nicht viel verloren, sondern wäre Inhalt für den derzeit ebenso verkorksten Artikel Sicherheitskonzepte (und was sie dem Benutzer bringen). Gruß,
Martin
|
redknight
Moderator & Supporter
Anmeldungsdatum: 30. Oktober 2008
Beiträge: 21809
Wohnort: Lorchhausen im schönen Rheingau
|
user unknown schrieb: zu Punkt 1: Wenn root angemeldet ist, und eine Partie Sudoku spielt, oder 14 Shells offen hat - ich sehe nicht was daran das System gefährdet.
Du unterschätzt John Doe, der grade mal eben die Rechte von / auf 777 setzt. Schau durch "Einrichten und Verwalten", wenn du glaubst, das könne nicht passieren. Die meisten werden eben vor so einem Unsinn nur durch "Permission denied" zurückgehalten. zu Punkt 2: Wenn man gewarnt würde, weil man sich mit einem Paßwort anmeldet, welches ein anderer User bereits nutzt, dann wüßte man, daß es mindestens einen Account mit diesem Passwort gibt. Das wäre eine empfindliche Sicherheitslücke.
Ich glaube mich zu erinnern, dass Debian während dem Installationsprozess unterschiedliche Passwörter für root und den angelegten user forderte. Hab ich allerdings auf die Schnelle keinen Nachweis gefunden, es kann auch sein dass ich Unsinn im Kopf habe. zu Punkt 3: Ich habe jahrelang einen root-login-Account gehabt, und hatte, neben dem Useraccount auch meist einen root-account offen.
Das macht mich ganz krank. Ich meine, daß man sein System nicht sonderlich gefährdet, wenn man als einziger Nutzer des Systems ständig als root arbeitet.
Ja, Du. Ich auch. Aber für einen user, der schlicht keine Lust hat, sich das Wissen über die Konzepte anzueignen, ist der Unterschied nicht ersichtlich. Es soll ja auch Leute geben, die ein WinXP Malware-frei halten. 😉 In der Zielgruppe der ubuntuuser dürfte AppArmor eine exotische Seltenheit sein. Über einen Wikihinweis hier werden eher wenige zu AppArmor kommen, oder?
AppArmor wird standardmässig installiert. Wieweit es konfiguriert wird, übersteigt auch meine Kenntnisse. Zur Susi-Stefan-Thematik: Da die Dateien in Stefans Home-Verzeichnis Stefan gehören, steht es Stefan auch frei, chmod 777 darauf zu machen. Somit kann Susi lesen und schreiben, ohne Mitgleid der Gruppe Stefan zu sein oder dessen PW zu kennen.
|
user_unknown
Anmeldungsdatum: 10. August 2005
Beiträge: 17586
Wohnort: Berlin
|
redknight schrieb: user unknown schrieb: zu Punkt 1: Wenn root angemeldet ist, und eine Partie Sudoku spielt, oder 14 Shells offen hat - ich sehe nicht was daran das System gefährdet.
Du unterschätzt John Doe, der grade mal eben die Rechte von / auf 777 setzt. Schau durch "Einrichten und Verwalten", wenn du glaubst, das könne nicht passieren. Die meisten werden eben vor so einem Unsinn nur durch "Permission denied" zurückgehalten.
Also wenn der unbedarfte User nicht chmod (rekursiv?) auf / anwendet, sondern auf ~, ist der Schaden dann geringer? Welche Verwendung von chmod ist das, die durch die sudo-Technik verhindert wird? Wieso soll er nicht sudo chmod machen, wenn er permission denied erhält?
Ich glaube mich zu erinnern, dass Debian während dem Installationsprozess unterschiedliche Passwörter für root und den angelegten user forderte. Hab ich allerdings auf die Schnelle keinen Nachweis gefunden, es kann auch sein dass ich Unsinn im Kopf habe.
Wenn das in einer Installationsprozedur stattfindet, wo man davon ausgeht, daß beide mal der gleiche User das Passwort eingibt, und es nur temporär vorgehalten wird, wäre es auch kaum problematisch.
zu Punkt 3: Ich habe jahrelang einen root-login-Account gehabt, und hatte, neben dem Useraccount auch meist einen root-account offen.
Das macht mich ganz krank. Ich meine, daß man sein System nicht sonderlich gefährdet, wenn man als einziger Nutzer des Systems ständig als root arbeitet.
Ja, Du. Ich auch. Aber für einen user, der schlicht keine Lust hat, sich das Wissen über die Konzepte anzueignen, ist der Unterschied nicht ersichtlich. Es soll ja auch Leute geben, die ein WinXP Malware-frei halten. 😉
Das das macht mich ganz krank bezog sich auf offensichtlich schwache Erklärungen, nicht auf einen meist offenen Rootaccount. Die Zitiertechnik hat hier einen ganz falschen Sinn erzeugt. Meine Kritik richtet sich dagegen den Eindruck zu erwecken, ein Programm, welches von root gestartet wurde, und das ungenutzt im Speicher rumlümmelt, würde die Sicherheit gefährden. Früher stand da:
Es gibt entscheidende Nachteile, wenn man als Administrator oder Root arbeitet, besonders dann, wenn der Rechner mit dem Internet verbunden ist. Gelingt es einem Angreifer, in das System einzudringen (eventuell mit einem Virus oder einem Fehler im Webbrowser), so besitzt er ebenfalls sofort Administratorrechte und kann tun, was immer er will.
und: Vergisst man, sich als root abzumelden, bleibt das System gefährdet
AppArmorIn der Zielgruppe der ubuntuuser dürfte AppArmor eine exotische Seltenheit sein. Über einen Wikihinweis hier werden eher wenige zu AppArmor kommen, oder?
AppArmor wird standardmässig installiert. Wieweit es konfiguriert wird, übersteigt auch meine Kenntnisse.
Die Frage ist: Paßt der Hinweis auf AppArmor da hin, ist er sinnvoll und nötig? Wenn niemand AppArmor konfiguriert, außer ein paar Professionellen Admins, dann gehört es da m.E. nicht hin.
Zur Susi-Stefan-Thematik: Da die Dateien in Stefans Home-Verzeichnis Stefan gehören, steht es Stefan auch frei, chmod 777 darauf zu machen. Somit kann Susi lesen und schreiben, ohne Mitgleid der Gruppe Stefan zu sein oder dessen PW zu kennen.
Wieso 777? Meinst Du 666? Außerdem kann dann jeder, nicht nur Susi zugreifen.
|
redknight
Moderator & Supporter
Anmeldungsdatum: 30. Oktober 2008
Beiträge: 21809
Wohnort: Lorchhausen im schönen Rheingau
|
user unknown schrieb: Also wenn der unbedarfte User nicht chmod (rekursiv?) auf / anwendet, sondern auf ~, ist der Schaden dann geringer? Welche Verwendung von chmod ist das, die durch die sudo-Technik verhindert wird? Wieso soll er nicht sudo chmod machen, wenn er permission denied erhält?
Ich suche die Threads gern raus, wir hatten in meiner (relativ kurzen) Zeit als supporter mehrere Helden, die chmod rekursiv auf / angewendet haben und danach Systemdienste nicht mehr starteten, weil die Rechte der zugehörigen Konfigdatei überprüft wurden und nicht in Ordnung waren. UNd noch einmal doppelt so viele, die genau das vorhatten und nur von Permission denied genau daran gehindert wurden. Das das macht mich ganz krank bezog sich auf offensichtlich schwache Erklärungen, nicht auf einen meist offenen Rootaccount. Die Zitiertechnik hat hier einen ganz falschen Sinn erzeugt.
Dann hab ich das auch falsch verstanden. Ich nehme also alles zurück und behaupte das Gegenteil 😉 Meine Kritik richtet sich dagegen den Eindruck zu erwecken, ein Programm, welches von root gestartet wurde, und das ungenutzt im Speicher rumlümmelt, würde die Sicherheit gefährden. Früher stand da: Es gibt entscheidende Nachteile, wenn man als Administrator oder Root arbeitet, besonders dann, wenn der Rechner mit dem Internet verbunden ist. Gelingt es einem Angreifer, in das System einzudringen (eventuell mit einem Virus oder einem Fehler im Webbrowser), so besitzt er ebenfalls sofort Administratorrechte und kann tun, was immer er will.
Ok, das is verbesserungswürdig, das geb ich zu. Die Frage ist: Paßt der Hinweis auf AppArmor da hin, ist er sinnvoll und nötig? Wenn niemand AppArmor konfiguriert, außer ein paar Professionellen Admins, dann gehört es da m.E. nicht hin.
Die Frage hierzu ist, was standardmässig mitgeliefert wird. Das weiß ich allerdings auch nicht. ich weiß nur, dass dpkg ab und zu Processing triggers for AppArmor und Profiländerungen dafür macht. Das müsste man dann entsprechend recherchieren...
|