Windows - Bekommt Windows ein Problem? [Archiv]

Rooter

2008-04-10, 22:33:07

Schnuller4u

2008-04-10, 22:52:58

Der erste Artikel hat durchaus nicht unrecht. Warum läuft z.B. der Eee-PC mit Linux oder maximal XP? Weil es M$ nicht schafft Vista in ausreichendem Maße abzuspecken. Aber Ansätze für einen schlankeren zukünftigen Windowskernel sind doch schon gemacht: MinWin
Ja. Ich kann mir den aktuellen Windows-Kernel nicht auf einem Smartphone vorstellen. Von OSX läuft mehr oder weniger das gleich OS auf dem iPhone. Bei Linux gibt es wahrscheinlich ebenfalls weniger Unterschiede, als bei Windows auf mobilen Devices. OK, Smartphone ist schon extrem aber für Vista reicht es offenbar noch nichtmal auf den Mini-Laptops.

Die Windows-Architekur mag wegen der vielen Altlasten nicht optimal sein, die von OSX mag auch um einiges durchdachter und schlicht besser sein, aber M$ kann nicht mit der Kompatibilität so einfach brechen wie Apple es bei OSX getan hat weil die Zielgruppe eine ganz andere ist. Der Großteil der Applenutzer dürfte wohl Bildbearbeitung u.ä. machen,
Ja wieso kann das Apple und nicht MS? Laufen bei MS "10" Leute weg, dann merken die das noch nichtmal, da Marktanteil auf dem Desktop >= 90 Prozent. Werden hingegen bei Apple "10" Leute verärgert, dann sieht das durchaus anders aus, vorallem wenn dann noch der Rest der verbliebenen ebenfalls anfängt an der Plattform zu zweifeln, da manches Software-Haus das evtl. nicht mit macht usw. So war es AFAIR beim Wechsel von OS9 auf OSX, wo zugegeben Apple aber auch gar keine andere Wahl hatte, da OS9 aus technischer Sicht völlig veraltet war.

die dafür nötigen Programme kann man schon mal neu programmieren
Trotzdem hat Apple immer Lösungen gefunden/präsentiert, die einen "sanften" Umstieg i.d.R. ermöglicht haben (der Situation entsprechend), wie z.B. Carbon-CFM, Classic, Rosetta.

(okay, so einfach auch nicht...).
Will ich auch meinen.

Aber was wäre denn wenn M$ morgen ein neues OS mit Top Architektur vorstellt auf der aber keine Windowsprogramme mehr laufen? Die Leute würden scharenweise zu Linux oder OSX flüchten weil sie die hundertausenden Programme die sie gewöhnt sind nicht mehr hätten (Privatkunden) oder weil ihre Unternehmenssoftware nicht mehr läuft. (Firmenkunden.
Hallo. Meinst bei Apple gibt es nicht diese Gefahr? Ausserdem gibt es Lösungen und sei es nur Virtualisierungslösungen, um einen Übergang zu ermöglichen.
Aber ich kann da nicht mitreden, wie es mit der WinAPI aussieht. AFAIK hat doch MS den Grundstein gelegt, der manches ermöglichen würde (.net usw).

MS hat es ja noch nichtmal geschafft den Usern das "Admin-sein" abzugewöhnen. Erst mit Vista (UAC) geht es in die Richtung und immer noch mit Rücksicht auf Altprogramme. Dabei hätte MS schon zu XP-Zeiten sagen können/müssen, dass z.B. mit SP1 schicht im Schacht ist mit schlecht geprogter Software, die root-Rechte verlangt. Dann hätten die Entwickler genügend Zeit gehabt. Die hätten schon reagiert (reagieren müssen) und das Thema wäre vermutlich heute gegessen.

Rooter

2008-04-10, 23:31:57

Ja wieso kann das Apple und nicht MS? Laufen bei MS "10" Leute weg, dann merken die das noch nichtmal, da Marktanteil auf dem Desktop >= 90 Prozent.

...

Hallo. Meinst bei Apple gibt es nicht diese Gefahr?Naja, wenn Apple eine neue Architektur rausbringt mögen die z.B. 50% ihrer Kunden verlieren. Wenn M$ das machen würde würden die sicher über 90% verlieren, Gründe siehe oben.

AFAIK hat doch MS den Grundstein gelegt, der manches ermöglichen würde (.net usw).Da könntest Du recht haben, ist ja auch virtualisiert, mit Mono sogar für andere OS.

MS hat es ja noch nichtmal geschafft den Usern das "Admin-sein" abzugewöhnen. Erst mit Vista (UAC) geht es in die Richtung und immer noch mit Rücksicht auf Altprogramme. Dabei hätte MS schon zu XP-Zeiten sagen können/müssen, dass z.B. mit SP1 schicht im Schacht ist mit schlecht geprogter Software, die root-Rechte verlangt. Dann hätten die Entwickler genügend Zeit gehabt. Die hätten schon reagiert (reagieren müssen) und das Thema wäre vermutlich heute gegessen.
Tja, M$ ist halt ein riesiger Dinosaurier und die sind laaangsaam. :wink:

MfG
Rooter

Schnuller4u

2008-04-10, 23:57:19

Naja, wenn Apple eine neue Architektur rausbringt mögen die z.B. 50% ihrer Kunden verlieren. Wenn M$ das machen würde würden die sicher über 90% verlieren, Gründe siehe oben.
Das glaube ich nicht. Ich glaube kaum, dass MS sich vor Apple wirklich fürchten muss, solange Apple an derzeitigem Geschäftsmodell festhält. Mit lizensierten "Mac-Clones" oder einem völlig freiem OSX wäre das evtl. anders.
Und bei Linux fehlt es an den ganzen kommerziellen Programmen, für die es nicht überall freie gleichwertige Alternativen gibt usw. OK, evtl. kämen dann die Softwarehäuser auf den Geschmack.

iDiot

2008-04-11, 08:43:04

Windows muss nicht auf Smartphones laufen, dafür gibts Windows Mobile. Warum sollte sich daran großartig was ändern? Klar, ein Modulares OS würde die Entwicklungskosten schmälern. Hat MS derzeit aber bei den Quartalszahlen in den nächsten 5 Jahren nicht nötig. MS hat den ersten Schritt mit Vista und Server 2008 (selber Kernel ab Sp1) schon getan.

Shink

2008-04-11, 10:15:11

Aber was wäre denn wenn M$ morgen ein neues OS mit Top Architektur vorstellt auf der aber keine Windowsprogramme mehr laufen? Die Leute würden scharenweise zu Linux oder OSX flüchten weil sie die hundertausenden Programme die sie gewöhnt sind nicht mehr hätten (Privatkunden) oder weil ihre Unternehmenssoftware nicht mehr läuft.
Windows 3.x-Programme laufen doch schon nicht mehr unter 64Bit-Windows, oder?
Ich hab sogar ein paar Windows 95-Programme die unter Windows XP so toll und problemlos laufen wie unter Wine.

Wirklich griffig find ich das Argument ohnehin nicht: Wenn jemand auf alte Software auf neuen Systemen setzt, muss er damit rechnen dass sie irgendwann nicht mehr läuft. (CPU-Speed, Zugriff auf Hardware; ja sogar viele alte Schnittstellen werden abgeschafft).

Ich nehme mal an wenn alle OLPC, EEEPC und ähnliche Rechner nur mit Linux laufen würden, hätte M$ irgendwann schon ein Problem. So weit wirds aber nicht kommen: M$s LowCost-LowEnd-Edition wird ein typisches M$-Betriebssystem: Später als die Konkurrenz, schlechter als die Konkurrenz und trotzdem weit verbreitet.

Schnuller4u

2008-04-11, 10:21:40

"Windows kollabiere, Microsoft müsse grundlegende Änderungen an seinem Betriebssystem bewerkstelligen, anderenfalls sei der Konzern weg vom Fenster: Windows, so wie man das heute kenne, müsse ersetzt werden."

"Als Abhilfe sehen die Gartner-Analysten eine weit stärker modularisierte Version von Windows als Vista an, bei dem Microsoft ja bereits seine Modularität betont. Auch könne in Virtualisierung von Systemen und Systembestandteilen, etwa für Abwärtskompatibilität mit älteren Anwendungen, eine Lösung liegen. Schnelle Änderungen seien bei Microsoft angesichts des Milliarden Dollar schweren Windows-Geschäfts nicht zu erwarten."

http://www.heise.de/newsticker/IT-Analysten-Windows-kollabiert--/meldung/106358

iDiot

2008-04-11, 10:26:20

Gartner-Analysten
http://www.heise.de/newsticker/IT-Analysten-Windows-kollabiert--/meldung/106358
lol
http://www.heise.de/newsticker/suche/ergebnis?rm=result;words=Gartner;q=gartner;url=/newsticker/meldung/100270/
http://www.heise.de/newsticker/suche/ergebnis?rm=result;q=gartner;url=/newsticker/meldung/78866/;words=Gartner

Irgendwie wiedersprüchlich?;D

Das zu lösende Problem (falls vorhanden? ) liegt auch rein bei MS selbst und tangiert die Kunden nur periphär.

Exxtreme

2008-04-11, 10:31:21

Problem an Windows ist eher, daß es mehr oder weniger "fertig" ist. Echte Baustellen wo MS was großartig verbessern müsste, gibt es kaum noch. Und Altlasten wird Windows wohl immer mitschleppen müssen. Ist nämlich ein Faktor was es so erfolgreich macht: Investitionssicherheit.

Ach ja, Linux ist der Monolithkernel schlechthin. Da ist der Windowskernel echt harmlos dagegen. Eine Zeitlang hatte Linux sogar Teile des Apache Webservers drinne.

Ech ja, ich nehme irgendwelche Analysten eh' nicht ernst.

beos

2008-04-11, 11:41:21

Des weiteren:
Windows-Architekturfehler (http://osx.realmacmark.de/osx_security.php?PHPSESSID=a990aebcd4089f41cac4a32b165a867b#windows_architekturf ehler)

Undeferenzierte Unwahrheiten für unwissende Mac-User...

Jeder Mac-Überzeugte sollte sich mal die damaligen Hype Videos von Jobs bezüglich des PowerPC Prozzies anschauen (und der verglichenen schlechten x86 Architektur) und dann schauen was seit einem Jahr in den Macs steckt :wink:

ste^2

2008-04-11, 11:54:55

Undeferenzierte Unwahrheiten für unwissende Mac-User...

Jeder Mac-Überzeugte sollte sich mal die damaligen Hype Videos von Jobs bezüglich des PowerPC Prozzies anschauen (und der verglichenen schlechten x86 Architektur) und dann schauen was seit einem Jahr in den Macs steckt :wink:

was hat das eine mit dem anderem zu tun? :| und an unwahrheiten kann ich in dem link jetzt auch nicht so viel erkennen.

SavageX

2008-04-11, 12:23:01

Der Linux Kernel ist zwar ganz bestimmt kein Microkernel und, sobald gebacken, ein monolithisches Dingen. Allerdings lässt er sich trotzdem wunderbar auf kleine Geräte packen, weil man ja auch nicht alles einbauen muss, was geht.

Der Windows NT Kernel hat sich so einiges von den Microkerneln abgeschaut. Wenn man Windows monolithisch nennt, dann liegt das nicht am Kernel, sondern daran, was man bei Windows alles mitbekommt.

Bei Linux ist "Linux" der Kernel, drum herum kann sich ein OEM ein Userland zusammenbasteln, was einem passt. Bei Windows bekommt man Kompatibilität mit alten Windows-Versionen zwangsverabreicht, kriegt DirectX (in allen möglichen Versionen), kriegt OLE und COM, kriegt die Oberfläche und und und. Das ist für viele Anwender richtig und wichtig, doch wenn es halt ein wenig kleiner sein soll, dann muss man direkt zu Windows Mobile gehen - und wenn man diesen Schritt vollzieht, dann kann man ja gleich ein Linux nehmen, da eine einfache Oberfläche drüberstülpen (EeePC) und ist fertigt.

Demirug

2008-04-11, 12:26:32

Bei Linux ist "Linux" der Kernel, drum herum kann sich ein OEM ein Userland zusammenbasteln, was einem passt. Bei Windows bekommt man Kompatibilität mit alten Windows-Versionen zwangsverabreicht, kriegt DirectX (in allen möglichen Versionen), kriegt OLE und COM, kriegt die Oberfläche und und und. Das ist für viele Anwender richtig und wichtig, doch wenn es halt ein wenig kleiner sein soll, dann muss man direkt zu Windows Mobile gehen - und wenn man diesen Schritt vollzieht, dann kann man ja gleich ein Linux nehmen, da eine einfache Oberfläche drüberstülpen (EeePC) und ist fertigt.

Es gibt mit Windows Embedded noch was dazwischen. Da kann der Gerätehersteller sehr genau bestimmen was er haben möchte und was nicht.

SavageX

2008-04-11, 12:34:03

Es gibt mit Windows Embedded noch was dazwischen. Da kann der Gerätehersteller sehr genau bestimmen was er haben möchte und was nicht.

Ja, aber wenn man schon die Schere ansetzt und die Kompatibilität einschränkt, dann erscheint ein Wechsel auch nicht mehr komplett abwegig. Auf den kleinen Kisten braucht man einen Browser, einen Multimedia-Player, einen Kalender und sonstigen Kleinkram. Dafür muss man nicht unbedingt ein Windows nehmen und es sich zurechtschneidern.

Übrigens, nur mal weil mal wieder X-Window erwähnt wurde... http://www.google.de/url?sa=t&ct=res&cd=1&url=http%3A%2F%2Ficps.u-strasbg.fr%2F~marchesin%2Fnvdri%2Ffosdem1.pdf&ei=-Tz_R5GON4GIngPcn-mJCQ&usg=AFQjCNFCnq0HJSEZwc7Bj20Wz1m5b4rJlw&sig2=SBMwdabelJKh4nhDwSdxaw

(Und nein, ich glaube nicht, dass ich jemals den Niedergang von Microsoft sehen werde. Die haben bis jetzt immer die Kurve gekriegt - wenn spät, dann aber mit ganzer Kraft.)

beos

2008-04-11, 12:40:39

was hat das eine mit dem anderem zu tun? :| ...

Ganz einfach - Apple ist Meister darin, Dinge - die sie verkaufen - als megagut hinzustellen und andere Dinge als megaschlecht. Dumm nur, wenn man auf einmal die Dinge die man als schlecht verteufelt hat , selbst verbaut und dann als megagut anpreist..

Exxtreme

2008-04-11, 12:45:49

was hat das eine mit dem anderem zu tun? :| und an unwahrheiten kann ich in dem link jetzt auch nicht so viel erkennen.
Problem ist, daß der Typ nicht weiss, was das Wort "monolithisch" in Verbindung mit Kernelarchitekturen überhaupt bedeutet. Deshalb ist der halbe Artikel Bullshit. Er hat einige gute Punkte drinne wie z.B. das sehr leichtfertig designte RPC-Konzept aber ansonsten ist das ein reines Windows-Bashing und MacOS X-Gehype.

Rooter

2008-04-11, 20:07:20

Windows 3.x-Programme laufen doch schon nicht mehr unter 64Bit-Windows, oder?
Ich hab sogar ein paar Windows 95-Programme die unter Windows XP so toll und problemlos laufen wie unter Wine.Ich rede ja nicht von 10 und mehr Jahre alter Software, das man die irgendwann aufgeben muss ist klar. Ich meinte eine komplett neue Architektur auf der keine PE-EXE mehr auch nur startet. Dann wäre alle aktuelle Software für die Tonne. Man hat ja gesehen wie lange die "grossen" Softwarefirmen gebraucht haben um z.B. Viren- oder Brennsoftware für Vista fit zu machen, und da musste sicherlich deutlich unter 10% neu gecodet werden. Was denkst du wie lange die für ein völlig anderes OS bräuchten?

Jeder Mac-Überzeugte sollte sich mal die damaligen Hype Videos von Jobs bezüglich des PowerPC Prozzies anschauen (und der verglichenen schlechten x86 Architektur) und dann schauen was seit einem Jahr in den Macs steckt :wink:Wann war dieses "damals"? Welche Intel-CPUs waren da aktuell? Die Pentiums wurden doch von Generation zu Generation immer schlechter, das Netburst-Design stellte sich spätestens mit dem Prescott als Sackgasse raus. AMD64 war zwar besser, aber für Apple als Partner wohl zu klein.
Aber das die Core-Architektur eine feine Sache ist wird wohl niemand ernsthaft bestreiten.

und an unwahrheiten kann ich in dem link jetzt auch nicht so viel erkennen.Naja, er läßt aber ein paar Details unter den Tisch fallen... Z.B. schreibt er das OSX von BSD die Datenausführungsverhinderung geerbt hat, verschweigt aber das Windows XP SP2 und neuer sowas auch haben.

MfG
Rooter

beos

2008-04-11, 20:18:59

Wann war dieses "damals"? Welche Intel-CPUs waren da aktuell? Die Pentiums wurden doch von Generation zu Generation immer schlechter, das Netburst-Design stellte sich spätestens mit dem Prescott als Sackgasse raus. AMD64 war zwar besser, aber für Apple als Partner wohl zu klein.
Aber das die Core-Architektur eine feine Sache ist wird wohl niemand ernsthaft bestreiten.

Es wurde generell die x86 Architektur als "schlecht" dargestellt und in Netburstzeiten mußte auch immer ein P4 als Vergleich herhalten und kein AMD Prozessor, die ja sowohl schneller als auch sehr früh über 64 Bit verfügte.

Sven77

2008-04-11, 23:13:27

Es wurde generell die x86 Architektur als "schlecht" dargestellt und in Netburstzeiten mußte auch immer ein P4 als Vergleich herhalten und kein AMD Prozessor, die ja sowohl schneller als auch sehr früh über 64 Bit verfügte.

Trotzdem ist PPC X86 überlegen. Apple zog nur die Reissleine, da IBM keine anständigen Prozessoren, und schon gar nicht in der Menge die man brauchte liefern. In X86 steckt nunmal noch Potential, und dank dem Henne-Ei Problem wird PPC weiterhin seinen Dornröschenschlaf schlafen im grauen Sarg aka. XBOX. Aber die Zeit wird kommen..

Coda

2008-04-11, 23:14:26

Trotzdem ist PPC X86 überlegen.
Bla! Ich kann das Gefasel echt nicht mehr hören.

Das haben wir jetzt schon x-mal durchgekaut. Es ist einfach nicht mehr wahr. x86 hat auch Vorteile ggü. PowerPC unter anderem die geringer Codegröße und damit effektiv mehr Instruction-Cache. Zudem ist die MMU überlegen.

Der 16-Bit-Kompatibilitätsmodus von x86 mag archaisch wirken, aber i386 ist immer noch absolut zeitgemäß, wenn man den GPR-Count mal außer acht nimmt. Das hat AMD64 aber auch beseitigt.

Aber die Zeit wird kommen..
Ja es wird die Zeit kommen in dem vom Mobiltelefon/PDA bis zum Server alles auf x86 läuft, weil es sich immer breiter durchsetzt. Das ist nicht mehr Aufzuhalten, weil die paar Millionen Transistoren die man für x86-Kompatibilität mehr braucht in modernen Prozessoren eh investiert werden müssen (Decoder). Ja auch bei PowerPC.

Exxtreme

2008-04-11, 23:26:37

Trotzdem ist PPC X86 überlegen.
In welcher Hinsicht denn?
Aber die Zeit wird kommen..
Ich denke, die Zeit ist abgelaufen ...

beos

2008-04-11, 23:36:44

Trotzdem ist PPC X86 überlegen. Apple zog nur die Reissleine, da IBM keine anständigen Prozessoren, und schon gar nicht in der Menge die man brauchte liefern. In X86 steckt nunmal noch Potential, und dank dem Henne-Ei Problem wird PPC weiterhin seinen Dornröschenschlaf schlafen im grauen Sarg aka. XBOX. Aber die Zeit wird kommen..

Also ich kenne nur ganz spezielle Fälle, wo PPc überlegen ist....die gibt es auf alle Fälle - sind aber relativ selten ...zb - die Nutzung der SIMD Register...

Ansonsten sieht und sah es für PPC düster aus....:wink:

_DrillSarge]I[

2008-04-11, 23:38:04

aus http://osx.realmacmark.de/osx_security.php?PHPSESSID=a990aebcd4089f41cac4a32b165a867b#windows_architekturf ehler (siehe post vom ts)

Ein Sicherheitsmodell wie es von UNIX-Dateisystemen bekannt ist, bieten die Dateisysteme unter Windows nicht. Bei FAT gibt es keine Dateizugriffsrechte, was dazu führt, daß keiner und jeder der Besitzer ist, sprich vollen Zugriff auf alles hat.

Beim NTFS gibt es ebenfalls keine dem UNIX-Modell entsprechenden Datei-Besitzer oder Zugriffssteuerung, aber mit Hilfe von ACLs konnte das trotzdem umgesetzt werden.

Bei UNIX werden ACLs nur zusätzlich eingesetzt; sie sind hier jedoch nicht nötig, um Dateizugriffe einschränken zu können. Als echtes Mehrbenutzer-Betriebssystem war UNIX schon Jahrzehnte darauf ausgelegt, fehlerhafte oder unauthorisierte Datei-Zugriffe zu unterbinden. Daß das dann auch für Schadprogramme ein Hindernis ist, ist nur ein Nebeneffekt.

Dies ist einer der Punkte, an denen man sieht, daß Windows nicht als Mehrbenutzer-Betriebssystem geplant war.

wtf? wo ist der typ stehengeblieben der das geschrieben hat? bei windows98?

Bei Windows Vista wird das Risiko, daß Angriffe, die diese Eigenschaft von Windows ausnutzen, erfolgreich sind, vermindert, aber auf Kosten der Anwendungskommunikation.
hö? was meint der? spiel der auf uac an? dann aber danebengeschossen

aus dem zweiten link

Weil man alle Kunden mit dem selben System bedienen und dabei maximale Kompatibilität zu älteren Versionen und den damit einhergehenden "Altlasten" bieten wolle, würde Windows irgendwann unter seinem eigenen Gewicht ersticken, so die Prophezeiung der Analysten
erst die aussage
und gleich danach:

Darüber hinaus müsse Microsoft ein einheitliches Nutzungserlebnis unabhängig von der jeweiligen Plattform schaffen, weil zu große Inkonsistenzen bestehen, hieß es

was denn jetzt?

ergo: das sind sinnlose 0-inhalt quellen. allein schon die zweite quelle, eine mac-seite *hust*, für sowas heranzuziehen

Die Vermischung von Programmen untereinander und mit dem System. Ein Fehler in einem Programm wirkt sich auf andere Programme und das System aus. Denn Windows ist monolithisch, weil es zuviele Funktionen in den Betriebssystem-Kern integriert, wo sie unnötig viel Schaden anrichten können. So gehören beispielsweise Graphikroutinen (nicht zu verwechseln mit "Graphik-Karten-Treibern") nicht in den Kern (wie bei Windows), sondern in eine höhere Schicht (wie bei den Schichten von Mac OS X zu sehen ist, wobei beispielsweise die Lage von "Quartz" zu betrachten ist). Windows hat keine sauber getrennten Schichten, sondern ist monolithisch, was Viren leichter zu Systemrechten verhilft.
seit vista und zum teil auch xp geschichte

Bei Windows Vista wird jedoch jedes noch so kleine Programm von einem Installations-Programm installiert. Selbst wenn ein normaler Benutzer ein Programm nur für sich installieren will, kommt er um ein Installation-Programm nicht herum. Wo liegt nun die Gefahr dabei? Windows Vista zwingt den Anwender, jedes Installations-Programm unter einem Administrator, welcher unter Windows Vista Systemdateien ändern kann, wozu er im schlimmsten Fall auf "OK" oder "Fortfahren" klicken muß, auszuführen. Das bedeutet, daß jedes Installations-Programm beliebig tief im Betriebssystem herumpfuschen kann.

ist genauso müll. in vista (wieder: zTauch xp) kann ein programm, auch im admin, nicht überall rumpfuschen.
-> zudem regt sich der autor da über sicherheitsrichtlinen bei benutzern etc. auf und bemängelt dann, dass man als eingeschr. user nix installieren oder großartig verändern kann X-D

Im Gegensatz dazu bietet Windows hier eine unglaubliche Fülle von Angriffspunkten: Erstens gilt die Implementierung des TCP/IP-Protokolls in Windows als schlecht und instabil. Und zweitens strotzt Windows nur so vor mangelhaften Längenabfragen (mögliche Buffer-Overflows), die man mit dem SoftIce-Debugger finden kann
;D nee, das ist lustig. am besten vergleicht man gleich windows 3.11 vs. ein aktuelles osx. lol

ste^2

2008-04-12, 11:43:23

Das zweite Argument ist doch schon quatsch. Vista hat den Grafiktreiber eben nicht mehr im Kernel,
Er schreibt dort doch nicht vom Grafiktreiber sondern von der Grafik-API.

Grestorn

2008-04-12, 12:15:12

Er schreibt dort doch nicht vom Grafiktreiber sondern von der Grafik-API.

Und die soll etwa im Kernel sein?!

Ectoplasma

2008-04-12, 15:58:49

Ganz einfach - Apple ist Meister darin, Dinge - die sie verkaufen - als megagut hinzustellen und andere Dinge als megaschlecht. Dumm nur, wenn man auf einmal die Dinge die man als schlecht verteufelt hat , selbst verbaut und dann als megagut anpreist..

Bezogen auf Intel CPUs stimmt das so nicht, wie du es sagst.

Coda

2008-04-12, 16:02:54

Er schreibt dort doch nicht vom Grafiktreiber sondern von der Grafik-API.
Gehirn einschalten. Wenn der Treiber nicht im Kernel ist, kann es die API auch nicht sein. Abgesehen davon dass eine API nie "im Kernel" ist.

Ectoplasma

2008-04-12, 16:27:51

Und die soll etwa im Kernel sein?!

Ich kann mich dunkel erinnern, dass das GDI in Windows NT 3.1/3.5 im User-Mode lief und ab Window NT 4.0 in den Kernel wanderte. Der Grund laut Microsoft war, dass dadurch eine bessere Performance erreicht wurde. Seit Vista scheint das GDI wieder im User-Mode zu laufen.

Die Grafiktreiber selbst liefen immer im Kernel. Bei Vista scheint das ja nun anders zu sein. Habe ich jetzt aber nicht wirklich recherchiert, kann also keine Quellenangaben machen.

@Coda: Das API selbst lag zwar nie im Kernel, aber so weit ich weiss, waren große Teile der Implementierung darin.

Coda

2008-04-12, 16:34:48

Ja. "Waren" ist das Stichwort.

grandmasterw

2008-04-13, 22:21:55

Grestorn

2008-04-14, 11:05:00

Drollig, am Mac gibts ein ~\applications, und unter Windows nicht? Es gibt zig Installer, die mit Benutzerrechten funzen, wenn man das Programm halt in ein Verzeichnis installiert, wo man Schreibrechte hat. Für bestimmte Sachen braucht man halt mit gutem Grund Adminrechte, drum brauchens die Installer dann halt auch.

Es ist keine gute Idee, Executables im User-Space liegen zu haben. Natürlich geht das (auch unter Windows), aber es ist weder Standard noch empfehlenswert. Auch nicht auf dem Mac oder unter Unix.

Eigentlich ist dies sogar eine heftige Sicherheitslücke.

Ectoplasma

2008-04-14, 11:12:03

Eigentlich ist dies sogar eine heftige Sicherheitslücke.

Hmm, verstehe ich jetzt nicht. Weil man das Programm auch aus dem User-Space modifizieren kann oder warum? Ich meine wenn ein User solche Programme installiert hat, dann können sie auch nur im User-Mode laufen, es sei denn ein Admin führt das Programm aus. Aber das ist doch sowieso ein grundsätzliches Problem, wenn ein Admin ein Programm startet.

Monger

2008-04-14, 11:44:44

Hmm, verstehe ich jetzt nicht. Weil man das Programm auch aus dem User-Space modifizieren kann oder warum?

Du hast dann im User-Space Schreibrechte auf ausführbare Daten. Das würde ich auch mal als äußerst hässliche Sicherheitslücke werten.

Unter Vista ist das ziemlich knallhart geregelt: Programme können nur Daten in den eigenen Dateien schreiben. Ein Programm hat nichtmal Schreibrechte auf die eigenen Installationsdateien, was z.B. auch der Grund ist weshalb unter Vista keine Konfigurationsdateien o.ä. mehr im Installationsverzeichnis liegen dürfen.
Das ist ja auch eigentlich der Grund, weshalb eine Installation Admin-Rechte erfordert. Wenn man keine Verknüpfungen, Registry Keys o.ä. anlegt, könnte man im Prinzip auch mit User Rechten ins User Verzeichnis reininstallieren. Technisch gesehen ist das kein Problem, nur glücklicherweise unter Windows verpönt.

Dass man unter Mac dieses "Problem" einfach dadurch umgeht indem man einfach alles in den User Space schaufelt, finde ich schon etwas bizarr.

grandmasterw

2008-04-14, 12:48:16

Stray_bullet

2008-04-14, 14:45:26

...
Ja es wird die Zeit kommen in dem vom Mobiltelefon/PDA bis zum Server alles auf x86 läuft, weil es sich immer breiter durchsetzt....

Das dauert bestimmt noch ein Weilchen, wenn man sich die Vorherrschaft der ARM-Architektur für mobile Anwendungen mal ansieht.

Es gibt unzählige SOC-Designs auf ARM-Basis von TI, Freescale, Samsung, Toshiba, Marvell, NXP etc.. bis jetzt bemerkt man keine Bestrebungen auf X86 umzuschwenken.

Coda

2008-04-14, 15:34:44

Intel Atom?

Ectoplasma

2008-04-14, 15:38:32

@Monger

Ich sehs eher wurschtig. Die Programme werden dann normalerweise auch vom User gestartet, und können daher nicht soo viel anrichten.
Das Verhalten vom User darf fürs System sowieso keine Sicherheitslücke darstellen - sonst ist die Trennung in User und Admins für die Katz. Solang der User nur sein eigenes Profil damit schrotten kann, ists ok.

Genau so sehe ich das auch. Und ausserdem ...

Unter Vista ist das ziemlich knallhart geregelt: Programme können nur Daten in den eigenen Dateien schreiben. Ein Programm hat nichtmal Schreibrechte auf die eigenen Installationsdateien ...

kann man das von dir beschriebene Verhalten auch schon seit Win NT 3.1 so konfigurieren. Leider hat MS das versäumt, wie so vieles in Bezug auf Sicherheit.

Grestorn

2008-04-14, 16:39:47

Ich sehs eher wurschtig. Die Programme werden dann normalerweise auch vom User gestartet, und können daher nicht soo viel anrichten.
Das Verhalten vom User darf fürs System sowieso keine Sicherheitslücke darstellen - sonst ist die Trennung in User und Admins für die Katz. Solang der User nur sein eigenes Profil damit schrotten kann, ists ok.

Was ihr überseht ist dass Schadprogramme zunächst praktisch immer im Kontext des Users laufen (denn auch der Browser, das E-Mail Tool und der Windows-Explorer laufen mit Userrechten und damit auch alle über diese Wege gestarteten Programme).

Damit ist für diese Schadprogramme zunächst nur mal das veränderbar, was auch der User ändern darf. Wenn keine Executables für den User schreibbar sind, tut sich ein Schadprogramm ungleich schwerer, sich irgendwo festzsetzen oder Programme und Daten zu manipulieren.

Deswegen ist es ein Grundgesetz, dass Executables im User-Space nichts verloren haben.

Ectoplasma

2008-04-15, 08:39:18

Wenn keine Executables für den User schreibbar sind, tut sich ein Schadprogramm ungleich schwerer, sich irgendwo festzsetzen oder Programme und Daten zu manipulieren.

Deswegen ist es ein Grundgesetz, dass Executables im User-Space nichts verloren haben.

Sorry aber irgendwie klingt das nach Pseudosicherheit. Ich meine ich leide schon an "Verfolgungswahn", in dem der Internet-Browser sogar mit einem anderen User als dem eingeloggten läuft (auf dem gleichen Desktop). Aber ich kann mir kein Szenario vorstellen, welches du beschreibst. Warum ein User keine Executables speichern können soll ist mir immer noch nicht aufgegangen. Kannst du deine These irgendwie mit einer Referenz untermauern oder es mit einem geeigneten Szenario erklären, wie sich eine Sicherheitslücke ergeben kann, die sich evtl. nicht auch anders ergeben kann.

Grestorn

2008-04-15, 09:05:31

Sorry aber irgendwie klingt das nach Pseudosicherheit. Ich meine ich leide schon an "Verfolgungswahn", in dem der Internet-Browser sogar mit einem anderen User als dem eingeloggten läuft (auf dem gleichen Desktop). Aber ich kann mir kein Szenario vorstellen, welches du beschreibst. Warum ein User keine Executables speichern können soll ist mir immer noch nicht aufgegangen. Kannst du deine These irgendwie mit einer Referenz untermauern oder es mit einem geeigneten Szenario erklären, wie sich eine Sicherheitslücke ergeben kann, die sich evtl. nicht auch anders ergeben kann.

Na, ganz einfach: Ein Schadprogramm scanned "Eigene Dateien" nach ausführbaren Programmen und infiziert sie.

Dass dies momentan eher nicht gemacht wird, liegt schlicht daran, dass die meisten User immer noch als Admin unterwegs ist und das Schadprogramm deswegen gleich alles auf der Platte infizieren kann und sich nicht auf Dateien im User-Space beschränken muss.

Ganon

2008-04-15, 09:20:07

Grestorn

2008-04-15, 09:25:48

OS X (und afaik auch Windows, weiß es aber nicht genau) merken, wenn eine Binary seit dem letzten Ausführen geändert wurde und gibt eine entsprechende Warnung aus. OS X zeigt dabei auch an, von welcher Webseite das Programm kam.

Weiterhin werden die meisten neueren OS X-Programme mit einer Code-Signatur versehen, womit eine Änderung durch einen Virus deutlich erschwert wird (kA ob es da überhaupt eine Möglichkeit gibt). Das bietet afaik auch Windows.

Da man die Signatur-Datenbank (sicherlich nur) als Administrator ändern kann, ist diese Maßnahme ziemlich überflüssig.

Man hat bereits ein Berechtigungssystem für das Ändern dieser Dateien. Es ist völlig sinnbefreit da noch etwas drüberzustülpen.

Wenn ein Schadprogramm Admin-Rechte hat, kann es auch die Signatur-Datenbank anpassen. Wenn nicht, dann dürfte es bei einem korrekt umgesetzten Rechtesystem sowieso nicht in der Lage sein, die Exes zu schreiben.

An dieser Stelle hat Apple die falsche Lösung für ein gar nicht existierendes Problem implementiert. Auch ein Grund, warum ich Personal Firewalls und permanent überwachende Virenscanner ablehne, beides eigentlich völlig überflüssige Dinge.

Ganon

2008-04-15, 09:47:33

Wenn ein Schadprogramm Admin-Rechte hat, kann es auch die Signatur-Datenbank anpassen. Wenn nicht, dann dürfte es bei einem korrekt umgesetzten Rechtesystem sowieso nicht in der Lage sein, die Exes zu schreiben.

Dazu muss das Programm aber auch erst mal ausgeführt werden. Und da kommt ja, wie gesagt, die Warnung.

An dieser Stelle hat Apple die falsche Lösung für ein gar nicht existierendes Problem implementiert.

Sicherheitslücken kann man nicht verhindern. Menschen machen Fehler. So bringt es absolut nichts, wenn man sich nur auf die User-Rechte verlässt. Entsprechend sind solche Prüfungen sinnvoll.

Auch ein Grund, warum ich Personal Firewalls und permanent überwachende Virenscanner ablehne, beides eigentlich völlig überflüssige Dinge.

In einem perfekten System mit fehlerfreiem User sind sie sicher überflüssig. Aber beides gibt es nicht mal im Ansatz. Auch du machst sicher irgendwo mal Fehler ;)

Und alles kann man irgendwie irgendwo aushebeln. Da braucht man nicht drüber reden.

Grestorn

2008-04-15, 09:50:11

Dazu muss das Programm aber auch erst mal ausgeführt werden. Und da kommt ja, wie gesagt, die Warnung.

Wir reden von Schadprogrammen, die über den Browser, E-Mail oder anderen Wegen eindringen...

Sicherheitslücken kann man nicht verhindern. Menschen machen Fehler. So bringt es absolut nichts, wenn man sich nur auf die User-Rechte verlässt. Entsprechend sind solche Prüfungen sinnvoll.

Sind sie nicht, wenn es schon ein funktionierendes Schutzsystem gibt und die Prüfung keine zusätzlichen, nennenswerten Hürden einbaut. Eine als Admin änderbare Datenbank ist genauso leicht oder schwer zu umgehen wie das Datei-Rechtesystem.

Ganon

2008-04-15, 09:58:12

Wir reden von Schadprogrammen, die über den Browser, E-Mail oder anderen Wegen eindringen...

Bei beiden gibt es ebenfalls eine Warnung, sofern keine Sicherheitslücke genutzt wurde. Und bei root-Zugriff hilft eh nichts mehr, auch nicht das beste Sicherheitssystem.

Sind sie nicht, wenn es schon ein funktionierendes Schutzsystem gibt und die Prüfung keine zusätzlichen, nennenswerten Hürden einbaut. Eine als Admin änderbare Datenbank ist genauso leicht oder schwer zu umgehen wie das Datei-Rechtesystem.

Du sprachst davon, dass ein Virus ein Programm infiziert. Die Code-Signierung wird an jede Methode einkompiliert. D.h. ein Virus könnte dann, wenn überhaupt, nur ein einzelnes Programm infizieren und müsste vorher das halbe Binary ändern (wäre dazu auch noch Versions- und Architekturabhängig). "Was dran klatschen" hilft da nicht. Entsprechend würde das Programm nicht starten.

Die allgemeine Signatur, die von OS X erstellt wird, ist ja nur ein Zusatz. Diese wird auch zum Binary hinzugefügt. Es gibt keine "Datenbank". D.h. auch hier müsste erst mal gefunden werden was gelöscht werden muss.

iDiot

2008-04-15, 09:58:43

Hier mal was zum Threadtitel:
http://community.winsupersite.com/blogs/paul/archive/2008/04/12/the-great-windows-collapse-of-2011.aspx
Jump ahead to today and the world has changed. The Windows Vista platform, as an extension of that XP SP2 platform, is far more secure and, more important from an architectural standpoint, far more modular and componentized (read: less monolithic) than its predecessors. In fact, you can see how its becoming even more modular and componentized (and thus less monolithic) over time via technologies like image-based setup and deployment (Vista, 2006), Server Core (Windows Server 2008, 2008), and MinWin (expected Windows 7, 2010). So Windows is actually evolving over time from an architectural standpoint. And it is doing so by sacrificing backwards compatibility as little as possible. (Though, oddly, everyone is complaining about how poor a job Vista does in this regard.)

Und auch noch auf ZDNet:
http://blogs.zdnet.com/microsoft/?p=1331

* As has been reported previously, Windows 7 is likely to include a feature that, at least at one point, was called the “Component Delivery System” which is expected to allow users to install the pieces of Windows that they want and need in a more user-configurable way. This may not be identical to the modularized role structure offered in Windows Server 2008, but it is similar in its intention. This should help, to some extent, with Windows’ bloat — as should Microsoft’s expected move to use Windows Live to deliver non-core pieces of functionality to users.

Grestorn

2008-04-15, 10:03:48

Bei beiden gibt es ebenfalls eine Warnung, sofern keine Sicherheitslücke genutzt wurde. Und bei root-Zugriff hilft eh nichts mehr, auch nicht das beste Sicherheitssystem.

Ja eben: Der Browser läuft im Userkontext und damit auch jede Software, die über eine Sicherheitslücke (und nur darüber reden wir) eindringt.

Und damit hat die Schad-SW eben keine root-Rechte!

Und deswegen ist ein Dateischutz völlig ausreichend.

Für die Fälle, in denen er nicht ausreicht, hilft auch Dein Signierungssystem nichts mehr. Genau darauf will ich die ganze Zeit hinaus.

Du sprachst davon, dass ein Virus ein Programm infiziert. Die Code-Signierung wird an jede Methode einkompiliert. D.h. ein Virus könnte dann, wenn überhaupt, nur ein einzelnes Programm infizieren und müsste vorher das halbe Binary ändern (wäre dazu auch noch Versions- und Architekturabhängig). "Was dran klatschen" hilft da nicht. Entsprechend würde das Programm nicht starten.

Der Virus muss dann doch nur die Signierung korrigieren... Und das muss mit root-Rechten doch problemlos möglich sein. Sonst könnte man ja kein neues Exec ins System einbringen.

Und ohne Root-Rechte kann der Virus die Datei - wenn sie korrekte Rechte hat und nicht im User-Space liegt - ja sowieso nicht verändern.

Womit wir wieder am Anfang meiner Argumentation wären. Code-Signierung ist schlicht und einfach komplett überflüssig.

Ganon

2008-04-15, 10:34:28

Ja eben: Der Browser läuft im Userkontext und damit auch jede Software, die über eine Sicherheitslücke (und nur darüber reden wir) eindringt.
Und damit hat die Schad-SW eben keine root-Rechte!
Und deswegen ist ein Dateischutz völlig ausreichend.
Für die Fälle, in denen er nicht ausreicht, hilft auch Dein Signierungssystem nichts mehr. Genau darauf will ich die ganze Zeit hinaus.

Wie schon gesagt liegt die Signierung nicht in einer externen Datenbank.

Der Virus muss dann doch nur die Signierung korrigieren...

"Nur" ist gut. Man muss auch "nur" zwei Atome fusionieren um Energie zu gewinnen. ;) Entsprechend würde ein Virus auch nur mit einer entsprechenden Programmversion-/architektur funktionieren.

Und ohne Root-Rechte kann der Virus die Datei - wenn sie korrekte Rechte hat und nicht im User-Space liegt - ja sowieso nicht verändern.

Sicher, das ist aber, wie ich schon gesagt hatte, auch kein Allheilmittel.

Die Kombination macht's.

Grestorn

2008-04-15, 10:55:28

"Nur" ist gut. Man muss auch "nur" zwei Atome fusionieren um Energie zu gewinnen. ;) Entsprechend würde ein Virus auch nur mit einer entsprechenden Programmversion-/architektur funktionieren.Das Signieren muss ja mit ausreichenden Rechten problemlos machbar sein, sonst hätten jede Menge Installations- und Updateroutinen ein echtes Problem.

Die Kombination macht's.

Ich bin anderer Ansicht. Signierung ist überflüssig, da sie keinerlei zusätzliche Sicherheit bringt.

Ich bleibe dabei: Executables haben im User-Space nichts verloren, da ungeschützt. Wenn man Exes im Userspace zulässt aber durch Signatur schützt, dann ist das widersinnig, denn dann kann der User sie ja auch nicht mehr ändern (ohne Root-Rechte). Da hätte er der Datei auch gleich die korrekten Rechte zuordnen können...

Ganon

2008-04-15, 11:02:52

Das Signieren muss ja mit ausreichenden Rechten problemlos machbar sein, sonst hätten jede Menge Installations- und Updateroutinen ein echtes Problem.

Ähm, noch mal: die Signatur wird vom Entwickler der Software >einkompiliert<.

Grestorn

2008-04-15, 11:04:49

Ähm, noch mal: die Signatur wird vom Entwickler der Software >einkompiliert<.

Also so etwas wie die Treibersignatur bei Windows?

Und was ist mit nicht signierten Dateien?

Ganon

2008-04-15, 11:29:54

Also so etwas wie die Treibersignatur bei Windows?

Kenne die Treibersignatur von Windows nicht. Das Programm bekommt halt eine Checksumme (afaik für jede Methode) und noch ein paar weitere "Original-Prüfungen" (Hersteller-Zertifikat, etc.). Sagte ich ja bereits.

Und was ist mit nicht signierten Dateien?

Da passiert nicht viel. OS X merkt sich halt die Checksumme und signiert die Anwendung nach, wenn der User die Frage nach dem Ausführen bejat hat. Das geht natürlich nur grob.

Grestorn

2008-04-15, 12:31:35

Da passiert nicht viel. OS X merkt sich halt die Checksumme und signiert die Anwendung nach, wenn der User die Frage nach dem Ausführen bejat hat. Das geht natürlich nur grob.

Ah so was wie UAC, verbunden mit einer dauerhaft gespeicherten Signatur, damit man den Start beim nächsten Mal nicht erneut bestätigen muss...

Wie macht MacOS das mit Programm-Modulen, die eine Applikation dynamisch nachlädt? Die kann es ja schlecht mitsignieren, da es davon u.U. ja gar nichts weiß... Und jedesmal nachfragen wäre auch nicht der Hit...

Also ich sehe da immer noch einige Detailprobleme!

Ganon

2008-04-15, 13:10:14

Wie macht MacOS das mit Programm-Modulen, die eine Applikation dynamisch nachlädt? Die kann es ja schlecht mitsignieren, da es davon u.U. ja gar nichts weiß... Und jedesmal nachfragen wäre auch nicht der Hit...

So tief geht es ja auch nicht. Solche tiefe Signierung muss vom Entwickler erfolgen.

Apple beschreibt in den Support-Dokumenten was man signieren sollte und was nicht.

Grestorn

2008-04-15, 13:45:19

So tief geht es ja auch nicht. Solche tiefe Signierung muss vom Entwickler erfolgen.

Apple beschreibt in den Support-Dokumenten was man signieren sollte und was nicht.

Und was hindert dann das Schadprogramm, ein unsigniertes Pluginmodul auszutauschen, wenn dies nur im Userspace liegt?

Ganon

2008-04-15, 15:27:52

Und was hindert dann das Schadprogramm, ein unsigniertes Pluginmodul auszutauschen, wenn dies nur im Userspace liegt?

Sofern die Entwickler ihre PlugIns signieren, geht das nicht.

Grestorn

2008-04-15, 15:39:19

Sofern die Entwickler ihre PlugIns signieren, geht das nicht.

Zum Signieren braucht man ein kostenpflichtiges Trusted Certificate... Genau das, was man ja Vista64 vorwirft. Nur dass Treiberentwickler damit normalerweise weniger Probleme haben als Entwickler irgendwelcher Plugins für irgendwelche Software.

Monger

2008-04-15, 15:42:18

Sofern die Entwickler ihre PlugIns signieren, geht das nicht.
Durchgängige Signierung von allen Plugins?

In der Windows Welt würdest du für so einen Vorschlag Proteststürme und Kopfschütteln ernten.

Grestorn

2008-04-15, 15:53:59

@Ganon:

Hier wird von dem von Dir beschriebenen Sicherheitssystem nichts erwähnt: http://de.wikipedia.org/wiki/Mac_OS_X#Sicherheit

Kannst Du mir bitte dazu irgendwelche Links geben, die da tiefer informieren? Mich interessiert das ernsthaft, ich würde gerne wissen über was ich diskutiere.

Schnuller4u

2008-04-15, 16:49:00

6.0.2.4 Signierte Programme: Leopard contra Viren:
http://macmark.de/osx_security.php#codesign

Guides Security:
http://developer.apple.com/documentation/Security/index.html

Code Signing Release Notes for Mac OS X v10.5:
http://developer.apple.com/releasenotes/Security/RN-CodeSigning/index.html

Code Signing Guide:
http://developer.apple.com/documentation/Security/Conceptual/CodeSigningGuide/Introduction/chapter_1_section_1.html

Mac OS X Security - PDF
http://images.apple.com/macosx/pdf/MacOSX_Leopard_Security_TB.pdf

Grestorn

2008-04-15, 16:55:13

6.0.2.4 Signierte Programme: Leopard contra Viren:
http://macmark.de/osx_security.php#codesign

Danke. Apple mal wieder als Vorreiter. Bei MS hätte man das sofort übelst verurteilt.

Da auch Viren signiert sein können, sehe ich aber dennoch recht wenig Sinn ist dieser Aktion, wenn ich ehrlich sein soll...

Es sei denn, man stellt sehr hohe Ansprüche an die Verteilung der Zertifikate, so dass ein Virenprogrammierer mit der Signierung auch seine Identität preisgeben müsste.

Aber wenn die Anforderungen so hoch sind, würgt das allen OSS und Freeware Projekten nachhaltig die Grundlage ab. Ein interessanter Konflikt... Wobei die Linie, die Apple hier fährt, schon längst abzusehen ist. iPhone anyone?

Apple wird zum viel schlimmeren M$ als Microsoft jemals war ... :)

MacMark

2008-04-15, 17:43:35

Signierte Programm-Updates:
http://developer.apple.com/documentation/Security/Conceptual/CodeSigningGuide/Procedures/chapter_3_section_5.html
Mehr Infos im übergeordneten Kapitel dort.

Generell sollen alle Anbieter ihre Programme signieren für OS X Leopard:
http://developer.apple.com/documentation/Security/Conceptual/CodeSigningGuide/Procedures/chapter_3_section_4.html

Zwar kann auch signierter Code durch Viren verändert werden, aber da der Angreifer den privaten Schlüssel des Autors der angegriffenen Software nicht kennt, wird die Signatur durch die Änderung am signierten Code auf jeden Fall ungültig. Eine erneute korrekte Signierung kann der Angreifer aus dem gleichen Grund ebenfalls nicht durchführen. Es würde dem Angreifer auch nichts nützen, wenn er Root wäre, denn auch Root kann ohne Kenntnis des privaten Schlüssels des Autors, keine korrekte Signierung vornehmen.

Meines Wissens hält Leopard zur Zeit kein unsigniertes oder fehlerhaft signiertes Programm vom Starten ab. Das wird wahrscheinlich in Zukunft erst eingeführt.

Jeder kann das Vorhandensein und die Gültigkeit der Signatur eines Programms so prüfen:
http://www.macmark.de/osx_security.php#codesign

Edit:
Wenn der Angreifer das Programm ändert und neu signiert, dann kann er das nur mit einer anderen Signatur, die ungleich der des Originalautors ist. Dann steht in der Signatur nicht mehr "Adobe", sondern etwas anderes.

Bestimmte Sicherheitsmechanismen in Leopard, bespielsweise "parental control" und die "Application Firewall" basieren ihre Regeln auf Signaturen. Sind für das Programm Photoshop15.app bestimmte Regeln eingestellt, dann gelten diese Regeln nicht mehr für ein infiziertes Photoshop15.app. Auch das fällt gegebenenfalls auf.

Zur Programm-Installation per Drag&Drop im Home:
JoeMacUser besorgt sich Virus.app, ein tolles Programm, das leider mit einem Virus infiziert ist. Er kopiert es per Drag&Drop in sein ~/Applications. Sicher kann dann das private Programm Virus.app des Normal-Benutzers "JoeMacUser" im schlimmsten Fall alles in seinem Home infizieren. Da es aber nur von JoeMacUser gestartet werden kann, bleibt die Ausbreitung auf /Users/JoeMacUser beschränkt.

Unter Vista verlangt eine Programminstallation üblicherweise Admin-Rechte:
http://blogs.msdn.com/onoj/archive/2007/04/20/windows-vista-uac-and-installer-detection.aspx
JoeVistaUser besorgt sich VirusSetup.exe, ein tolles Programm, das leider mit einem Virus infiziert ist. VirusSetup.exe verlangt Adminrechte und kann ohne diese nicht installiert werden. Da JoeVistaUser, dieses Programm will, bekommt es diese Adminrechte und infiziert nicht nur Dateien in JoeVistaUsers Benutzerverzeichnis, sondern auch außerhalb davon. Das installierte Virus.exe kann auch von anderen VistaUsern, ErnaVistaUser und 3dVistaUser, genutzt werden und infiziert auch deren Dateien.

Wie man hieran leicht sieht, beschränkt die Drag & Drop-Installation ins User-Home die Infektionsausbreitung eines Virus unter OS X während bei Vista eine breitere Infektion stattfinden kann.

Zum Glück erzwingt Vista NTFS als Bootpartition. Ältere Windows-Versionen erlaubten FAT-Dateisysteme, die keinerlei Resourcen-Besitz kennen und daher einem Virus die ganze Platte als Opfer bieten.

Noch eine Anmerkung zu falschem Sprachgebrauch: Ein "User Space" ist nichts, was man auf der Platte findet. Der User Space sind die Bereiche im Hauptspeicher, die zu User-Prozessen gehören und nicht zu Kernel-Prozessen. Edit: Insbesondere kann man also nichts im User Space "installieren".

Schnuller4u

2008-04-15, 18:52:04

Aber im Regelfall zieht man doch per Drag'N'Drop die Programme unter OS X in den Application-Ordner und dafür braucht man Admin-Rechte. Ist man als Standard-User unterwegs wird man dann nach dem Admin-Passwort gefragt.
Im Application-Ordner steht das Programm dann auch allen Usern im System zur Verfügung.

Ja ich weiss auch, dass man nicht gezwungen ist das Programm in den Application-Ordner zu ziehen (mit Ausnahmen von Programmen, die per Installer daher kommen).

Rooter

2008-04-15, 19:48:12

Sicher kann dann das private Programm Virus.app des Normal-Benutzers "JoeMacUser" im schlimmsten Fall alles in seinem Home infizieren. Da es aber nur von JoeMacUser gestartet werden kann, bleibt die Ausbreitung auf /Users/JoeMacUser beschränkt.
Wie mein Vorredner schon schrieb sind nötige Adminrechte doch das Verhängnis. Was wenn Administrator oder Root irgend etwas aus dem verseuchten Home von JoeMacUser aufrufen?

MfG
Rooter

MacMark

2008-04-15, 21:21:20

… Ist man als Standard-User unterwegs wird man dann nach dem Admin-Passwort gefragt…
Man muß sich, falls Normalo, als ein User der Admin-Gruppe authentifizieren, das heißt: Den Namen eines Admin-Users und dessen Paßwort eingeben.

Die UNICES haben normalerweise ja auch ein ~/bin-Verzeichnis für Shell-Programme. Man will doch nicht, daß jeder User systemweit Programme installiert. Analog ist ~/Applications zu sehen.

… Was wenn Administrator oder Root irgend etwas aus dem verseuchten Home von JoeMacUser aufrufen? …

User der Admin-Gruppe haben auf Privatordner anderer User keinen Zugriff. (Edit: Genauer gesagt auf dessen Unterverzeichnisse "Documents, Library, Photos, Movies, ..." hat sonst keiner Zugriff. Auf "Sites", die Webseiten des Benutzers, gibt es Leserechte und auf "Public/Drop Box", den Briefkasten, gibt es Schreibrechte.) Außer root kann in diese Verzeichnisse sonst keiner rein. Und als root kann man sich per default nicht anmelden auf OS X. Wenn ein Admin per sudo dort einbricht, ist er selbst schuld. Es ist also nicht aus Versehen möglich. Über die GUI per default sogar überhaupt nicht.

Ganon

2008-04-16, 07:24:16

Aber wenn die Anforderungen so hoch sind, würgt das allen OSS und Freeware Projekten nachhaltig die Grundlage ab.

Grund?

Ganon

2008-04-16, 07:28:23

Durchgängige Signierung von allen Plugins?

In der Windows Welt würdest du für so einen Vorschlag Proteststürme und Kopfschütteln ernten.

Äh, ob die PlugIns signiert sind, oder das Programm nur signierte PlugIns ausführt sind immer noch 2 paar Schuhe. Ich glaube eine verwechseln hier ganz gewaltig irgendetwas.

Grestorn

2008-04-16, 07:31:42

Grund?

Na, genau der selbe, der bei Windows angeführt wird: Die Kosten für das Trusted Certificate...

Äh, ob die PlugIns signiert sind, oder das Programm nur signierte PlugIns ausführt sind immer noch 2 paar Schuhe. Ich glaube eine verwechseln hier ganz gewaltig irgendetwas.

Wenn das Programm auch nicht zertifizierte Plugins ausführt, dann ist das ganze Verfahren ausgehebelt.

Monger

2008-04-16, 08:18:28

Äh, ob die PlugIns signiert sind, oder das Programm nur signierte PlugIns ausführt sind immer noch 2 paar Schuhe. Ich glaube eine verwechseln hier ganz gewaltig irgendetwas.
Welcher Softwarehersteller signiert denn seine Software freiwillig?
Sicherheit gegen Viren ist für Anwendungen kein Verkaufsargument, das ist in Augen des Kunden Aufgabe des Betriebssystems.
Zu glauben, dass freiwillig alle Entwickler diese Signierung auf sich nehmen, nur damit der Mac sicherer wird, ist arg utopisch.

Na, genau der selbe, der bei Windows angeführt wird: Die Kosten für das Trusted Certificate...

Vorallem wenn man bedenkt, wie groß das Geschrei unter Vista war. Und das, obwohl sich die Signierung nur auf Kernel Treiber, und (nach viel äußerem Druck) nur auf die 64Bit Variante bezieht.
Schließlich will der Anwender seinen 5 Jahre alten, thailändischen No-Name Scanner immer noch benutzen können...

Ganz normale Anwendungssoftware zu signieren, wäre völlig utopisch. Vorallem, da in der Open Source Szene ja es üblich ist, eigene Builds zu machen - und diese natürlich immer signiert werden müssen.

Ganon

2008-04-16, 08:31:57

Na, genau der selbe, der bei Windows angeführt wird: Die Kosten für das Trusted Certificate...

Und wo steht bitte das die Signierung >nötig< ist, um zu starten (so wie unter Windows?). Bleibt mal auf dem Teppich. Das ist eine Sicherheitsfunktion gegen Binary-Manipulation.

Zumal selbst OpenSource-Firmen wie Mozilla ihre Zertifikate längst haben. Können sie Problemlos nutzen.

"Normale" OpenSource-Software wird eh auf anderem Weg installiert und läuft dann halt ohne Code-Signierung. Da wird nichts ausgehebelt...

Wenn das Programm auch nicht zertifizierte Plugins ausführt, dann ist das ganze Verfahren ausgehebelt.

Es ist trotzdem noch ein Unterschied ob wir von einem PlugIn ohne Signatur reden oder von einem PlugIn mit ungültiger Signatur.

Welcher Softwarehersteller signiert denn seine Software freiwillig?

Ich seh das Problem immer noch nicht. Zumal Firmen ihre Zertifikate sowieso schon haben.

Sicherheit gegen Viren ist für Anwendungen kein Verkaufsargument, das ist in Augen des Kunden Aufgabe des Betriebssystems.

Darum signiert OS X die Software auch nach, wenn sie keine hat. OS X warnt dann auch, wenn sich das Binary ändert. Ist sie offiziell signiert und das Binary nach Änderung noch gültig (z.B. nach einem Update), gibt es keine Warnung.

Zu glauben, dass freiwillig alle Entwickler diese Signierung auf sich nehmen, nur damit der Mac sicherer wird, ist arg utopisch.

Klappt bisher ganz gut. Zumal OS X in einigen Sicherheitsfunktionen (FireWall, Key-Chain, ParentalControl) von OS X nutzt, wie oben schon erwähnt.

Vorallem wenn man bedenkt, wie groß das Geschrei unter Vista war. Und das, obwohl sich die Signierung nur auf Kernel Treiber, und (nach viel äußerem Druck) nur auf die 64Bit Variante bezieht.

Da ging es ja auch darum das NUR signierte Sachen laufen.

Schließlich will der Anwender seinen 5 Jahre alten, thailändischen No-Name Scanner immer noch benutzen können...

Kann er in OS X Problemlos.

Vorallem, da in der Open Source Szene ja es üblich ist, eigene Builds zu machen - und diese natürlich immer signiert werden müssen.

Können, nicht müssen.

Grestorn

2008-04-16, 08:39:02

Und wo steht bitte das die Signierung >nötig< ist, um zu starten (so wie unter Windows?). Bleibt mal auf dem Teppich. Das ist eine Sicherheitsfunktion gegen Binary-Manipulation.

Na, wenn das Zertifikat für die Ausführung nicht nötig ist, dann ist es auch kein Schutz gegen Viren. Dann schleust das Schadprogramm eben unsignierten Code in den User-Space *) ein.

Und damit sind wir wieder bei Punkt 0: Es ist absolut keine gute Idee, ausführbaren Code im User-Space zu haben.

*) MacMark: Wer das Wort "User-Space" wie verwendet, ist nicht festgelegt. Nicht von Dir oder von irgendjemand sonst. Allgemein denke ich ist es naheliegend, den Begriff so zu definieren, dass man damit jegliche Resource meint, auf die der User freien Zugriff hat.

Ganon

2008-04-16, 09:29:04

Na, wenn das Zertifikat für die Ausführung nicht nötig ist, dann ist es auch kein Schutz gegen Viren. Dann schleust das Schadprogramm eben unsignierten Code in den User-Space *) ein.

So noch mal: Die Code-Signierung ist dazu da um zu prüfen ob ein Programm ein "Original" ist. Es verhindert das Programme manipuliert oder sonst was wurden. Die Code-Signierung stellt sicher das eine ausführbare Datei das macht was vom Hersteller vorgesehen wurde.

Die Code-Signierung ist KEIN Schutz (hab ich auch nirgendwo behauptet) gegen "unerlaubten" Code (dies kommt vllt. mal auf dem iPhone, aber sicher nicht in OS X). D.h. durch eine Sicherheitslücke, etc. kann immer noch Schadcode eingeschleust werden. Es können nur keine Binaries angegriffen werden, die signiert sind. (darum ging es hier ja). Das heißt der Schadcode kann im Regelfall nur ein mal ausgeführt werden. Es kann sich nicht irgendwo "einnisten". Darum auch der Unterschied zwischen "unsigniertem PlugIn" und "fehlerhaftem PlugIn".

Führst du ein unsigniertes Programm manuell aus (bzw. Safari oder Mail tut es, je nach Einstellung), kommt eine WARNUNG, nach JEDER Änderung des Programms. Führst du ein runtergeladenes Programm zum ersten mal aus, kommt immer eine Warnung.

Ist es jetzt verständlich?

Grestorn

2008-04-16, 09:33:06

Ist es jetzt verständlich?

Ja, aber warum hast Du selbst es dann als Argument ins Feld geführt, als ich schrieb, dass Executables im User-Space nichts verloren haben? Für diese Problematik ist das Verfahren doch keine Lösung...

Ganon

2008-04-16, 09:36:20

Für diese Problematik ist das Verfahren doch keine Lösung...

Weil eine signierte Anwendung (ob nun vom Hersteller oder von OS X nachträglich), nach einer Virenmanipulation nicht oder nur mit einer Warnung startet. Da ist es vollkommen egal wo die Anwendung liegt.

Grestorn

2008-04-16, 09:39:15

Weil eine signierte Anwendung (ob nun vom Hersteller oder von OS X nachträglich), nach einer Virenmanipulation nicht oder nur mit einer Warnung startet. Da ist es vollkommen egal wo die Anwendung liegt.

Und wieder drehen wir uns im Kreis... Plugins können nicht signiert werden. Es gibt sicher auch andere Teile einer Applikation, die ausführbar sind aber nicht signiert sind, wenn sie nur automatisch vom OS signiert wurden.

Ganon

2008-04-16, 09:44:25

Und wieder drehen wir uns im Kreis... Plugins können nicht signiert werden.

Eben doch. Ich sagte ja schon mehrmals das es einen unterschied zwischen unsignierten und fehlerhaften PlugIns gibt. Und wenn du eine Anwendung hast die wahllos irgendwelche PlugIns ohne Warnung ausführt, dann liegt das Problem bei der Anwendung und nicht beim Betriebbsystem.

Zumal PlugIn-Anwendungen ja nun kein Regelfall ist.

Es gibt sicher auch andere Teile einer Applikation, die ausführbar sind aber nicht signiert sind, wenn sie nur automatisch vom OS signiert wurden.

Darum bittet Apple ja auch alles zu signieren was Code enthält. Ob Bibliotheken, Frameworks, etc. Apple beschreibt das in ihrem Dokument recht deutlich (wurde oben bereits verlinkt).

Ganon

2008-04-16, 09:51:13

Afaik warnt doch selbst FireFox davor, wenn man gerade dabei ist ein PlugIn ohne Zertifikat zu installieren/starten.

Grestorn

2008-04-16, 09:53:14

Ok, der Kreis ist geschlossen, ich klinge mich aus. Du bringst gegen alle Einwände wieder die alten, bereits angesprochenen und kritisierten Argumente.

Die Signierung ist und bleibt kein Ersatz für den Grundsatz, dass installierte, ausführbare Dateien nicht in den User-Space gehören. Im User-Space dürfen nur vom Anwender selbst erstellte ausführbare Dateien liegen und sonst nichts.

Es gibt auch keinen Grund es anders zu handhaben.

Ganon

2008-04-16, 10:05:30

Ok, der Kreis ist geschlossen, ich klinge mich aus. Du bringst gegen alle Einwände wieder die alten, bereits angesprochenen und kritisierten Argumente.

Was daran liegt das du deine alten, von mir bereits angesprochenen Argumente bringst.

Die Signierung ist und bleibt kein Ersatz für den Grundsatz, dass installierte, ausführbare Dateien nicht in den User-Space gehören. Im User-Space dürfen nur vom Anwender selbst erstellte ausführbare Dateien liegen und sonst nichts.

Mit dem letzten Satz würdest du deiner "Virus-Theorie" aber neuen Nährboden geben. Unsignierte Anwendungen im User-Space.

Es gibt auch keinen Grund es anders zu handhaben.

Sicher sind unsignierte Anwendungen im User-Space keine tolle Idee, nur vertrete ich halt den Standpunkt das eine signierte Anwendung das gerne tun kann.

Grestorn

2008-04-16, 10:17:58

Was daran liegt das du deine alten, von mir bereits angesprochenen Argumente bringst.

Du bist nie auf die Problematik eingegangen, dass nicht alle Applikationen vom Hersteller signiert sein können. Und gegen die Argumentation mit der Auto-Signierung des OS hatte ich genügend Einwände gebracht, die Du m.E. nicht wirklich vom Tisch gebracht hast.

Mit dem letzten Satz würdest du deiner "Virus-Theorie" aber neuen Nährboden geben. Unsignierte Anwendungen im User-Space.Prinzipiell stimmt das, aber ein Entwickler wird nicht darum herum kommen während seiner Arbeit seine Arbeitsergebniss in seinem Bereich abzulegen. Und das Virus-Risiko ist bei selbstgeschriebenen, nicht allgemein bekannten, ständig neu kompilierten Anwendungen auch vergleichsweise gering (wenn auch nicht null).

Sicher sind unsignierte Anwendungen im User-Space keine tolle Idee, nur vertrete ich halt den Standpunkt das eine signierte Anwendung das gerne tun kann.Ich widerspreche gar nicht, wenn Du sagst dass eine signierte Anwendung ausreichend sicher vor Manipulationen ist. (Abgesehen davon, dass sie ganz einfach durch einen ebenfalls signierten Virus ausgetauscht werden kann).

Ich frage mich nur: Wozu der Zinober? Es bringt einfach keinen Zusatzgewinn gegenüber einer konsequenten Nutzung der Zugriffsrechte.

Wenn ein Schadprogramm im Übrigen erst mal aus irgendeinem Grund root Rechte erlangt hat, dann hilft die Signierung natürlich auch nicht mehr, denn dann dürfte der Mechanismus auch ganz ausgehebelt werden können. Also, auch da kein Sicherheitsgewinn ggü. den althergebrachten Lösungen.

MacMark

2008-04-16, 11:52:01

... Zu glauben, dass freiwillig alle Entwickler diese Signierung auf sich nehmen, nur damit der Mac sicherer wird, ist arg utopisch. ...

Selbst Shareware-Programme und kostenlose Programme für OS X sind inzwischen korrekt signiert, beispielsweise Skype und Graphicconverter.
Da war die Realität schneller als die Utopie ;) :P

... Vorallem wenn man bedenkt, wie groß das Geschrei unter Vista war....
Bei Vista signiert Microsoft fremde Programme, sozusagen als Kompatibilitäts-Zertifikat. Bei OS X signieren die Hersteller selbst.

MacMark

2008-04-16, 12:00:34

... Es ist absolut keine gute Idee, ausführbaren Code im User-Space zu haben.

*) MacMark: Wer das Wort "User-Space" wie verwendet, ist nicht festgelegt. Nicht von Dir oder von irgendjemand sonst. Allgemein denke ich ist es naheliegend, den Begriff so zu definieren, dass man damit jegliche Resource meint, auf die der User freien Zugriff hat.
Das ist Deine Privatdefinition. Lies mal ein beliebiges Buch über UNIX ;) da steht es meist ungefähr so:
http://www.linfo.org/user_space.html
Man muß sich schon an allgemein anerkannte Definitionen halten, sonst redet man aneinander vorbei.

Warum Programme im User-Home ein Sicherheitsgewinn im Bezug auf Viren sind, hatte ich oben in #72 ausführlich erläutert:
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=6433024&postcount=72

MacMark

2008-04-16, 12:20:01

... Wenn ein Schadprogramm im Übrigen erst mal aus irgendeinem Grund root Rechte erlangt hat, dann hilft die Signierung natürlich auch nicht mehr, denn dann dürfte der Mechanismus auch ganz ausgehebelt werden können. Also, auch da kein Sicherheitsgewinn ggü. den althergebrachten Lösungen.

Root zu sein nützt Dir gar nichts, denn Du mußt den Private-Key des Programmierers haben, um das Programm zu ändern und eine gültige Signatur nach der Änderung zu haben.

Edit: Ein guter Startpunkt, etwas darüber zu lernen, ist dies:
http://developer.apple.com/documentation/Security/Conceptual/CodeSigningGuide/AboutCS/chapter_2_section_2.html

Grestorn

2008-04-16, 13:02:30

Bei Vista signiert Microsoft fremde Programme, sozusagen als Kompatibilitäts-Zertifikat. Bei OS X signieren die Hersteller selbst.

Nein. Du verwechselst - wie so viele - WHQL mit der Herstellersignierung.

Für eine Herstellersignierung braucht man nur ein Trusted Certificate, und die kriegt man z.B. bei VeriSign. Gegen Geld. Und das wird auch beim Mac nicht anders sein, mit den selben Nachteilen.

Grestorn

2008-04-16, 13:04:29

Root zu sein nützt Dir gar nichts, denn Du mußt den Private-Key des Programmierers haben, um das Programm zu ändern und eine gültige Signatur nach der Änderung zu haben.

Das bezweifle ich. Als Root schalte ich einfach die Zertifikatsprüfung aus, und gut ist.

Ganon

2008-04-16, 13:42:14

Als Root schalte ich einfach die Zertifikatsprüfung aus

Wie?

Coda

2008-04-16, 14:36:00

Gehen tut es mit voller Kontrolle über das System auf jeden Fall.

Ganon

2008-04-16, 14:42:14

Gehen tut es mit voller Kontrolle über das System auf jeden Fall.

Sicher. Aber das würde für dem Nutzer fast einem "rm -rf /" gleichen ;)

Aber root darf unter OS X auch nicht alles, wie auf der Seite von MacMark zu finden ist. Er darf z.B. Kernel-Erweiterungen laden und entladen, nur nicht den für die Sandbox ;)

Grestorn

2008-04-16, 15:06:46

Sicher. Aber das würde für dem Nutzer fast einem "rm -rf /" gleichen ;)

Daran hat der Virus kein Interesse. Er will normalerweise an Daten herankommen oder den Rechner zum Zombie machen.

Ganon

2008-04-16, 15:13:43

Daran hat der Virus kein Interesse. Er will normalerweise an Daten herankommen oder den Rechner zum Zombie machen.

An Daten kommt man auch mit einer normalen Sicherheitslücke und benötigt keine dauerhafte Binär-Manipulation, die dank signiertem Code sowieso nicht geht.

Rechner zum Zombie machen, bzw. Trojanermäßig handeln, benötigte Datenmanipulation. Zerschreddert man aber das System soweit das der Nutzer kaum noch was machen kann, dann bringt der Trojaner/Virus auch nichts. ;)

Denn die Sache mit dem signierten Code ist so tief ins System verankert... weiß nicht wie man das ohne Schäden "abschalten" will. Da die FireWall dann auf "Stur" schaltet, kommen dann auch keine Daten mehr durch. ;)

Grestorn

2008-04-16, 15:17:12

An Daten kommt man auch mit einer normalen Sicherheitslücke und benötigt keine dauerhafte Binär-Manipulation, die dank signiertem Code sowieso nicht geht.

Natürlich... man installiert üblicherweise einen Keylogger.

Rechner zum Zombie machen, bzw. Trojanermäßig handeln, benötigte Datenmanipulation.

Eigentlich reicht ein Programm, dass bei jedem Systemstart automatisch mitgestartet wird, am besten mit root-Rechten, aber auch eingeschränkte Rechte reichen für viele Dinge aus (wie Flood-Angriffe u.ä.).

Ganon

2008-04-16, 15:28:33

Natürlich... man installiert üblicherweise einen Keylogger.
Eigentlich reicht ein Programm, dass bei jedem Systemstart automatisch mitgestartet wird, am besten mit root-Rechten, aber auch eingeschränkte Rechte reichen für viele Dinge aus (wie Flood-Angriffe u.ä.).

Das ist wieder ein anderer Fall. Als normaler Nutzer kriegst du unter OS X keine Systemstart-Dienste eingerichtet, ohne Admin-Rechte (der normale Admin-User von OS X reicht auch nicht, der fragt auch nach Passwort). Und wenn du das als root machst, bringt die von dir genannte "alle ausführbaren Dateien nicht im User-Space" auch nicht allzu viel und hat auch recht wenig damit zu tun. ;)

Die FireWall würde sich dann übrigens auch melden wenn noch ein unbekanntes/nicht signiertes Programm ins Netz will.

SentinelBorg

2008-04-16, 15:56:27

Unter .net gibts den ganzen Signatur-Krams auch schon ewig. Wenn ich will, lädt meine App auch nur DLLs mit einem ganz bestimmten Strong Name, der dann die Signatur mit einschliesst.

MacMark

2008-04-16, 16:56:56

… Als Root schalte ich einfach die Zertifikatsprüfung aus, und gut ist.

Einfach? Cool, dann sag mir konkret, wie Du das auf OS X machst. :tongue:

Gehen tut es mit voller Kontrolle über das System auf jeden Fall.

Auf jeden Fall? Super, Du darfst mir auch konkret sagen, wie Du das auf OS X machst. :cool:

Mit physikalischem Zugriff, anschließendem Boot von anderer Platte und komplettem Kerneltausch auf der Originalplatte - vielleicht, wenn Du gut bist.

Aber: Allein Root zu sein auf dem laufenden System ermöglicht noch lange nicht, alles verändern zu können. Du kannst beispielsweise nicht beliebig Kernel-Erweiterungen entladen - nicht einmal als root. Du kannst auch keine Dateien verändern oder löschen während des Normalbetriebs, die das "system immutable flag" gesetzt haben - nicht einmal als root.

Edit: Ich kann Dir auch eine root shell aufmachen, mit der Du keine einzige Datei schreiben kannst:
Miami:~ macmark$ sudo -s
Password:
bash-3.2# whoami
root
bash-3.2# touch test
bash-3.2# rm test
bash-3.2# sandbox-exec -p "(version 1) (allow default) (deny network*) (deny file-write*) (debug deny)" /bin/bash
bash-3.2# whoami
root
bash-3.2# touch test
touch: test: Operation not permitted

MacMark

2008-04-16, 18:49:14

Zum Ausgangsposting: Microsoft hat das Problem, an dem auch Apples "Copland" gescheitert ist: "Not invented here"-Syndrom. Wenn man alles selbst entwickeln will, hat man sehr viel Arbeit, macht viele Fehler und kommt nur langsam voran.
Bei den Unices wird in der Regel das, was gut ist, auch auf anderen Plattformen übernommen, auch wenn man es nicht selbst erfunden hat. Damit baut man auf bewährtem Code und Konzepten auf und kommt schnell voran.

Matrix316

2008-04-16, 21:57:05

Ganon

2008-04-17, 06:55:53

Allerdings dann bitte mit exe und installer für Software und Treiber. :D

Installer für Software? :ugly: Wie Rückständig :D *scnr*

MacMark

2008-04-17, 07:42:29

... Denn die Sache mit dem signierten Code ist so tief ins System verankert... weiß nicht wie man das ohne Schäden "abschalten" will. Da die FireWall dann auf "Stur" schaltet, kommen dann auch keine Daten mehr durch. ;)

"Die" Firewall gibt es hier nicht, denn OS X 10.5. Leopard hat zwei Firewalls: Die Application-Firewall (sehr praktisch für Programme mit wechselnder Portnutzung), die man per GUI konfiguriert, und die auch früher genutzte ipfw, die komplizierter und für Fortgeschrittene gedacht ist.
Keine von beiden verhindert in der Standardkonfiguration ausgehende Verbindungen.

Edit: Wird die Signatur eines Programms jedoch geändert oder ungültig durch Manipulation am signiertem Programm, dann passen die für das Programm definierten Erlaubnis-Regeln in der Application Firewall nicht mehr. Meintest Du das mit "stur"?

Den Einsatz von solchen Firewalls halte ich allerdings für fragwürdig bei Systemen, die interne Funktionen auch ohne Firewall nicht nach außen anbieten.
http://macmark.de/osx_security.php#firewall

Ganon

2008-04-17, 08:13:45

Edit: Wird die Signatur eines Programms jedoch geändert oder ungültig durch Manipulation am signiertem Programm, dann passen die für das Programm definierten Erlaubnis-Regeln in der Application Firewall nicht mehr. Meintest Du das mit "stur"?

Jop. Sicher muss man sie erst einschalten. Aber hier geht's ja auch nicht um die Standard-Installation von OS X.

Den Einsatz von solchen Firewalls halte ich allerdings für fragwürdig bei Systemen, die interne Funktionen auch ohne Firewall nicht nach außen anbieten.
http://macmark.de/osx_security.php#firewall

Alles hat halt Vor- und Nachteile, ansonsten würde es nicht so viele verschiedene Sachen geben ;)

Es ging mir halt nur um das Beispiel mit den signierten Programmen. Ist das Programm signiert und ein Virus modifiziert es, würde spätestens die FireWall sagen, dass da was nicht stimmt.

ste^2

2008-04-17, 10:23:35

Auf ArsTechnica gibt es gerade einen Artikel passend zum Thema: Keeping your Mac locked down: a Mac OS X security primer (http://arstechnica.com/guides/tweaks/mac-os-x-security.ars)

@Mod:
Threadsplit?

Coda

2008-04-17, 12:59:14

Auf jeden Fall? Super, Du darfst mir auch konkret sagen, wie Du das auf OS X machst. :cool:

Mit physikalischem Zugriff, anschließendem Boot von anderer Platte und komplettem Kerneltausch auf der Originalplatte - vielleicht, wenn Du gut bist.
Jo, irgendwie geht's halt. Ich find's aber krank, dass man das so tief ins System gegraben hat.

Wenn das Microsoft bei Windows machen würde würde der Weltuntergang prophezeit werden.

Ganon

2008-04-17, 13:24:39

Jo, irgendwie geht's halt. Ich find's aber krank, dass man das so tief ins System gegraben hat.

Wenn man es halt nicht effektiv einbaut, kann man es auch gleich ganz lassen. Ist ja z.B. wie mit der Sandbox. Wenn der Dienst in einer Sandbox läuft und man erlangt durch eine Sicherheitslücke im Dienst root-Zugriff, dann bringt die Sandbox ja auch nichts wenn man dadurch einfach die Sandbox abschalten kann. ;)

Wenn das Microsoft bei Windows machen würde würde der Weltuntergang prophezeit werden.

Wie man es macht ist das Problem. M$ kam halt gleich damit an das nur signierte Treiber laufen und die Signierung darf auch nur M$ vornehmen. So macht man sich halt recht wenig Freunde.

Apple bittet nur die Entwickler ihre Software selbst zu signieren, verlangt es aber nicht.

Grestorn

2008-04-17, 13:40:28

M$ kam halt gleich damit an das nur signierte Treiber laufen und die Signierung darf auch nur M$ vornehmen.

Nein Herrgott. Wie oft muss ich das in diesem einen Thread noch korrigieren bis Du es nicht mehr wiederholst?!

Die Treibesignierung (Hersteller!) ist nicht das selbe wie WHQL (MS). Und nur erstere wird von Vista64 verlangt. Letztere ist optional.

Ganon

2008-04-17, 14:04:37

Nein Herrgott. Wie oft muss ich das in diesem einen Thread noch korrigieren bis Du es nicht mehr wiederholst?!

Wie oft habe ich es denn wiederholt? Ich habe das in diesem Thread bisher noch nicht gesagt...

Die Treibesignierung (Hersteller!) ist nicht das selbe wie WHQL (MS). Und nur erstere wird von Vista64 verlangt.

Dann bleibt halt nur das "verlangen" danach.

Grestorn

2008-04-17, 14:35:33

Wie oft habe ich es denn wiederholt? Ich habe das in diesem Thread bisher noch nicht gesagt...
Hier habe ich es schon mal geschrieben:

http://www.forum-3dcenter.org/vbulletin/showthread.php?p=6434611#post6434611

Und Du hast es eben wiederholt, nachdem MacMark es schon mal falsch schrieb und ich ihn korrigierte.

Dann bleibt halt nur das "verlangen" danach.Bei Treibern sehe ich da - im Gegensatz zu Software generell - ehrlich gesagt auch kein Problem. Wenn ein Treiberhersteller nicht bereit ist, seinen Treiber zu signieren, dann kommt der auch nicht auf mein System. Und MS hat da genau den richtigen Schritt getan.

Ganon

2008-04-17, 15:03:33

Hier habe ich es schon mal geschrieben:
http://www.forum-3dcenter.org/vbulletin/showthread.php?p=6434611#post6434611
Und Du hast es eben wiederholt, nachdem MacMark es schon mal falsch schrieb und ich ihn korrigierte.

"...Wie oft in DIESEM..." und "...DU nicht mehr...", klingt aber anders.

Bei Treibern sehe ich da - im Gegensatz zu Software generell - ehrlich gesagt auch kein Problem. Wenn ein Treiberhersteller nicht bereit ist, seinen Treiber zu signieren, dann kommt der auch nicht auf mein System. Und MS hat da genau den richtigen Schritt getan.

Und der Unterschied zwischen Treiber und Software ist? Warum wird befürchtet das OpenSource-Software ausgeschlossen wird, aber das OpenSource-Treiber ausgeschlossen werden ist wieder kein Problem?

Naja, wie du möchtest... ;)

Grestorn

2008-04-17, 15:30:39

"...Wie oft in DIESEM..." und "...DU nicht mehr...", klingt aber anders.Das war in diesem Thread. Und Du hast es wiederholt (auch wenn Du es beim ersten Mal nicht warst, aber wiederholt hast Du's trotzdem).

Und der Unterschied zwischen Treiber und Software ist? Warum wird befürchtet das OpenSource-Software ausgeschlossen wird, aber das OpenSource-Treiber ausgeschlossen werden ist wieder kein Problem?

OS-Treiber sind ein Problem, aber ein kleines. Da Treiber normalerweise zu Hardware gehört und demnach per Definition ein Hersteller dahinter steht, der auch kein Problem damit hat, die $300 für das Trusted Certificate auszugeben.

Bei beliebiger Software sieht das schon anders aus.

Aber zugegeben: Es gibt auch Freeware die "Treiber" verwendet, z.B. RivaTuner. Aber das sind wirklich seltene Ausnahmen und für die findet sich auch eine Lösung.

Das aber für jegliche SW zu fordern geht weit weit darüber hinaus, was MS mit den Treibern fordert. In einem geschlossenen, abgesicherten System (aka TCPA) ist sowas natürlich völlig unvermeidbar, aber nicht in einem offenen System.

Coda

2008-04-17, 15:33:55

Ich hoffe eh immer noch drauf dass die Zertifikate endlich billiger werden. Das ist ein Unding dass man für die Speicherung von Kundendaten und einer Ausführung von einem Script das vielleicht 2s läuft $300 pro Jahr verlangt.

Verisign hat damit praktisch eine Gelddruckmaschine und hat wahrscheinlich nichtmal 10 Server rumstehen für alle Kunden. Gut sie müssen noch die Personen bezahlen die die Validieriung des Antragstellers machen.

Grestorn

2008-04-17, 15:35:27

Ich hoffe eh immer noch drauf dass die Zertifikate endlich billiger werden. Das ist ein Unding dass man für die Speicherung von Kundendaten und einer Ausführung von einem Script das vielleicht 2s läuft $300 pro Jahr verlangt.

Verisign hat damit praktisch eine Gelddruckmaschine und hat wahrscheinlich nichtmal 10 Server rumstehen für alle Kunden.

Zustimmung. Wobei natürlich die Identität des Zertifikatinhabers zweifelsfrei nachgewiesen werden muss. Also ein gewisser Aufwand ist vorhanden, aber $300 ist definitiv zu viel.

Coda

2008-04-17, 15:42:32

Imho sollten es maximal 50$ sein.

Bei Web noch weniger. Die Validierung von Domain-Zertifikaten wird ja über eine automatische Mail an ssladmin@domain gemacht. Personalaufwand = 0. Ich ärger mich jedes Mal wieder über die Preise wenn ich eins beantragen muss.

MacMark

2008-04-17, 16:56:38

Nein. Du verwechselst - wie so viele - WHQL mit der Herstellersignierung. …
Ich verwechsele das nicht, sondern stelle es absichtlich einander gegenüber, denn bei OS X gibt es keine Signierung, die nur als Kompatibilitätsstempel dient. Daher das "Geschrei bei Vista" und die Ruhe bei OS X-Programmierern.

MacMark

2008-04-17, 17:05:30

Auf ArsTechnica … Keeping your Mac locked down: a Mac OS X security primer (http://arstechnica.com/guides/tweaks/mac-os-x-security.ars)…

… Versions of Mac OS X prior to v10.5 used the open-source ipfw firewall package as the underlying system firewall. In the current version, this has changed to a proprietary application-level firewall …

Die ipfw ist nicht gegen die Application Firewall ausgetauscht worden. Es sind beide verfügbar und nutzbar. (John Siracusa schreibt bessere Artikel.)

Grestorn

2008-04-17, 17:26:24

Ich verwechsele das nicht, sondern stelle es absichtlich einander gegenüber, denn bei OS X gibt es keine Signierung, die nur als Kompatibilitätsstempel dient. Daher das "Geschrei bei Vista" und die Ruhe bei OS X-Programmierern.

Du hast es immer noch nicht verstanden. Die WHQL Zertifizierung, die MS durchführt und die auch recht teuer ist, ist auch unter Vista64 für Treiber nicht verbindlich (nur eine Warnmeldung).

Das einzig verbindliche ist die Herstellersignatur für Treiber unter Vista64. Das ist nichts anderes als was bei OSX gefordert wird, nur auf Treiber beschränkt,

MacMark

2008-04-17, 19:56:18

… Die WHQL Zertifizierung, die MS durchführt und die auch recht teuer ist, ist auch unter Vista64 für Treiber nicht verbindlich (nur eine Warnmeldung).

Mir geht es nicht um WHQL oder Nicht-WHQL. Tatsache ist, daß unter Vista in einigen Fällen unsignierte Software nicht läuft:
Kernel-mode software must be digitally signed to be loaded on x64-based versions of Windows Vista
http://www.microsoft.com/whdc/winlogo/drvsign/kmcs_walkthrough.mspx

Das einzig verbindliche ist die Herstellersignatur für Treiber unter Vista64. Das ist nichts anderes als was bei OSX gefordert wird, nur auf Treiber beschränkt,
Nein, es ist etwas anderes, weil OS X keine Software vom Laufen abhält, wenn sie keine Signatur hat.

Und nein, Vista hält nicht nur unsignierte Kernel-Treiber vom Laufen ab, sondern auch normale unsignierte heruntergeladene Programme:
Installation packages and self-extracting executables downloaded through Internet Explorer must be digitally signed in order to run or install.
http://www.microsoft.com/whdc/winlogo/drvsign/drvsign.mspx

Darum heulen die OS X-Programmierer nicht so wie die Vista-Programmierer.

Grestorn

2008-04-17, 20:08:24

Mir geht es nicht um WHQL oder Nicht-WHQL. Tatsache ist, daß unter Vista in einigen Fällen unsignierte Software nicht läuft:

http://www.microsoft.com/whdc/winlogo/drvsign/kmcs_walkthrough.mspx

Nein, es ist etwas anderes, weil OS X keine Software vom Laufen abhält, wenn sie keine Signatur hat.

Und nein, Vista hält nicht nur unsignierte Kernel-Treiber vom Laufen ab, sondern auch normale unsignierte heruntergeladene Programme:

http://www.microsoft.com/whdc/winlogo/drvsign/drvsign.mspx

Darum heulen die OS X-Programmierer nicht so wie die Vista-Programmierer.Es ist eine reine Herstellersignatur die Vista64 für Treiber anfordert, nicht mehr und nicht weniger (schau mal was der von Dir verlinkte Artikel für eine Überschrift trägt!).

Ein 5. Mal schreib ich das jetzt nicht mehr, wenn Du es mir nicht glaubst dann kann ich Dir auch nicht helfen. Ich behaupte ja auch nicht irgendwelche Dinge über OSX, da ich mich damit nicht auskenne. Du solltest dies auch beherzigen.

Coda

2008-04-17, 20:29:06

Und nein, Vista hält nicht nur unsignierte Kernel-Treiber vom Laufen ab, sondern auch normale unsignierte heruntergeladene Programme:
Tut es nicht.

"Kernel-Mode Software" sind Treiber. Was Grestorn schreibt ist genau so richtig.

Digitale Signatur ist nur bei Vista 64 für Treiber verpflichtend. WHQL ist generell optional, wenn kein WHQL dann kommt ne Warnmeldung.

MacMark

2008-04-17, 20:39:27

Tut es nicht.…
Doch: Vista hält auch normale Programme ohne Signatur vom Laufen ab, sagt Microsoft:
Installation packages and self-extracting executables downloaded through Internet Explorer must be digitally signed in order to run or install.
http://www.microsoft.com/whdc/winlogo/drvsign/drvsign.mspx

Es ist eine reine Herstellersignatur die Vista64 für Treiber anfordert…
Was für eine Signatur das ist, ist mir egal, denn ich sagte lediglich, daß eine Signatur Pflicht ist, um Laufen zu können.

Coda

2008-04-17, 20:47:30

Doch: Vista hält auch normale Programme ohne Signatur vom Laufen ab, sagt Microsoft:

http://www.microsoft.com/whdc/winlogo/drvsign/drvsign.mspx
Damit sind TREIBERinstallationen gemeint. Gott verdammt lies doch mal die Überschrift und um was es in dem Artikel geht.

Für die ganz blöden fett markiert:
Driver Signing Requirements for Windows

Das einzige was du bekommst unter Vista wenn du einen unsignierten Installer für ein User-Space-Programm runterlädst ist eine Warnung. Und ja, das weiß ich ganz sicher, weil ich das momentan in Vista schreibe.

Ganon

2008-04-18, 08:14:33

Das aber für jegliche SW zu fordern geht weit weit darüber hinaus, was MS mit den Treibern fordert.
...
Das ist nichts anderes als was bei OSX gefordert wird, nur auf Treiber beschränkt,

Fordert Apple doch gar nicht, wie oft noch?

Grestorn

2008-04-18, 08:20:17

Fordert Apple doch gar nicht, wie oft noch?

Du hast mich missverstanden: Ich weiß dass Apple das nicht fordert. Es wurde hier in diesem Thread gefordert (als Voraussetzung damit die Signierung als universeller Schutz gegen Viren und als Ersatz für ein Rechtesystem einen Sinn macht), nicht von Apple!

Ich habs unglücklich formuliert, zugegeben...

MacMark

2008-04-18, 16:28:47

Damit sind TREIBERinstallationen gemeint. … .
Und? "Installation packages and self-extracting executables", sprich install.exe und setup.exe und so weiter sind ganz normale Programme, auch wenn sie Treiber installieren.

MacMark

2008-04-18, 16:35:32

… damit die Signierung als universeller Schutz gegen Viren und als Ersatz für ein Rechtesystem einen Sinn macht ergibt/hat …

Signierte Programm-Dateien ermöglichen, daß man unauthorisierte Änderungen an ihnen, beispielsweise durch einen Virus, bemerkt, wenn man die Signatur prüft.
Als Ersatz für UNIX-Dateirechte sind signierte Programme nicht gedacht.

Coda

2008-04-18, 17:19:11

Und? "Installation packages and self-extracting executables", sprich install.exe und setup.exe und so weiter sind ganz normale Programme, auch wenn sie Treiber installieren.
Nein. Es kommt nur eine Warnung. Auch mit Vista x64. Ganz sicher.

Da kannst du dich drehen und wenden wie du willst, das ist schlicht und einfach die Realität.

http://www.mental-asylum.de/files2/setup.png

Und ja, es ist auch völlig egal wie die Datei heißt. Und ja ich hab das Ding mit IE runtergeladen.

Schnuller4u

2008-04-21, 10:46:52

Microsoft has never done anything so bold as Apple's OS X transition. It developed a new, modern OS, but did so in the early 1990s: Windows NT. And although Windows NT ticked the right boxes at the time—protected memory, preemptive multitasking, multiprocessor, written in platform-independent C—in places it was never even close to modern. Its APIs were based on the Win16 API from 16-bit Windows. This was a deliberate decision, as it made it easier to migrate 16-bit apps to the new 32-bit platform, and at the time it probably made sense. But it means that nowadays the 64-bit API (Win64) still reflects decisions made 20 years ago. As mentioned in my Vista article, the graphics stack in NT is today pretty archaic (to be fair, it was never cutting-edge, but what was a sensible compromise 20 years ago is now just plain obsolete).

What makes this all worse is that Win16 was never well-designed in the first place, and Win32 has replicated poor decisions in abundance. Win32 is a big API; it's really huge, many thousands of API calls, and it's totally inconsistent. It's inconsistent in every way imaginable.

For example, many of the functions in Win32 require the caller to give a buffer to the function to store some data, and often that buffer has a size that's dynamic. Typically, the API can figure out how big the buffer needs to be, but the caller can't. A sensible software developer strives to solve the same problem the same way each time. It makes things easier for everyone concerned; it's easier for the software developer (because he only has to design one approach to doing it), and it's easier for people using his code (because they only have to learn one approach to doing it). There's no good reason to do it different ways. Yet Win32... Win32 does it in different ways.

Sometimes you can pass in an empty buffer and the function will tell you how big a buffer it needs.

Sometimes you have to pass in a small—but not empty—buffer and the function will tell you how big a buffer it needs.

Sometimes the function allocates a buffer from one of the standard Win32 memory allocators all on its own.

Sometimes the function allocates a buffer from a custom API-specific memory allocators all on its own.

Now, there might be some consistency in different portions of the API—the set of functions for dealing with backup/restore operations might all work in the same way, the set of functions for dealing with the registry might all be consistent, and so on. But while that might make sense to the people developing the OS, all in their own little teams, it's of no comfort to people like me who want to write Windows software.

I can't just use the registry API or the file API or DirectShow in isolation; I want to write a useful application. That means I have to deal with all of those things together. This makes the inconsistencies really jarring. I have to deal with them up close and personal. And it's frustrating and annoying. It makes things harder than they ought to be. With a well-designed library, you can learn one part of the library and apply that knowledge to other parts of the library. Because they work the same way. They're consistent. They reuse concepts in different places. Win32 isn't like that. Every little bit has got to be learned from scratch, because it's a schizophrenic mess.

This has been part one of a three-part series. Next time I'll take a look at how Microsoft squandered a gilt-edged chance to give Windows an API fit for the 21st century, and the missed opportunities that Vista represents. In part three, I'll examine just what went wrong in Redmond and how things got the way they are, and then take a look at what Microsoft could do to restore the "wow" that it once had.

http://arstechnica.com/articles/culture/what-microsoft-could-learn-from-apple.ars/3

(Fullquote, da die Seite derzeit so langsam ist).

Kompletter Artikel: http://arstechnica.com/articles/culture/what-microsoft-could-learn-from-apple.ars/1

Diarrhorus

2008-04-21, 13:10:40

Das die WinAPI ein riesiges Chaos ist, ist kein Geheimnis. Aber Microsoft hat da gar keine Wahl. Wenn die die bereinigen wollen, dann müssten die komplett die Rückwärtskompatibilität aufgeben.

Außerdem programmiert heute doch eh kaum noch einer direkt mit der WinAPI, genau so wenig wie jemand unter Unixsystemen seine grafischen Applikationen noch direkt mit der XLib schreibt.

Coda

2008-04-21, 13:49:25

Die WinAPI wird doch im Moment durch .NET abgelöst. Das kann man wunderbar mit allen verfügbaren Programmiersprachen verwenden und hat eine sehr sauberer Architektur wie Cocoa auch. Das ist für den Programmierer sogar noch angenehmer, weil er kein Speichermanagement mehr machen muss (ab Leopard gibt es offenbar auch einen Obj-C garbage collector).

Auf dem Macintosh gibt's da auch noch Carbon dass noch im wesentlichen die Mac-OS-9-API ist. Und das ist mindestens genauso schlimm. Für manche Dinge muss man das sogar noch verwenden, weil es keinen Cocoa-Wrapper gibt wenn ich richtig informiert bin.

Verstehe den Rant also nicht ganz.

Exxtreme

2008-04-21, 14:09:52

Microsoft schleppt das aus Kompatibilitätsgründen halt mit. Stören sollte es aber normalerweise nicht. Für ganz neue Dinge gibt es .NET oder man kann auch Java nehmen. So what? Eine Wahl hat man normalerweise immer.

Ganon

2008-04-21, 14:25:45

Das ist für den Programmierer sogar noch angenehmer, weil er kein Speichermanagement mehr machen muss (ab Leopard gibt es offenbar auch einen Obj-C garbage collector).

Davor war es semi-auto über manuelles Reference-Counting. Ab Leopard gibt es einen Garbage-Collector, ja.

Auf dem Macintosh gibt's da auch noch Carbon dass noch im wesentlichen die Mac-OS-9-API ist. Und das ist mindestens genauso schlimm.

Das betrifft hauptsächlich die tote HIToolBox, was quasi der "GUI"-Teil von Carbon ist. Die ist recht eklig und WinAPI ähnlich, ja.

Für manche Dinge muss man das sogar noch verwenden, weil es keinen Cocoa-Wrapper gibt wenn ich richtig informiert bin.

Dies wiederum sind dann normale C-Routinen aus der CoreFoundation (bestandteil von Carbon). Mit normale C-Routinen meine ich das es alles noch vernünftig lesbar ist und nicht mit total krüppligen Datentyp-Bezeichnungen/Konstanten arbeitet. Apple scheut da keine langen Variablen und Funktionsnamen.