Als Admin/User arbeiten

[Tzunami]

admin oder User ist bei macos x Hose wie Jake, beide können ohne Eingabe eines Passwortes keine systemdateien ändern oder manipulieren die brauchen nämlich rootrechte.

Vorteil ist, das ein admin alle Systemeinstellungen ändern kann ohne jedes mal nach einem Passwort gefragt zu werden.

Auch als normalo kannst du einen Installer starten, wenn er nach dem User/Passwort fragt, kennt du sowieso das adminpasswort und wird dieses spätestens beim 2ten versuch benutzen.

ob Admin oder User, wenn mann das Adminpasswort kennt hilft es nur dieses auch verantwortungsbewusst einzusetzen.

 

[Nogger]

Und
wenn wirklich einmal mehrere Personen an einem Mac arbeiten, werden halt
verschiedene Accounts angelegt und gut ist. Ist doch wohl normal, dass derjenige,
dem der Mac gehört auch gleichzeitig Admin ist.

Es geht überhaupt nicht darum, wem der Mac gehört, und wieviele Personen daran arbeiten.

root -> darf alles

admin-user -> darf nur seinen Kram machen, darf aber bestimmte Administrationstätigkeiten durchführen und zu root wechseln mittels sudo

normaler user -> darf nur seinen Kram machen.

Wenn durch eine Lücke oder Userfehlverhalten ein Worm/Virus in der Lage ist, unter dem aktuellen User Befehle auszuführen, dann ist der potentielle Schaden sehr viel geringer, wenn der User nur ein normaler User ist.

 

[abgemeldeter Benutzer]

Mal ne doofe Frage… ich arbeite immer als Admin… wo kann ich den Account denn zum simplen User machen?

Yves

Wenn das Dein einziger Account ist, gar nicht, denn ein Account muss immer Admin bleiben.

Da Root ja deaktiviert ist (und auch kein Passwort besitzt), ist ein Admin-Passwort die einzige Möglichkeit Konfigurationen über das Security Framework vorzunehmen bzw. ist der Admin die einzige Möglichkeit in der shell mit sudo root-Rechte zu erlangen.

P.S. Am Ende ist es völlig egal, ob man als Admin oder als normaler-Benutzer arbeitet, denn für eventuelle Viren würde nicht das Arbeiten mit dem Benutzer, sondern seine reine Existenz den Angriffspunkt bieten. Schon gar nicht, wenn der Mensch, der als normaler Benutzer arbeitet, auch das Admin-Passwort kennt.
Deshalb ist im Sicherheitskonzept von Mac OS X auch vorgesehen, dass root deaktiviert ist. root bietet damit schon mal keinen Angriffspunkt, wegen der mehrstufigen Identifizierung ist aufwendiger die Angriffspunkte über Admin anzugreifen, als über root.

 

[Nogger]

Wenn das Dein einziger Account ist, gar nicht, denn ein Account muss immer Admin bleiben.

Deshalb ja auch der Tip, einen separaten Admin Account anzulegen und der Hauptidentität das Adminrecht zu entziehen.

Am Ende ist es völlig egal, ob man als Admin oder als normaler-Benutzer arbeitet,

Nein, denn...

root bietet damit schon mal keinen Angriffspunkt, wegen der mehrstufigen Identifizierung ist aufwendiger die Angriffspunkte über Admin anzugreifen, als über root.

normaler user -> admin user -> root

ist besser als

admin user -> root

 

[abgemeldeter Benutzer]

normaler user -> admin user -> root

ist besser als

admin user -> root

Nicht wirklich, denn beide Schritte verwenden das gleiche Passwort (nämlich das des Admin-Users).

 

[ratti]

Nun, das dürfte auch weiterhin erst einmal ein Problem für Windows-Benutzer bleiben. Möglicherweise mag UNIX eines Tages ebenfalls
die selben gravierenden Sicherheitsprobleme haben, aber bis das
soweit ist, erfreue ich mich jeden Tag aufs neue an einen Viren-
und Wurmfreien System.

Wie kommst du denn auf das schmale Brett?

Punkt 1:
Unix ist deswegen sicherER, weil es ein restriktives Sicherheitskonzept verfolgt. Je mehr Leute das aufreissen, um so unsicherer wird es. Niemand hat vor der Kiste Respekt, nur weil es Unix heisst.

Punkt 2:
Das übliche Sicherheitsverständnis bezieht sich AUSSCHLIESSLICH auf Server: Eine Malware kann ja "nur" die Userdaten des infizierten Users löschen, keinesfalls aber die Datenbanken, Webseiten, [...] die der Server so served. Das ist aber in der Regel Quatsch für die Kiste, die grad vor dir steht: Wenn eine Malware hier "nur" deine Userdaten löscht, dann ist eben gerade das *wichtigste* weg, was drauf ist: Deine Musik, deine Dokumente, deine selbstgeschriebene Software, deine Pornosammlung, deine...
Das klassische Unix-Sicherheitskonzept rettet dich also ganz und gar nicht: Einmal falsches Attachment geklickt und ZACK ist alles wichtige platt. Daß dein nacktes System nach wie vor unbeschädigt ist, wird dich dann kaum trösten. Wozu noch iTunes ohne Mpegs?


Als ich es das letzte mal ausprobiert hatte, konnte man einem AppleScript prima ein QuarkXpress-Icon verpassen und es per Mail verschicken. Hoffentlich geht das inzwischen nicht mehr, ansonsten ist es nur eine Frage der Zeit, bis die erste Wurmwelle über uns hinwegrast. Schuld ist daran m.E. das schwachsinnige Apple-Dateihandling, welches mit Type und Creator arbeitet anstelle einer Headeranalyse. Kannst ja mal im Terminal das Tool "file" ausprobieren:

ratti@ratti:~$ cp /sbin/fdisk ./harmlos.doc
ratti@ratti:~$ file harmlos.doc
harmlos.doc: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.0, dynamically linked (uses shared libs), stripped

So macht man das.

Ich reg mich schon wieder auf!
Gruß, Ratti

 

[Nogger]

Nicht wirklich, denn beide Schritte verwenden das gleiche Passwort (nämlich das des Admin-Users).

OK.

Es macht aber trotzdem einen Unterschied.

Ein Virus unter einem Adminuser kann unmittelbar Anwendungen löschen oder verändern (Gruppenschreibrechte für Gruppe admin).

Ein Virus unter einem normalen User kann das nicht, und muß sich erst Zugang zu dem Adminuser verschaffen.

 

[HAL]

So macht man das.

Was wird das jetzt hier, Hackers Guide für Anfänger ?! Ihr solltet darauf
achten was ihr postet, am Ende kommen irgendwelche Scriptkids auf
dumme Gedanken und erzählen irgendwo: "Geile Sache, hab ich gerade
bei Macuser.de gelesen...".

Super. Würde mich freuen, wenn Du deinen Crashkurs wieder entfernst.

Danke.

 

[Nogger]

Das klassische Unix-Sicherheitskonzept rettet dich also ganz und gar nicht: Einmal falsches Attachment geklickt und ZACK ist alles wichtige platt.

Als ich es das letzte mal ausprobiert hatte, konnte man einem AppleScript prima ein QuarkXpress-Icon verpassen und es per Mail verschicken.

Ja, und? Wurde es dann von Mail beim Doppelklick ausgeführt oder mit Quark geöffnet?

Hoffentlich geht das inzwischen nicht mehr, ansonsten ist es nur eine Frage der Zeit, bis die erste Wurmwelle über uns hinwegrast.

Schuld ist daran m.E. das schwachsinnige Apple-Dateihandling, welches mit Type und Creator arbeitet anstelle einer Headeranalyse.

Ich sehe keinen Nachteil. Type und Creator sind eine gute Idee mit vielen Vorteilen.

Ob ein Programm jetzt aufgrund eines gesetzten Types oder aufgrund von file() oder Aufgrund der Dateiendung (Windows) entscheidet, ob eine Datei ausführbar ist, ist doch egal. Ein Mailprogramm sollte als ausführbar erkannte Attachments beim Doppelklick nicht starten. Egal unter welchem OS.

 

[Grady]

Security by obscurity ?

OpenSource hat doch gerade den Ansatz und großen Vorteil, dass die Quelle offenliegt und man sich sicher sein kann, dass etwas sicher ist. Listen wie Bugtraq&Co. sind dann überflüssig, bzw. gefährlich?!? Mir ist es lieber, wenn Apple endlich mal etwas gegen die Lücken tut.

 

[ratti]

Was wird das jetzt hier, Hackers Guide für Anfänger ?! Ihr solltet darauf achten was ihr postet, am Ende kommen irgendwelche Scriptkids auf dumme Gedanken und erzählen irgendwo: "Geile Sache, hab ich gerade bei Macuser.de gelesen...".

Super. Würde mich freuen, wenn Du deinen Crashkurs wieder entfernst.

Ein System ist entweder sicher, oder es ist unsicher.

Ein System, welches nicht mehr sicher ist, wenn nur genug Leute rumerzählen, wie man reinkommt, gehört zu Recht den Scriptkiddies zum Fraß vorgeworfen.
Und wenn es durch Ändern eines Icons zu plätten ist, dann gehört es geplättet.

Ich gehe allerdings davon aus, daß das inzwischen nicht mehr der Fall ist. Ich habe zuhause keinen Mac, auf dem ich das testen könnte.

Alles andere nennt sich "Security through obscurity" und hat genau DAS Problem produziert, mit dem die Win-Leute sich jetzt auseinandersetzen dürfen. Einfach einem Script den Mimetype für Film verpassen, und die Deppenkiste macht es von allein auf, und solche Geschichten.


Darüberhinaus habe ich den Verdacht, daß du den "So macht man das"-Teil nicht verstanden hast: Eine Dateizuordnung nach Headeranalyse heisst eben gerade, daß irgendwelche Extensions, Dateitypen, Creator, Mimetypes, [...] völlig egal sind, das System weiss immer, WAS genau es da in der Hand hat. Ich habe in meinem Beispiel fdisk als Worddokument tarnen wollen, und wenn das System das richtig macht, dann geht das glücklicherweise voll in die Hose.

Das geht auf meinem System so weit, daß eine .php-Datei nicht vom Texteditor geöffnet wird, wenn erstmal noch kein < ? php-Tag drinsteht, sondern nur <html>. Gnome sagt einfach: "Die Datei gibt sich als php aus, ist aber html. Beschiss! Ich öffne diese Datei nicht. [CANCEL]". Ich muss dann tatsächlich erstmal ein leeres < ? php ? > reinschreiben, um eine Textdatei(!) im Texteditor(!) öffnen zu dürfen.

Sicher ist man trotzdem nie. Heute wurde eine Sicherheitslücke in der png-Library bekannt gemacht. Seufz...wo ist die nicht drin?

Gruß, Ratti

 

[Nogger]

Mir ist es lieber, wenn Apple endlich mal etwas gegen die Lücken tut.

Welche Lücken?

 

[ratti]

Ja, und? Wurde es dann von Mail beim Doppelklick ausgeführt oder mit Quark geöffnet?

Ausgeführt natürlich, es hatte ja nur das Icon, nicht aber den FileType. Natürlich kam nur ein "Hallo"-Alert, aber prinzipiell "gehört" dir an dieser Stelle der Useraccount und daher bei einer ein-Personen-Kiste realistisch gesehen der ganze Rechner (Keylogger im Userspace, das wars).

Ich sehe keinen Nachteil. Type und Creator sind eine gute Idee mit vielen Vorteilen.

Ob ein Programm jetzt aufgrund eines gesetzten Types oder aufgrund von file() oder Aufgrund der Dateiendung (Windows) entscheidet, ob eine Datei ausführbar ist, ist doch egal. Ein Mailprogramm sollte als ausführbar erkannte Attachments beim Doppelklick nicht starten. Egal unter welchem OS.

Ich sehe Nachteile:

- Es ist fälschbar und somit ein Ansatz für Malware. Anregungen dazu habe ich schon gegeben.

- Es ist inkompatibel zum Rest der Welt und in der Kommunikation dann meist auch schnell kaputt. An meinem Tisch stehen den halben Tag Leute, die per Mail erhaltene "Freehand-8-EPSe" nicht aufbekommen, weil es eben gar keine Freehand-8-EPSe sind, sondern irgend ein anderes EPS, welches ihnen von $ANDERES_BETRIEBSSYSTEM zugesandt wurde.

- Das Verfahren hilft dir nicht weiter, wenn du die Software noch nicht installiert hast. Weisses Blatt. Hm. Wenn du richtig geeky bist, besorst du dir Type und Creator und weisst dann "TRGA|8BIM". Hm. Hm. Hm. Und nun?


Und jetzt vergleich das mal mit der Headeranalyse. Ein Beispiel aus der Praxis: Ich sammle Schriften und lasse mir alt.binaries.fonts automatisch downloaden und dekomprimieren. Meistens heissen die Dateien dann "Schrift.zip", was erfreulich ist, oft genug aber:

ratti@ratti:~/download/fontdownload/files$ ls -1ad UNK*
UNKNOWN.001
UNKNOWN.001.1088545694.1876455837
UNKNOWN.001.1088627040.1893905891
UNKNOWN.001.1089060405.97762554
UNKNOWN.001.1089062654.1598271194
UNKNOWN.002
UNKNOWN.002.1089060405.712825072
UNKNOWN.003

Uuuuups... und jetzt mit der Geheimwaffe "file":

ratti@ratti:~/download/fontdownload/files$ file UNK*
UNKNOWN.001: GIF image data, version 89a, 245 x 36
UNKNOWN.001.1088545694.1876455837: Zip archive data, at least v2.0 to extract
UNKNOWN.001.1088627040.1893905891: Zip archive data, at least v2.0 to extract
UNKNOWN.001.1089060405.97762554: AppleDouble encoded Macintosh file
UNKNOWN.001.1089062654.1598271194: PNG image data, 300 x 30, 8-bit colormap, non-interlaced
UNKNOWN.002: JPEG image data, JFIF standard 1.01
UNKNOWN.002.1089060405.712825072: GIF image data, version 89a, 348 x 72
UNKNOWN.003: JPEG image data, JFIF standard 1.01


Siehst du den Vorteil?

Auf Wunsch kann man sich auch stattdessen den Mimetype ausgeben lassen (Ich lass die Filenamen mal weg, der Lesbarkeit wegen):

image/gif
application/x-zip
application/x-zip
application/octet-stream
image/png
image/jpeg
image/gif
image/jpeg

Im Prinzip sind das deine Extensions oder Filetypes - nur eben richtig.

Wenn du das nächste Mal von einem Windowsler ein Attachment gemailt bekommst, das mit nix aufgehen will, denk an "file" und die Kommandozeile - OS X hat all diese Sachen schon dabei.


Das Verfahren von Windows ist natürlich nicht besser als Type/Creator: Es wirft sogar beides zusammen (Wie üblich: Erstens geklaut, und zweitens auch noch schlecht. ). Im Prinzip ist es aber sehr ähnlich: Das Erstellungsprogramm gibt einen Typ vor, und die anderen Programme glauben es erstmal. Und damit lässt sich herrlich Schindluder treiben.

Gruß, Ratti

 

[Nogger]

Das geht auf meinem System so weit, daß eine .php-Datei nicht vom Texteditor geöffnet wird, wenn erstmal noch kein < ? php-Tag drinsteht, sondern nur <html>. Gnome sagt einfach: "Die Datei gibt sich als php aus, ist aber html. Beschiss! Ich öffne diese Datei nicht. [CANCEL]". Ich muss dann tatsächlich erstmal ein leeres < ? php ? > reinschreiben, um eine Textdatei(!) im Texteditor(!) öffnen zu dürfen.

Ich halt dieses Verhalten für falsch.

1. Ist eine PHP Datei auch dann eine gültige php Datei, wenn es keinen php Codeblock enthält (Beweis: CLI Version mit der Datei füttern -> PHP meldet OK). D.h. die Typprüfung ist fehlerhaft.

2. Halte ich diese Prüfung für völlig sinnlos, denn sie bringt überhaupt keinen Vorteil sicherheitstechnisch. Wenn du dein fdisk als Word-Dokument tarnst, dann passiert folgendes: mit Prüfung: "Das ist kein Word Dokument. Cancel". Ohne Prüfung: fdisk wird IN Word geöffnet. Steht dann halt nur Zeichensalat dort. Ja und?

 

[Nogger]

Ausgeführt natürlich, es hatte ja nur das Icon

Das its ein eindeutiger Fehler des Programms, wenn es ausführbare Attachments auch ausführt. Ich kann mir nicht vorstellen, daß es Mail.App noch so macht.

Ich sehe Nachteile:

ein Ansatz für Malware. Anregungen dazu habe ich schon gegeben.

Sehe ich nicht, auch nicht in deinen Ausführungen. Konkretes Beispiel?

- Es ist inkompatibel zum Rest der Welt und in der Kommunikation dann meist auch schnell kaputt. An meinem Tisch stehen den halben Tag Leute, die per Mail erhaltene "Freehand-8-EPSe" nicht aufbekommen, weil es eben gar keine Freehand-8-EPSe sind, sondern irgend ein anderes EPS, welches ihnen von $ANDERES_BETRIEBSSYSTEM zugesandt wurde.

Hää? Sie bekommen eine Mail, mit vom Sender bezeichneten mime-typ image/eps und das Mailprogramm weist sie als öffnenbar mit Freehand aus, weil das die MIME Zuordnung ist. Aber Freehand meldet einen Fehler, weil die Datei irgendwas in dem EPS enthält, mit dem Freehand nichts anfangen kann. Soweit richtig?

Was wäre bei einer HTML Datei mit Inline CSS, der verknüpfte Editor verweigert das öffnen, weil er kein CSS kann. Eine file() basierte Zuordnung würde nichts helfen, ob mit oder ohne css, beides text/html.

Wenn die Datei aber überhaupt kein EPS ist, aber trotzdem so deklariert ist, wäre eine Hilfesfunktion für den User sinnvoll. Ich kann mir als Menüpunkt "Dateityp korrigieren" Befehl per file() vorstellen.

- Das Verfahren hilft dir nicht weiter, wenn du die Software noch nicht installiert hast. Weisses Blatt. Hm. Wenn du richtig geeky bist, besorst du dir Type und Creator und weisst dann "TRGA|8BIM".

Sollte dann der Mac nicht anhand des Type eine passende Applikation starten, wenn der Creator nicht installiert ist?

Und jetzt vergleich das mal mit der Headeranalyse.
[...]
Siehst du den Vorteil?

File ist ein Werkzeug, um zu *versuchen* den Typ eines Objekts zu ermitteln. Das tut es recht brauchbar.
Ich sehe folgendes Problem, es als die Methode des Betriebsystems für Dateizuordnung zu Applikationen zu nutzen: fehlende Eindeutigkeit.

file() kann die raw-Audio Datei, die ich gerade aufgenommen habe, und die zufällig die Magic von jpg enthält, nicht von einem jpg unterscheiden. Ich kann die Datei nicht mehr durch Doppelklick in dem Editor öffnen, in dem ich sie gerade noch gespeichert habe.

Du mußt Metadaten zu Dateien speichern (Dateiendung oder type/creator), um Eindeutigkeit zu erreichen. Der Schluß von Syntax auf Semantik ist nicht eindeutig.

 

[Grady]

2. Halte ich diese Prüfung für völlig sinnlos, denn sie bringt überhaupt keinen Vorteil sicherheitstechnisch. Wenn du dein fdisk als Word-Dokument tarnst, dann passiert folgendes: mit Prüfung: "Das ist kein Word Dokument. Cancel". Ohne Prüfung: fdisk wird IN Word geöffnet. Steht dann halt nur Zeichensalat dort. Ja und?

Das wäre die Spar-Version. Wenn man einfach das Icon eines Skriptes auf das eines Word-Dokuments ändert, bleibt es ausführbar und wird bei Doppelklick nicht mit Word gestartet. Da hat Apple noch nichts geändert.
Das letzte Sicherheitsupdate hat eine andere Lücke geschlossen, wo nun eine Abfrage kommt: http://docs.info.apple.com/article.html?artnum=25785

 

[abgemeldeter Benutzer]

@ ratti
In Deinem Beispiel würde am Mac da stehen:
harmlos.doc
Art: Programm
(Natürlich nur, wenn die Datei mit dem Type-Code APPL versehen worden ist und kodiert verschickt worden ist, damit wäre der Type-Code und die Programm-Resourcen nicht verloren gehen.)

Und
@ Nogger
Mail.app würde die Datei nicht ausführen, sondern eine Warnung ausgeben, dass das Mail im Attachement eine ausführbare Datei enthält.

 

[ratti]

Das its ein eindeutiger Fehler des Programms, wenn es ausführbare Attachments auch ausführt. Ich kann mir nicht vorstellen, daß es Mail.App noch so macht.

Davon gehe ich aus - das hilft aber nicht.

Fast alle "meine" User verwenden Icon-oder Tabellendarstellung im Finder, sie haben also nichts anderes als das Aussehen des Icons, um Dateien zu idenzifizieren. Sie würden also brav das Attachment abspechern und es vom Schreibtisch aus öffnen.

Du wirst lachen, aber: Zu mir kommen regelmässig Mac-User, die "so eine EXE-Datei" per Mail an ihrem Mac zugeschickt bekommen haben, und fragen, ob sie sie an meinem Windows-Rechner (Ich teste dort Websites) öffnen dürfen, am Mac kriegen sie sie nicht auf.

Sehe ich nicht, auch nicht in deinen Ausführungen. Konkretes Beispiel?

Meine Ausführung war: Nimm eine Apple-Script-Datei und verpass ihr ein Word- (Quark, Text, QuickTime,...)-Icon. Sie wird geklickt, weil das Icon nicht anhand des Inhalts vom System *erzwungen* wird. Einziger Vorteil: Kleine Previewbildchen bei Grafikfiles. Na Danke, das ist zwar nett, aber das ist es nicht wert.

War da vor einiger Zeit nicht eine "Pseudo-Raubkopie" von Office in Umlauf, die ~/ löschte, nach genau diesem Prinzip?

Hää? Sie bekommen eine Mail, mit vom Sender bezeichneten mime-typ image/eps und das Mailprogramm weist sie als öffnenbar mit Freehand aus, weil das die MIME Zuordnung ist. Aber Freehand meldet einen Fehler, weil die Datei irgendwas in dem EPS enthält, mit dem Freehand nichts anfangen kann. Soweit richtig?

Richtig. Weil Type/Creator einen Informationsoverhead hat, den kein anderes OS kennt. Wie du schon sagst: image/eps, und eben nicht image/eps/freehand. Gezwungenermassemn vergeben die Programme dann irgendeinen Creator, der passen könnt. Bei Mail, bei ftp,... - immer dann, wenn es CrossPlattform geht.

Das Problem ist dann, daß die User in die Irre geführt werden, weil sie es nur so kennen, daß ein Freehand-Icon eben auch Freehand ist - und nicht etwa ein Illustrator-eps. Du kannst dir gar nciht vorstellen, wieviele Dokumente immer und immer und immer wieder neu hin- und -hergeschickt werden, bevor mir mal jemand bescheid sagt und ich das blöde Ding einfach mal auf BBedit droppe und mir einfach den Header ansehe.

Was wäre bei einer HTML Datei mit Inline CSS, der verknüpfte Editor verweigert das öffnen, weil er kein CSS kann. Eine file() basierte Zuordnung würde nichts helfen, ob mit oder ohne css, beides text/html.

Nein, weil file() immer nur die ersten paar Bytes anguckt. Wenn darin < html > vorkommt, ist es eine HTML-Datei. Hinterher kannst du dann gerne C++-Code schreiben.

Wenn die Datei aber überhaupt kein EPS ist, aber trotzdem so deklariert ist, wäre eine Hilfesfunktion für den User sinnvoll. Ich kann mir als Menüpunkt "Dateityp korrigieren" Befehl per file() vorstellen.

Was du da als "Reparatur-Hilfe" siehst, verwenden eben Gnome oder KDE als default.
Nichts ist ohne Makel, aber unter'm Strich funktioniert es besser. Gut, wenn ich einen Artikel schreibe:

<html> ist eine Krankheit!
Wer soll denn in sowas Seiten basteln? Alles voller komischer Zeichen...

Dann geht tatsächlich auf Doppelklick der falsche Editor auf, und ich müsste "Öffnen mit..." verwenden.

Ich sehe folgendes Problem, es als die Methode des Betriebsystems für Dateizuordnung zu Applikationen zu nutzen: fehlende Eindeutigkeit.

file() kann die raw-Audio Datei, die ich gerade aufgenommen habe, und die zufällig die Magic von jpg enthält, nicht von einem jpg unterscheiden. Ich kann die Datei nicht mehr durch Doppelklick in dem Editor öffnen, in dem ich sie gerade noch gespeichert habe.

Du wirst in der Unix-Welt solche Daten nicht finden. Genau deswegen. Warum sollte man raw-Daten haben? Man kann das Format in ein paar Bytes kapseln, und schon hat man was eindeutiges.

Übrigens unterstützt 'file' durchaus auch "Mehrfach-Erkennung" mit -k (keep going).

[/QUOTE]
Du mußt Metadaten zu Dateien speichern (Dateiendung oder type/creator), um Eindeutigkeit zu erreichen. Der Schluß von Syntax auf Semantik ist nicht eindeutig.[/QUOTE]

Eindeutigkeit ist auch nicht nötig. Schlimmstenfalls geht das falsche Programm auf, /das die Daten aber lesen kann/ - weil z.B. normales ASCII mit HTML verwechselt wurde, siehe oben.
Dafür bist du aber Cross-Platform-sicher, sicherER gegen Irrtümer oder sogar Attacken mit falschen Metadaten, und es ist sehr bequem bei unbekannten Daten.

 

[ratti]

Ich halt dieses Verhalten für falsch.

1. Ist eine PHP Datei auch dann eine gültige php Datei, wenn es keinen php Codeblock enthält (Beweis: CLI Version mit der Datei füttern -> PHP meldet OK). D.h. die Typprüfung ist fehlerhaft.

Dann schreibst du halt < ? php ? > rein, und die Welt ist ein besserer Ort.
Unixe sind nicht in erster Linie bequem oder praktisch, sie sind vielmehr streng und zwingend. Daher rührt der enorme Sicherheitsgewinn.

Das ist auch ein Vorwurf, den ich Apple mache - zum Beispiel (teilweise) Dateityp-Erkennung aufgrund von Extensions einzubauen, dann aber das Anzeigen der Extensions per default zu unterdrücken und es nur zuzulassen, wenn der User dafür ein englisches System akzeptiert - also macht's keiner.

2. Halte ich diese Prüfung für völlig sinnlos, denn sie bringt überhaupt keinen Vorteil sicherheitstechnisch. Wenn du dein fdisk als Word-Dokument tarnst, dann passiert folgendes: mit Prüfung: "Das ist kein Word Dokument. Cancel". Ohne Prüfung: fdisk wird IN Word geöffnet. Steht dann halt nur Zeichensalat dort. Ja und?

Wenn du fdisk ein Word-Icon verpasst, wird es nicht in Word geöffnet, sondern je-nachdem. Zum Beispiel, wenn es die Extension ".command" hat (Glaubich? Grad kein Mac hier? Oder war's .term? Egal.) direkt in der Shell. Natürlich macht das bei fdsik nix, denn da muß man noch ein paar Dinge mehr machen, aber folgendes Szenario:

Ich schreibe ein Shellscript, welches alles im Heimverzeichnis löscht (Dafür ist keine Authentifizierung nötig). Dem verpasse ich ein Word-Icon und nenne es:

"Wildschwein-porno.doc___________________________________.command"

Denk dir Leerzeichen anstelle der Unterstriche.
Der User zieht sich das auf den Desktop, sieht dort den gekürzten Dateinamen, klickt drauf, - bumm.

Da kann man jetzt was machen. Windows besteht wahrscheinlich fast komplett aus "if"-Abfragen, um zu verhindern, daß solche Dateien, einmal ins System gelangt, gestartet werden. Und einmal pro Woche findet wieder jemand eine Lücke, die darauf basiert, daß jemand ein Nullbyte oder einen Umbruch reinmogelt, den Dateinamen länger als 32KB macht oder ihn urlencoded (%0D statt Zeilenumbruch), oder oder oder...

Für mich ist die Lehre daraus, daß es so nicht funktionieren KANN. Metadaten und Iconbildchen sind keine zuverlässige Information über Content.
Fileheader mögen das auch nicht sein, aber im Versagensfall sind sie nur unbequem, nicht aber gefährlich.

 

[abgemeldeter Benutzer]

"Wildschwein-porno.doc___________________________________.command"

Unter Mac OS X werden die Dateinamen in der Mitte gekürzt. Der Benutzer sieht also "Wildschwein-porno.doc....command" bzw. bei ausgeblendetem Suffix "Wildschwein-porno.doc...."