was will sudo?

[MoTw]

Danke für eure Antworten. @Cathul vom 18.05.2009, 13:47:
Ich habe das Alles so gemacht und bin auch inzwischen selbst Admin und kompiliere gerade SDL-1.2.0. Jetzt habe ich ein anderes Problem: Wenn ich mit make ankomme, sagt das Terminal folgendes (Ausschnitt, wo die Errors anfangen):

SDL_macevents.c:79: warning: 'SetCursor' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/QuickdrawAPI.h:526)
SDL_macevents.c:79: warning: 'GetQDGlobalsArrow' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/QuickdrawAPI.h:5345)
SDL_macevents.c: In function 'myGlobalToLocal':
SDL_macevents.c:96: warning: 'GetPort' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/QuickdrawAPI.h:307)
SDL_macevents.c:98: warning: 'SetPort' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/QuickdrawAPI.h:292)
SDL_macevents.c:102: warning: 'GlobalToLocal' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/QuickdrawAPI.h:2181)
SDL_macevents.c:103: warning: 'SetPort' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/QuickdrawAPI.h:292)
SDL_macevents.c: In function 'Mac_HandleEvents':
SDL_macevents.c:219: error: invalid operands to binary !=
SDL_macevents.c:219: error: invalid operands to binary !=
SDL_macevents.c:220: error: invalid operands to binary !=
SDL_macevents.c:220: error: invalid operands to binary !=
SDL_macevents.c:261: warning: 'FrontWindow' is deprecated (declared at /System/Library/Frameworks/Carbon.framework/Frameworks/HIToolbox.framework/Headers/MacWindows.h:11398)
SDL_macevents.c:305: warning: 'GrowWindow' is deprecated (declared at /System/Library/Frameworks/Carbon.framework/Frameworks/HIToolbox.framework/Headers/MacWindows.h:11661)
SDL_macevents.c: In function 'TranslateKey':
SDL_macevents.c:596: warning: 'GetScriptManagerVariable' is deprecated (declared at /System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/Script.h:993)
SDL_macevents.c: In function 'Mac_InitEvents':
SDL_macevents.c:612: warning: 'AppendResMenu' is deprecated (declared at /System/Library/Frameworks/Carbon.framework/Frameworks/HIToolbox.framework/Headers/Menus.h:7047)
make[3]: *** [SDL_macevents.lo] Error 1
make[2]: *** [all-recursive] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all-recursive] Error 1

Was bedeutet das?

EDIT: Warum hat dieser Thread auf einmal das Stichwort "popcorn"?

 

[Goglo]

Richtig vermutet:

#
# sudoers-file
#
# Cmnd alias specification
Cmnd_Alias MAKE = /usr/bin/make, /usr/bin/make install

# User privilege specification
foobar     ALL=MAKE

Dann brauchen wir noch ein klitzekleines Makefile:

install: 
    xterm &

"make" macht ein normales xterm auf. Mit "sudo make" bekommt man dann eins mit root-Berechtigung.

 

[Rastafari]

Es kommen abstruse Vorschläge, wie man mit Gewalt Dinge mit der Shell erledigt, die man sonst eigentlich per GUI macht.

So ist das halt mal, wenn man zB über eine Backdoor via SSH unauffällig in einem fremden System rumspazieren will...

Und es wird behauptet, ein Normalo könne das System irgendwie kaputtkriegen. Überlicherweise braucht er dazu sowohl nach, wie auch vor meinem "sodoers-Hack" Zugang zu einem Admin-account.

Traumtänzer. Wenn du meinst, dann steppt eben mal kurz der Bär für dich.

1) Leg dir einen neuen, eingeschränkten Benutzer an.

2) Gib ihm den von dir vorgeschlagenen, vollen sudo-Zugriff; genauso wie ihn auch die admin-Gruppe besitzt.

3) Verhalte dich wie ein typischer, sich in wohlig warmer Sicherheit wägender Normalbenutzer, der durchs Netz bummelt. Sprich:
Klicke dich durch die angehängten vier Dokumente. Da drin versteckt sich ein (primitiver und absolut harmloser) Trojaner. So einer, wie du ihn dir auch auf etlichen Webseiten, oder zB über von Kunden oder Freunden angelieferte, infizierte Dokumente jederzeit einfangen könntest.
Genau davor soll dich die Trennung der Benutzerrechte ja bewahren, dass du damit dein gesamtes System verseuchen könntest. Mal sehen, ob das bei dir noch klappt?

Du brauchst einfach nur alle vier Dokumente der Reihe nach doppelklicken, also ganz wie üblich mit den mitgelieferten Standardprogrammen von OS X zu öffnen; das wären TEXT und RTF in "TextEdit", ein MOV für den "QuickTime Player" und ein PDF in "Vorschau".
Also alles ganz harmlos wirkende Programme, denen man gegenüber den heute gängigen, längst plattformunabhängigen Makroviren (Word) oder JavaScript-Attacken (Acrobat) eigentlich stahlharte Immunität nachsagt.
Und trotzdem: Schwupps, ist dein eingeschränktes Benutzerkonto ein glühend heisses Pflaster geworden: Die Siliziumgrippe hat dich erwischt.

Keine Sorge:
Ich bin keiner von den pösen Puben. Ich war nicht so fies, einen Autostartmechanismus einzubauen (was natürlich kinderleicht möglich gewesen wäre). Sonst wäre das Teil auch nach Neuanmeldungen oder Neustarts noch "scharf", und das wäre mir einfach viel zu weit gegangen für eine Demonstration. Nach einem Restart sollst du ja wieder in Frieden weiterschlafen können. Ist schliesslich nur ein "Proof-Of-Concept" und kein echter, aggressiver und trickreicher Botnetz-Kampfpanzer.
Bösartige Schadfunktionen enthält er selbstverständlich auch keine.
(Nur einen kleinen Beweis, was er hätte tun können, wenn er denn wollte.
Und sei froh, dass ich den Elefanten dazu nicht quer durch dein TimeMachine-Volume trampeln lasse, bis hin zu deinem ältesten aller alten Backups...)

4) Arbeite einfach weiter, so wie du das im Alltag auch tun würdest. So lange wie du willst. Und dann öffne irgendwann später (während der gleichen Sitzung, s.o.) ein Terminal und führe damit ein beliebiges "sudo"-Kommando aus.
Nach deiner Theorie ist sowas ja absolut harmlos und ungefährlich?

Spätestens 5-6 Minuten später wird dir hoffentlich klar, dass du über Systemsicherheit besser keine Vorträge mehr geben solltest. Du durchschaust das Konzept nämlich nicht die Bohne, Q.E.D.
Ende der Ansage.

Die Aussage "Nur Mitglieder der Gruppe Admin dürfen sudo dürfen und das machst Du mit Deinem Tip ja kaputt und deshalb ist das ein böser Tip." möchte ich jetzt nicht als Begründung gelten lassen.

Besser wär das aber.
Das ist nämlich leider die sprichwörtliche Faust, die genau aufs Auge passt.

 

[Goglo]

Ohne es jetzt ausprobiert zu haben, glaube ich Dir, daß eine gezielte Attacke auf sudo machbar ist und auch funktionieren wird. Es wird demnach aufs wundervollste demonstrieren, warum es auch unter OS X keine gute Idee ist, permanent als Admin zu arbeiten. Und Apple gut dran täte, im Installationssetup per Default zwei Benutzer anlegen zu lassen: Einen Normalo und einen Admin.

Denn was ein Admin machen kann, kann der sudoende Entwickler mit ein wenig Hirnschmalz und Verrenkungen auch - ich habe nie etwas anderes behauptet[1]. Du gehst in Deiner Agrumentation immer noch davon aus, ich hätte einen allgemeinen Tip zur Performancesteigerung für alle OS X User dieser Welt gegeben und unterstellst mir "Vorträge über Systemsicherheit halten" zu wollen, das "Konzept nicht die Bohne" zu durchschauen und reiß darüber hinaus Zitate aus ihrem Zusammenhang. Das sind allesamt Unterstellungen Deinerseits, in die Du dich da zunehmend hereinsteigerst.

Halten wir also fest: Es ist auch unter OS X keine gute Idee, normalen Benutzern zu erlauben, "diesen Computer verwalten" zu dürfen. Wenn man einem Benutzer Administrationsrechte einräumt, sei es über die Admingruppenzugehörigkeit oder über die /etc/sudoers[2], sollte man sich der daraus erwachsenden Konsequenzen und Risiken bewußt sein. Das gilt auch für Entwickler und andere PowerUser(tm).



[1] Ich schrieb lediglich, daß unter normaler Benutzung des Computers die sudoers-Lösung die GUI-Komponenten immer noch als Normalo laufen läßt.
[2] Wobei die Admingruppenzugehörigkeit weiter reichende Berechtigungen bedeutet, als die sudoers-Lösung.

 

[MacMark]

Du hast es immer noch nicht verstanden, Goglo: Man sollte die Grenze zwischen Admin und Normaluser nicht verwischen wie mit Deinem "Tip". Die Sicherheit des Normalusers ist dann nämlich weg.

Und wenn man sudo benötigt, muß man auf einen Admin wechseln. Deine Abkürzung, Dein "Tip", ist ein Sicherheitsproblem.

 

[Goglo]

@MoTw: kurzes googlen nach der Fehlermeldung ergab "try using GNU make (gmake)" Probier das doch mal.

(Und laß das mit dem Admin, Du weißt ja jetzt wie gefährlich das ist; brauchen tust Du die Adminrechte erst beim "make install"; compilieren tust Du hoffentlich in Deinem Home-verzeichnis.)

Warum hat dieser Thread auf einmal das Stichwort "popcorn"?

Da wird irgendein Witzbold der Meinung gewesen sein, die Debatte über sudoers wäre eine inhaltslose, zu deren besserem Genuß man sich fernsehmäßig einrichten sollte: Mit Cola und Popcorn.

 

[Goglo]

@MacMark: Gut, dann ist die sudoers unter OS X böse, denn in Cupertino hat man sich eine Gruppenzugehörigkeit als Unterscheidung zwischen Normalo und Admin ausgedacht und diese gilt ausschließlich. Was auf allen mit sudo ausgestatteten Unices dieser Welt als normale Konfiguration ist gilt, ist unter OS X also ein "Sicherheitsproblem". Dann haben wir wohl unterschiedliche Auffassungen von Problemen.

 

[MacMark]

... Was auf allen mit sudo ausgestatteten Unices dieser Welt als normale Konfiguration ist gilt ...

Du irrst Dich hier.

 

[Rastafari]

Was auf allen mit sudo ausgestatteten Unices dieser Welt als normale Konfiguration ist

Die spartanisch und vorsintflutlich anmutende Methode: "root oder nix", "Gott oder Depp, dazwischen gibts nix" (alle Macht oder überhaupt keine), die sich so manches Do-it-yourself Use-nix immer noch erdreistet, wäre mir nicht so ganz genehm. (Ganz vornehm ausgedrückt.)
Aber du kannst ja gerne die Admin-Gruppe mit ihren Privilegien komplett aus dem System verbannen und zukünftig ebenfalls alles als root verwalten, so wie diese bedauernswerten Leute das tun müssen. Mit all seinen frappanten Nachteilen - und keinem einzigen erkennbaren Vorteil.
Es sei dir ganz allein anheimgestellt, die Uhr etwa 15 Jahre zurückzudrehen - auf deinem eigenen System darfst du das.
Dass du dir dazu erst mal eine eigene, gehärtete Version von sudo kompilieren solltest, oder zumindest ein paar Tage (bis Wochen) Bedenkzeit in deine ganz individuelle sudoers-Konfiguration stecken musst, ist dir sicher klar.

 

[GunBound]

Klicke dich durch die angehängten vier Dokumente. Da drin versteckt sich ein (primitiver und absolut harmloser) Trojaner. So einer, wie du ihn dir auch auf etlichen Webseiten, oder zB über von Kunden oder Freunden angelieferte, infizierte Dokumente jederzeit einfangen könntest.
Genau davor soll dich die Trennung der Benutzerrechte ja bewahren, dass du damit dein gesamtes System verseuchen könntest. Mal sehen, ob das bei dir noch klappt?

Vor allem beim letzten merkt man, dass es kein simples Dokument ist (da die "… ist ein Programm, das aus dem Internet geladen wurde."-Meldung erscheint). Ich hab's mal geöffnet (unter meinem Standardaccount — ja, ich bin so vorsichtig gewesen und arbeite nicht als Admin). Was tut der Trojaner denn genau bzw. wie kann man ihn aufspüren?

 

[Goglo]

Die spartanisch und vorsintflutlich anmutende Methode: "root oder nix", "Gott oder Depp, dazwischen gibts nix" (alle Macht oder überhaupt keine)...

Gerade wegen des spartanischen "root oder nix"-Konzepts ist ja sudo entwickelt worden. Damit kann man Benutzern einzelne Befehle und Hosts erlauben, wie mir die manpage mitteilte.

Das von OS X verfolgte "Darf Computer verwalten oder nicht" sehe ich irgendwie relativ nahe an an dem von Dir zu Recht kritisierten "root oder nix". Beide Konzepte sehen auf den ersten Blick aus, als ob es nur zwei Zustände gäbe. Mit dem Unterschied, daß es einmal "$admin" heißt und einmal "root". Da die sudoers aus "Sicherheitsgründen" ja nur zur Verwaltung der admin-Gruppe benutzt werden soll, bleibts beim Alles oder Nichts, auch wenn das "Nichts" unter OS X ein bisschen mehr ist, als unter anderen Unices.

Übrigens habe ich keinerlei Verlangen danach, root zu aktivieren oder mir sonstwelche Berechtigungskonzepte auszudenken, wie Du mir unterstellst. Aber dennoch danke, daß Du es mir erlaubst.

 

[Rastafari]

Was tut der Trojaner denn genau

"300"
Singen, tanzen, scherzen, lachen.
Griechen und Perser prügeln bis die Haare bluten.
Und hin und wieder jemanden ins tiefe Loch schubsen. Bloss zur Gaudi.
"301"

Die Quarantänemeldung ist übrigens nicht sehr tragfähig. Man braucht einem Benutzer nur permanent seine LaunchServices-Datenbank unterm Hintern wegzuschiessen. Dann nerven diese Dialoge bei praktisch allen Aktionen, immer und immer wieder. Der Rest ist psychologische Kriegsführung. Früher oder später klickt jeder alles.
Click!
"302"

bzw. wie kann man ihn aufspüren?

Irrelevant. Ist nur ein oberflächliches Shellskript, das einen Trojaner "simuliert".
(Von der Länge der Barthaare her einen aus dem Jahre 1986/87 )
Ein echter würde sich hinter einer Software verbergen, die du für nützlich hältst. Und er würde auch etwas vorsichtiger vorgehen als ich das auf die Schnelle gemacht hab. Meine Ad-Hoc Methode könnte man anhand verdächtiger sudo-Alerts im Syslog aufstöbern (zumindest wenn er lange genug auf das ersehnte Öffnen der Tür warten musste).

syslog | grep sudo | grep validate

Einen etwas zarter ans Werk gehenden Code entdeckt man so nicht. Der wäre clever genug, dort nur zu lauschen und sonst erst mal überhaupt nichts zu tun. Du kannst da ja einfach mal mit der "Konsole" reinschauen und sehen was geschieht, wenn sich jemand unberechtigt einzuloggen versucht. Und wie das im Gegensatz dazu aussieht, wenn es jemand erfolgreich tut. Das ist dann das Wecksignal, und dann ist es auch schon zu spät.
"303"

 

[GunBound]

Was wäre denn passiert, hätte man ein sudo-Kommando eingegeben?

 

[MacMark]

Systemübernahme durch den Hintergrundprozeß, der durch die Trojaner-"Dokumente" gestartet wurde.

 

[Rastafari]

Was wäre denn passiert, hätte man ein sudo-Kommando eingegeben?

Lass dich überraschen.
Wie gesagt, keine Schadfunktion, just for fun.
(Dieses mal noch... )

 

[Apfelbitz]

Lass dich überraschen.
Wie gesagt, keine Schadfunktion, just for fun.
(Dieses mal noch... )

Nach seiner Verhaftung wurde festgestellt das er seine Taten schon lange im Internet angekündigt hatte. :-D

 

[GunBound]

Lass dich überraschen.
Wie gesagt, keine Schadfunktion, just for fun.
(Dieses mal noch... )

Habe es jetzt eine ganze Weile am laufen (unter einem eingeschränkten und Admin-Benutzer gleichzeitig gestartet, auf beiden ein sudo-Kommando ausgeführt [wobei der eingeschränkte natürlich keinen Zugriff hat; da habe ich noch mit "su admin" und danach dem sudo-Kommando etwas versucht]).
Keine Auswirkungen.

 

[Rastafari]

unter einem eingeschränkten und Admin-Benutzer gleichzeitig gestartet

Wie das mit der "schnellen Benutzerumschaltung" harmoniert, hab ich nicht getestet (und auch gar nicht berücksichtigt). Ich behaupte einfach mal, dass das Probleme bringen wird. Da müsste ich wohl noch so einiges umspengeln.
(RTFM; Im Posting stehts: "gleiche Sitzung" -->> Neu anmelden stoppt die Demo)

wobei der eingeschränkte natürlich keinen Zugriff hat; da habe ich noch mit "su admin" und danach dem sudo-Kommando etwas versucht

Also hast du es effektiv zwei mal als Admin getan. Denn ein "su" führt nicht nur Befehle "im Namen" eines anderen Nutzers aus, es ändert deine Identität komplett. Du geniesst dann nicht nur die Rechte eines anderen, sondern du bist danach ein anderer.
Unter dem Benutzerkonto kann sich also nichts tun, denn der hat sudo nie benutzt.
(Genau das ist der in sicherer Weise voreingestellte Mechanismus, den du nicht durch Erweiterungen der sudo-Befugnisse anbohren sollst.)

Und wenn du die andere Sitzung verlassen hast, bevor der Effekt eintritt, klemmt es auch dort...
Je nachdem wie wild du rumgeklickt hast, laufen da jetzt also zwei oder mehr Prozesse unter gleichem Namen (Adminkonto), die sich ständig gegenseitig als "Prozessleichen" erkennen (gestartet in anderer Sitzung) und daraufhin die Arbeit einstellen (weil ich ein nettes Mensch bin, das anderer Leute Rechner nicht zumüllen will).
Alle wollen den gleichen Lockfile (mit statischem Dateinamen) verwenden, und so gehts nicht.
Muss man jetzt etwa auch schon seine Exploits in absolut narrensicherer Weise gestalten?

Mach einfacherweise einen Neustart, um evtl noch herumschwirrende Prozesszombies mit Sicherheit los zu sein. (Oder kille sie alle in der Aktivitätsanzeige, such dazu hierarchisch nach "bash"-Instanzen, an denen ein "sleep" dranhängt).
Dann benutzt du wie angegeben ein "sudo-enabled" Normalkonto (oder auch einen Admin, da klappt das natürlich sowieso). Und dann versuch dort doch mal, das PDF mehrmals hintereinander zu betrachten. (Das könnte Verwirrung stiften. Einmal genügt natürlich auch, aber mehrmals sorgt für etwas Bonus-Vergnügen. Nach einigen Sekunden der Betrachtung ändert es nämlich eigenmächtig seinen Inhalt. Oops! ).
Im "worst case" dauert es dann etwas über 5 Minuten, bis deine am Mac hängenden 1000 Watt Boxen den Nachbarn den Kitt aus der Lesebrille drücken.

 

[koksnutte]

hab das ganze mal ausprobiert, sehr lustig ja
was mich etwas verwundert:
- warum kommt bei mir keine quarantäne meldung wenn ich auf das "pdf" klicke welches in wirklicheit ja ein programm paket ist?
- was hat es mit dem codestream in "Localized PDF Helper" auf sich? sind das die bilder die abwechselnd geöffnet werden?
- hatte /System nicht ein "group:everyone deny delete" attribut!?
und ganz wichtig:
- was hat es mit der umbegungsvariable securitysessionid auf sich?
- warum erlangt ein skript welches in einer anderen subshell läuft ebenso root rechte?

edit:
ok zu punkt 1 hab ich schon eine lösung:
betterzip versieht die entpackten dateien nicht mit dem quarantäne attribut... :/

 

[Rastafari]

- was hat es mit dem codestream in "Localized PDF Helper" auf sich? sind das die bilder die abwechselnd geöffnet werden?

Psssst! Nie fragen! Nie antworten!

- hatte /System nicht ein "group:everyone deny delete" attribut!?

Klar doch. Das bedeutet nichts anderes, als dass niemand einfach so diesen Ordner löschen kann (auch den von einem System auf einer externen HD nicht).

- was hat es mit der umbegungsvariable securitysessionid auf sich?

Die wird vom Windowserver an deine gesamte grafische Sitzung vererbt. Viele Programme orientieren sich an ihr, auch sudo stellt damit fest, ob seine Timestamps noch plausibel sind.

- warum erlangt ein skript welches in einer anderen subshell läuft ebenso root rechte?

Weil sudo keine Authentifizierung verlangt, wenn...
...der Benutzer innerhalb der letzten 5 Minuten schon mal erfolgreich verifiziert wurde.
...wenn er das in der gleichen grafischen Sitzung (s.o.) getan hat.

Aus Komfortgründen verzichtet sudo auf eine Bestätigung von aufrufendem Elternprozess (PPID) oder Terminalsitzung (tty). Wer das Konfigurationskonzept von sudo verändern will, sollte diese Prüfungen unbedingt einführen.

EDIT: Hinzufügt ein Auszug aus "sudoers.5":

tty_tickets

If set, users must authenticate on a per-tty basis. Normally, sudo uses a directory in the ticket dir with the same name as the user running it. With this flag enabled, sudo will use a file named for the tty the user is logged in on in that directory. This flag is off by default.

Den meisten Anwendern dürfte das aber nicht schmecken, wenn in jedem Terminalfenster und auch in jedem Tab des Programms das Kennwort erneut einzugeben ist. Im Grunde bringt das aber sowieso nicht allzu viel, denn alle diese Fenster gehören zum gleichen GUI-Programm und können so einander "bespitzeln".
Ein Heruntersetzen der 5-minütigen "Grace Period" auf kleinere Werte bringt auch nichts, denn bereits 100-200 ms sind schon zu viel für solche Löcher: Sobald "syslogd" mit einem Protokolleintrag auf ein erfolgreiches sudo-Login reagiert hat, steht der sich mit "tail" da dranhängende Schädling auch schon auf der Matte. Und diese komplett abzuschalten ist auch nicht clever, denn dann funktioniert so gut wie kein Skript mehr, welches sudo genau so wie beabsichtigt einsetzt.

Ergo:
- sudo "härten" und nerviges Verhalten in Kauf nehmen, oder:
- Die voreingestellte Konfiguration niemals in solcher Weise verändern.
Alles andere ist MÖÖÖÖÖP!