Comments on: Defragmentierung, Macs & Mac OS X | Mac-Tipps von MacMark

By: MacMark

MacMark — Mon, 17 May 2010 18:49:02 +0000

Lieber xyz,

und wieder verleitet Dich Dein Unwissen zu falschen Schlußfolgerungen. Du hast wieder nicht vollständig und richtig gelesen, was ich geschrieben habe. In diesem Fall auf http://www.macmark.de/osx_dynamic-overriding.php.

Der erste Teil des Artikels, den ich seit 2005 pflege, beschreibt die Situation vor dem Intel-Switch, also alles vor 10.4.4. Ich gehe weiter unten auch auf 10.3.0 ein. Das ist Dir völlig entgangen.

Dynamic Overriding stellte in keiner Version von OS X ein Architektur- oder Sicherheits-Problem dar, denn task_for_pid() hat immer die UNIX-Usergrenzen beachtet: Man konnte task_for_pid() immer nur auf eigene Prozesse verwenden, es sei denn man ist root. Das ist Dir vollkommen unbekannt.

Die erste Intel-Version von OS X schränkte das noch weiter ein. Die PowerPC-Version erst mit 10.5.0, als sie wieder codegleich wurde mit der Intel-Version. Auch das hast Du nicht korrekt hingekriegt. Jede weitere Version von OS X nahm weitere Einschränkungen und Code-Aufräumarbeiten vor.

All das ist pro Version detailliert beschrieben worden von mir. Ist Dir entgangen.

Signierter Code aus selektiven Quellen ist nur eine zusätzliche Bedingung, wenn Du meinen Artikel mal richtig lesen würdest. Details siehe dort. Hast Du weder gewußt noch verstanden.

Wenn Du mal gründlich lesen würdest, dann hättest Du Dir ein paar fehlerhafte Postings sparen können. Versteckst Du Dich deshalb anonym hinter “xyz”?

Grüße von
MacMark

By: xyz

xyz — Mon, 17 May 2010 11:37:26 +0000

Und noch ein Komentar zu “Dein Wissen über task_for_pid() ist mangelhaft. Nachhilfe gibt es hier: http://www.macmark.de/osx_dynamic-overriding.php”

Was Du dabei (mit Absicht?) unterschlägst, ist die Tatsache, dass alle Deine Ausführungen nur für neuere Mac OS X-Versionen gelten. Erst in Mac OS X 10.4.4 wurde die mach_inject-Schwachstelle abgedichtet, indem Securitychecks eingeführt wurden. In früheren Versionen war das nicht drin:
“Important restriction: In 10.4.4 (intel build), Apple removed the ability to send low-level mach commands from one task to another.”
http://guiheneuf.org/mach%20inject%20for%20intel.html

“mach_inject is a very clever piece of hack that allows an application to inject and execute code in another running process. The PowerPC version works with standard user privilege whereas the intel version requires more privileges to work.”
http://0xced.blogspot.com/2006/06/machinject-procmod-group-and-security.html
Aber bestimmt ist das Deiner Meinung nach auch kein grundlegender Designfehler, den Mac OS X da gehabt hat, oder?

Vielleicht wäre es für Dich an der Zeit, Deine Aussagen mal selbst zu hinterfragen. Das arrogante Verhalten anderen gegenüber ist da nicht wirklich angebracht. Wie war das noch gleich mit der Samba-Lücke, die bei Mac OS X ja nicht greifen würde? Uups, bei 10.6 doch: “Anscheinend verhält sich 10.6 etwas anders und hat eventuell hier noch einen Fehler.” Das nenne ich mal eine windelweiche Aussage. Aber Hauptsache schnell die Beruhigungspille einschieben und das Problem, welches nicht mehr abgestritten werden kann, verharmlosen: “Nicht tragisch, da dieser Benutzer nicht viel machen kann, aber dennoch unschön.”

By: xyz

xyz — Mon, 17 May 2010 09:18:05 +0000

Ja, ja, andere belehren aber wenn es hart auf hart kommt, kneifen. Wie wäre es mal, wenn Du inhaltlich auf die Argumente eingehen würdest? Stattdessen kommen Abwiegelung (ist ja nicht so schlimm), Verharmlosung (nur ein einfacher Bug) und persönliche Angriffe. Da kann sich ja jeder selbst ein Bild machen. Wird Dir das nicht irgendwann mal peinlich?

By: MacMark

MacMark — Sun, 16 May 2010 15:57:24 +0000

Dein Wissen über task_for_pid() ist mangelhaft. Nachhilfe gibt es hier:
http://www.macmark.de/osx_dynamic-overriding.php

Daniel Melanchthon, von Microsoft angestellt als sogenannter “Evangelist”, hat in dem “Widerlegungs-Kommentar” seines “Windows 7 Blog von Microsoft Deutschland” seine Eignung als Microsoft-”Evangelist” unter Beweis gestellt, aber nicht mit technischem Know-how geglänzt. Er hat, ganz offen gesprochen, nicht den leisesten Schimmer von OS X und weiß auch vieles über Windows nicht. Ich habe die Details dazu dort in ein paar Kommentaren angemerkt.

Zum Rest Deines Postings kann ich mir erneute Kommentare schenken.

By: xyz

xyz — Sun, 16 May 2010 08:48:04 +0000

“bei normalen Schreibzugriffen ist nur eine einzelne Datei in Gefahr, beim Defragmentieren die ganze Platte.”
Aha. Ist natürlich ein Problem der Software, richtig? Ein System-Architekturfehler kann es ja nicht sein, weil Max OS X per deiner Definition keine Architekturfehler hat. Oder haben darf. Hurra! Nur das auf anderen Systemen sowas nicht so kritische Auswirkungen hat.
“Windows auf NTFS ist deutlich anfälliger für Fragmentierung als OS X auf HFS+…. Daher kennen Windows-User dieses Problem aus ihrem Alltag und fragen sich beim Switch zum Mac, ob sie das gleiche auch bei OS X vorfinden.”
Die Defragmentierung unter Windows ist maßlos überschätzt. Seit Vista kümmert sich das OS im Hintergrund automatisch darum. Was hier eigentlich viel mehr eine Rolle spielt, ist die Tatsache, dass unbedarften Anwendern schon seit Jahren Schlangenöl verkauft wird. Es wird ein Geschäft gemacht mit Tuningsoftware und C0. Nur weil diese Software existiert, heißt das nicht, dass sie ein wirkliches Problem lösen. Es gibt diese Software vor allem, weil man damit Gewinn machen kann. Viele Tests haben gezeigt, dass derartige Software eher Schaden anrichtet, als Gutes tut. Trotzdem ist sie nicht auszurotten. Wenn Mac OS X genauso populär wäre wie Windows würdest Du auch 1000 und 1 Trick lesen können, den Apple den Anwendern verschweigt und hunderte Tuningtools kaufen können, die das richtig machen, was Apple ab Werk falsch macht (so jedenfalls die Behauptung derartiger Software). Du empfiehlst selbst, Anwender sollten möglichst die Finger vom System lassen, also keine Programme installieren, die das System “verbessern”. Das gilt genauso für Windows. Deine Gebashe an Windows ist da völlig fehl am Platz.
Ob Defragmentierung wirklich auf einem Mac nichts bringt, sein mal dahin gestellt. Das wird von EXT2/EXT3 auch immer wieder behauptet, obwohl es falsch ist. Hat die c’t ja sehr schön gezeigt: http://www.heise.de/open/artikel/Fragmentierung-224380.html Mich würde es nicht überraschen, wenn für HFS+ gleiches gelten würde, weil die Optimierungsstrategien ja sehr ähnlich sind.
Was Du weiterhin nicht bedenkst: Die automatische Optimierung, die beim Zugriff auf eine Datei da durchgeführt werden, kosten auf jeden Fall Performance, weil die IO-Operationen ja zusätzlich durchgeführt werden. Kennt Mac OS X überhaupt so etwas wie Low Priority IO? Ich denke nicht. Mir ist ein performantes OS lieber, das im Hintergrund optimiert, wenn der Benutzer das System nicht belastet, als eins, das genau dann optimiert, wenn der Anwender auf die Datei zugreifen will. Auch das halte ich für einen Architekturfehler. Aber Du erklärst mir bestimmt, dass das alles ganz toll so ist, wie es ist und die Performance überschätzt wird.
Zu Pwn2Own: Mac OS X wurde als erstes gehackt. Deine Argumentation ist da Haarspalterei. Die kannst Du genauso auf alle anderen OSse übernehmen. Am Ende zählt, was dabei rauskommt und OS X hat sich als sehr leicht zu überwinden gezeigt. Du verteidigst Apple auch noch dafür, dass sie mehrmals als defekt bekannte Systembibliotheken in ihren Betriebssystemen übernommen und nicht auf dem aktuellen Stand gehalten haben. Das Gegenteil ist richtig: Apple hat keinen vernünftigen formalen Sicherheitsprozess über seine Systeme integriert. Da wäre das sonst aufgefallen. Da sie das nicht tun, ist es nicht verwunderlich ,dass bekannte und in der Quelle gefixte Sicherheitslücken bei Mac OS X lange ungepatched bleiben. Das ist kein Einzelfall und Apple bekleckert sich hier nicht nur nicht mit Ruhm, sondern setzt seine anwender grob fahrlässig unnötigen Risiken aus. Das ist nicht akzeptabel und auf keinen Fall so schönzureden, wie Du das machst.
Das es Dir nicht passt, wenn ein Sicherheitsexperte sich auf Mac OS X eingeschossen hat, passt zu dem Bild, das Du abgibst. Mac OS X ist ja fehlerfrei und heilig – die Bösen sind die, die das kritisieren oder sogar wagen, den Beweis immer und immer wieder zu erbringen, wie schwach das System eigentlich ist. Jammer weiter – Windows und Linux wird von viel mehr Experten permanent versucht zu überwinden. Sei nur froh, dass sowenige sich bisher mit Mac OS X Security beschäftigen. Die Ergebnisse sind schon beschämend genug. Für wieviele kritische Sicherheitslücken ist Safari verantwortlich?
Dein Kommentar zu ASLR und DEP zeigt auch, wieweit Dein Wissen langt. Beides sind Techniken, die Angriffe erschweren (nicht für immer verhindern). Sie machen es viel schwerer, Buffer Overflows auszunutzen. Nur dass es Wege gibt, sie zu überwinden, heißt nicht, dass sie unnütz sind. Sie verkleinern die Menge an ausnutzbaren Buffer Overflows signifikant und machen das Ausnutzen um Längen schwerer. Das ist der Wert dieser Technologien. Apple hat das natürlich auch erkannt und hat in der Weiterentwicklung von Mac OS X ASLR und DEP mit eingebaut. Kein Grund, das schlecht zu reden, wie Du es tust.
Zum Code Signing: Microsoft ist einer der Vorreiter bei Code Signing. Code-Signing bei Windows bezieht sich eben nicht hauptsächlich auf Kompatibilitätsaspekte. Mich würde auch mal interessieren, was Du damit eigentlich meinst. Warum sollte Code signiert werden, damit er kompatibler ist? Von Microsoft ist so ziemlich alles signiert, was mit dem System ausgeliefert wird. Sehr viele Drittanbieter signieren ihre Software, nicht nur die Treiber. Seit 64-bit Windows Vista kann man nur noch signierte Kernel Module laden. Das übersiehst Du alles. Bei OS X ist das auch (noch) nicht flächendeckend inklusive Drittherstellern umgesetzt. Du kannst auf Mac OS X genauso unsignierten Code (noch) ausführen.
Naja, später in Deinem Post wirfst Du noch mehr Dinge zusammen, um Äpfel mit Birnen zu vergleichen und schießt Dich wieder mal auf UAC ein. Nur vergißt Du, dass ein UAC-protected Admin eben kein Benutzer ist, sondern ein Admin. Nimm ein normales Benutzerkonto und Du hast genau die Absicherung, die Du Windows absprichst. Gegenbeispiel bei Apple gefällig? Nimm mal task_for_pid(), damit kann man Code injizierren via mach_inject. Bis Mac OS X 10.4 konnte man das als Benutzer – das ist zum Beispiel auch eine architekturelle Schwachstelle, die erst in neueren Mac OS X Versionen behoben wurde. Witzigerweise aber nur für unsignierten Code – signierter Code darf das weiterhin. Das ist genauso eine Schwachstelle, wie bei UAC, weil hier davon ausgegangen wird, dass Code sich an Regeln hält. Und dass der Signaturschutz von Apple ausgehebelt wird, zeigt sich ja jedes mal, wenn das iPhone OS wieder gerootet wird.
Und Dein beharren auf “Admins auf OS X haben keine Systemrechte. Das hat nur root oder die Gruppe wheel.” – die Menge an Local Root Exploits, die es für Mac OS X gegeben hat und geben wird, zeigt, dass diese Unterscheidung marginal ist. Wenn der Bösewicht auf der Kiste ist (was dank Safari ja recht einfach ist), dann kann er sich die Rechte erhöhen und mit den dann erworbenen Rechten sich Zugriff verschaffen. Du hast solche Scheuklappen auf bei Deinen Lobliedern auf Mac OS X.
Und zu dem Blog: Du hast es ja vorgezogen, auf seine Argumente nicht einzugehen, sondern lieber mit Logik zu argumentieren. Was nur besonders peinlich ist, weil das Argument von Dir falsch ist (Apache hat schon seit längerer Zeit mehr Sicherheitslücken als IIS) und Dein rotes Auto Beispiel ist auch falsch: Dein Kritikpunkt war eine Pauschalaussage “viel Marktanteil, darum viele Angriffe”. Das ist keine Pauschalaussage. Du machst eine daraus, indem Du behauptest: “Nur viel Marktanteil bedeutet viele Angriffe” und das Gegenteil beweist. Nur folgt niemand Deiner Behauptung. Das “nur” ist falsch und deshalb hilft Dir Aussagenlogik nicht weiter.
Dass die Diskussion mit Dir abgelehnt wird, kann ich völlig verstehen. Der Autor der Seite hat doch jede Menge Deiner Argumente widerlegt. Punkt für Punkt. Anstatt dass Du darauf eingehst und Dich entweder verteidigst, oder die Fehler in Deiner Argumentation zugibst und Deine Seite korrigierst, weichst Du der Diskussion aus und kommst mit einem “rote Auto” Beispiel. Es ist kindisch, wenn Du dann hinterher hier klagst, dass ja niemand mit Dir diskutieren will. Du biegst Dir die Fakten so zurecht, dass sie zu Deiner Argumentation passen. Wieviel von dem Schlechtmachen von Windows, das Du betreibst, geht gegen Versionen älter als 10 Jahre? Was wäre, wenn jemand Mac OS 9 mit Windows 7 vergleichen würde und daraus den Schluss zieht, dass Apples Technologie schlechter ist? Da würdest Du doch auch vehement protestieren.
Also entweder machst Du Deine Aufgabe richtig und vergleichst die produkte fair oder Du lässt es. Dann ist jedem klar, dass das nur eine kleine Fanboyseite ist. Es muss Dir doch zu denken geben, dass Du in der Diskussion nicht ernst genommen wirst.
BTW: Dein Rumhacken auf der SMBReplay-Attacke geht auch ins Leere. Warum wohl gibt es SMB Signing? Damit ist die Replay-Attack nämlich nicht möglich. Auch dieses Beispiel einer konzepionellen Schwachstelle von Windows ist nicht wirklich tragfähig.

By: MacMark

MacMark — Sat, 15 May 2010 17:16:15 +0000

Mmh, ein anonymer Kommentar. Nun gut.

Lieber “xyz”,

bei normalen Schreibzugriffen ist nur eine einzelne Datei in Gefahr, beim Defragmentieren die ganze Platte. Das sieht auch Amit Singh so. Wenn Du meinen verlinkten Artikel gelesen hättest oder Amits Artikel, wüßtest Du das auch ;-)

Windows auf NTFS ist deutlich anfälliger für Fragmentierung als OS X auf HFS+. Ältere Versionen auf FAT waren noch anfälliger. Daher kennen Windows-User dieses Problem aus ihrem Alltag und fragen sich beim Switch zum Mac, ob sie das gleiche auch bei OS X vorfinden.

Macs wurde nicht am “schnellsten” gehackt bei den Pwn2Own-Wettbewerben. Die Reihenfolge, in der die Leute ihre lange vorbereiteten Hacks vorführen, wird gelost. Niemand weiß genau, wie lange die Vorbereitung jeweils war. Daher kann von “am schnellsten” gar nicht gesprochen werden. Siehe auch die Details dazu hier:
http://www.macmark.de/blog/osx_blog_2010-03.php#pwn2own_osx_2010_news_review
http://www.macmark.de/blog/osx_blog_2010-03.php#pwn2own_prediction
http://www.macmark.de/blog/osx_blog_2009-03.php#macbook_not_hacked_in_two_minutes_again
http://www.macmark.de/blog/osx_blog_2008-12.php#macbook_not_hacked_in_two_minutes

Die Einschätzung von Charlie Miller und Dino Dai Zovi “Mac hacken macht Spaß, Windows ist harte Arbeit” ist natürlich sehr subjektiv, weil beide erfahren Mac-Hacker sind, die auch ein Buch darüber geschrieben haben, welches ich auf meiner Seite empfehle.
Allerdings hat Charlie auch einmal gesagt, daß er seine Lebensaufgabe darin sieht, Apple schlecht zu machen. Von daher kommen solche Aussagen nicht von ungefähr.
Fachlich bezog sich die Aussage nicht pauschal auf OS X, sondern auf einen ganz speziellen Aspekt und zwar darauf, daß OS X Address Space Layout Randomization (ASLR) nur für Systembibliotheken vornimmt, nicht jedoch für Anwendungsprogramme. Das ist richtig, hat aber mit effektiver Sicherheit nicht viel zu tun: ASLR bietet keine tatsächliche Sicherheit, sondern positioniert einfach ausgedrückt interessante Codestellen an zufälligen Adressen. Um einen Exploit zu schreiben, muß man dann, falls man ASLR nicht umgeht, sozusagen noch eine Suche einprogrammieren. ASLR ist, als wenn man die Eingangstür jeden Tag an einer anderen Stelle an der Hauswand positioniert. Der Einbrecher findet sie trotzdem oder umgeht das Problem, indem er ein Fenster öffnet. Dazu gleich mehr.
Das ASLR von Applikationen hat zudem weder Windows Vista noch Windows 7 genützt, denn es ist schon oft überwunden oder umgegangen worden, auch auf den oben angesprochenen Hacker-Wettbewerben.
Die Uni Stanford hat sogar gezeigt, wie man aus einem Exploit, der ohne ASLR funktioniert, einen Exploit generieren kann, der gegen ASLR funktioniert.
Peter Vreugdenhil hat mehrere generelle Wege (Proof of Concepts) gefunden, um ASLR und DEP auf 7 und Vista zu umgehen. Damit sind beide Techniken ziemlich wertlos.
Zusammenfassend muß man also sagen, daß sich der “macht Spaß”-Spruch auf eine spezielle nur teilweise angewandte Technik bezog, die so oder so nur eine scheinbare Sicherheit bietet.

Die Vorteile, die ich bezüglich OS X gegenüber GNU/Linux nenne, sind nicht “bei Windows schon lange drin”. Im Gegenteil:
Das Portable Executable (PE) Format der Windows-Binaries ist eine modifzierte Version des relativ primitiven und uralten UNIX Common Object File Format (COFF). Auf UNIX ist das inzwischen durch das bessere Format ersetzt worden, welches auch Linux verwendet: Executable and Linkable Format (ELF).
Das Code-Signing bei Windows bezieht sich hauptsächlich auf Kompatibilitätsaspekte, die von Microsoft damit abgesegnet werden. Vor allem ist es bei OS X flächendeckend inklusive Drittherstellern umgesetzt. Bei Windows bezieht es sich hauptsächlich auf Gerätetreiber und ähnliches.
Die UAC ist kein Sicherheitsmechanismus. Mark Russinovich von Microsoft hat das in seinen Technotes deutlich beschrieben und auch Beipiele gezeigt, wie ein Low-Integrity-Process einen höheren beeinflussen kann, beziehungsweise, wie man aus einer Integritätsstufe ausbricht – by Design. Die UAC ist eine sehr mäßige umsetzung von Mandatory Access Control (MAC). Das ist bei Linux und OS X besser und vor allem wirkungsvoll umgesetzt.

Die grundlegenden Architektur-Vorteile von OS X sind von Anfang an schon drin gewesen, also 10.0. Der grundlegende Aspekt ist, daß es auf jedem System immer Bugs geben wird. Die entscheidende Frage ist jedoch, was aufgrund solcher Bugs angestellt werden kann. Bei UNIX im Allgemeinen und OS X im Speziellen, trifft jede Art von Schadprogramm auf mehr Schwierigkeiten als auf Windows. Einfachstes Beispiel ist der Umstand, daß ein Windows-User trotz UAC dank der “gespaltenen Persönlickkeit” des sogenannten “Protected Administrators” Systemrechte hat, die ein Schädling nutzen kann um das System zu verändern. Wem das nicht klar ist, mag sich an Mark Russinovich von Microsoft wenden. Admins auf OS X haben keine Systemrechte. Das hat nur root oder die Gruppe wheel. Weitere Details finden sich auf meiner Seite.

Viele Bug-Beschreibungen in der Presse sind reißerisch und irreführend. Insbesondere, wenn es um OS X geht.

Die “Demontage” auf der von “xyz” angesprochenen Seite, dem Windows 7 Blog von Microsoft Deutschland, habe ich dort damals schon beantwortet. Wie Du mich schon richtig zitierst, ist diese “Demontage” ein Paradebeispiel für “manche lesen nicht, was da steht, sondern was sie lesen wollen.” Der “Demonteur” hat auch meine Korrekturen an seiner “Demontage” nicht verstanden und eine Diskussion abgelehnt.

Und meinen Hintergrund sollte jeder kennen, denn ich bin ja nicht anoynm. Siehe dieses Interview und mein Impressum.

Grüße von
MacMark

By: xyz

xyz — Sat, 15 May 2010 07:03:21 +0000

Defragmentieren ist gefährlich? “Ein Bug im Programm, versehentlicher Neustart oder Stromausfall während der Defragmentierung bedeutet Datenverlust.” Das bedeutet es genauso für normale Schreibzugriffe. Das hat mit Defragmentieren null zu tun.

“Defragmentierung ist eines der typischen Switcher-Themen, weil es unter Windows nötig und gewohnt ist.”

Warum muss eigentlich Liebe zum Mac so oft mit Seitenheiben auf Windows korrelieren? Vor allem mit falchen, die nur das tiefe Unwissen von einem selbst zeigen? Defragmentierung ist unter Windows seit Vista auch kein Thema, genauso wie beim Mac. Das erledigt das System automatisch im Hintergrund. Vielleicht wäre hier ein wenig mehr Recherche hilfreich anstatt mit pauschalem Windows-Bashing seine “Kompetenz” zu zeigen.

“Es gibt durchaus Leute die Mac OS X als unsicher einstufen. Diese Stimmen kommen auch aus dem Linuxlager. Was denkst du darüber?”

Klar das ein Mac-Liebhaber da als erstes wieder auf Windos losgehen muss *Kopfschüttel*:

“Solche Stimmen höre ich meist aus dem Windows-Lager. Von Seiten der GNU/Linux-User kenne ich derartiges eigentlich gar nicht.”

Vielleicht sollte Euer Experte da mal besser genauer hin hören. Vor allem, wenn er sich selbst anmaßt, über Security zu schreiben. Seine Seite ist voll mit Falschinformationen zu dem Thema. Wieso wohl werden Macs mit am schnellsten gehackt auf jedem Hacking Contest? Pwn2own-Fazit: “Mac hacken macht Spaß, Windows ist harte Arbeit”: http://www.heise.de/newsticker/meldung/Pwn2own-Fazit-Mac-hacken-macht-Spass-Windows-ist-harte-Arbeit-208604.html
Was er als Sicherheitsgewinn gegenüber Linux aufführt, ist übrigens in Windows schon lange drin. Länger als in OS X. Das verschweigt er aber. Windows wird nur dort rausgeholt, um uralte Kamellen als Beispiele heranzuziehen.

Es stört aber Euren Experten, wenn man sein “keine durch ungeeignete System-Architektur bedingten Schwachstellen” kritisiert. Mac OS X hat also die perfekte System-Architektur? Seit welcher Version denn? 10.0 oder vielleicht auch erst später? So eine Pauschalaussage ist doch nichts wert, wenn man dann tausende Sicherheitslücken, die in OS X und den mitgelieferten Anwendungen von Apple bisher gefixed wurden, die jegliche Sicherheitsstufe (auch die höchste) erreicht haben und die totale Kompromittierbarkeit des Systems ermöglichen, einfach abtut. Die haben alle nichts mit der System-Architektur zu tun?

“Manche lesen nicht, was da steht, sondern was sie lesen wollen.” Manche biegen sich die Realität auch so hin, wie sie es wollen.

Vielleicht solltet ihr mal den Hintergrund Eures “Experten” besser prüfen, bevor ihr so ein Interview macht. Seine Argumente aus dem Bereich Sicherheit wurden hier sehr schön widerlegt (man kann auch von Demontage sprechen): http://blogs.technet.com/sieben/archive/2010/04/23/keine-admin-rechte-sicherere-pcs.aspx