Mountain Lion: gesperrte Programme ausführen
von caschy | 11 Kommentare
Kleiner Tipp für alle Mac OS X Mountain Lion-Nutzer. Das Betriebssystem kommt mit dem Sicherheitsfeature Gatekeeper daher. Nicht bestätigte Entwickler und Apps, die nicht aus dem Mac App Store kommen, werden so geblockt, eine Installation von Fremd-Software wäre nicht möglich. Nun könnte man in den Sicherheitseinstellungen unter dem Punkt „Allgemein“ auswählen, wie das System sich verhalten soll.
Soll es direkt alles blocken, was nicht aus dem Mac Store kommt, oder darf man von verifizierten Entwicklern auch unter Umgehung des Stores installieren? Auch lässt sich dieses Sicherheitsfeature deaktivieren, was nicht ratsam ist. Was aber macht man am besten? Man lässt die Einstellung restriktiv, muss aber nur eine kleine Tastatur-Kombi im Kopf haben, wenn man (wie ich) ab und an Apps ausprobiert, die nicht aus dem Store kommen.
Öffnet man diese Programme nämlich via STRG+Klick und wählt aus dem Menü „Öffnen“, dann kann man auch die App öffnen, wenn der Entwickler unbekannt ist. Dieses muss man nur einmalig machen, danach ist diese App ganz normal startbar.
Wird geladen ...
nice!
ich fürchte aber, dass apple schon in 10.9 keine unsignierten apps mehr zulässt. ganz so wie auf ios…
„was nicht ratsam ist“
Bitte was? Um im AppStore verkaufen zu müssen, muß man in Vorkasse gehen, sofern ich weiß gilt das auch für die registrierte ID.
Es gibt aber genug gute (Freeware-)Programme, wo es sich die Entwickler nicht leisten können oder wollen, extra dafür Geld auszugeben.
Sicherheit ist dabei eh nur vorgetäuscht, die Vergangenheit hat oft genug gezeigt, wie lachs Apple mit Security im AppStore umgeht.
IMHO ist das nicht mehr, als der nächste Versuch, dem goldenen Käfig auch noch ein Schloß vorzuhängen.
@Mike: Ich bleibe dabei: nicht ratsam. Es steht jedem frei, das Feature zu deaktivieren oder den Shortcut zu nutzen. Windows 8 hat sowas übrigens in ähnlicher Form.
Ach was, „nicht ratsam“: WENN schon, dann richtig, genau wie bei der UAC. Anlassen und ertragen oder GANZ aus, aber nicht so faule Kompromisse, grins!
Gut, du verdienst dein Geld mit dem Comp, gut, das muß jeder selber wissen (mit genug Ahnung, und die hast du) – aber bei meiner Strategie ist auch noch deswegen nix „dauergecrasht“ oder infiziert…. 😕
@caschy, nur weil MS das nun auch macht, wiederlegt das nicht meine Punkte.
Google doch mal rum, wieviele Leute sich (u.a. in diversen Techblogs) darüber aufregen.
Noch ist das optional, aber ich glaube nicht daran, dass das für immer so bleibt. MS zieht ja mit WinRT genauso einen WalledGarden hoch wie Apple mit iOS, da passt das nunmal wunderbar ins Bild.
Und ernsthaft, wovor soll dich das schützen, wenn die App an sich eigentlich clean ist, dann aber einen ausnutzbaren Bug aufweist und Apple bekanntlich alles andere als Highspeed ist in Sachen Bugfix?
Das ist genauso Snakeoil wie AV-Programme und Personal Firewalls, jedem logisch denkenden müßte klar werden, dass die Dinger im Zweifel nicht helfen, sondern in aller Regel immer mehr Ärger verursachen.
@Mike: zerr mal nicht meine Aussagen in falsche Richtungen. Solange etwas OPTIONAL ist, schreibe ich, dass das Deaktivieren nicht ratsam ist. Wenn etwas wie bei iOS eh nicht geht, dann hätte ich ja hier nix schreiben können. Im übrigen schrieb ich hier mal, wie man für Einzelprogs unter Win das UAC deaktiviert. Da schreit keiner.
Ich WÜRDE schreien, aber: man kanns ja eben ausschalten… 😛
@caschy, dann sag mir doch bitte mal ein Beispiel, wie und vor was einen das nun schützen können soll?
Das kann keine Bugs in Flash oder Java verhindern, Bufferoverflows u.ä. wird’s regelmäßig geben, etc. Das Stichwort für Infektionen heutzutage lautet doch Driveby und eben dagegen kann es im Zweifel null und gar nicht schützen.
Es gibt auch genügend (bekannte) Developer, die ihre Programme aus dem Appstore zurückgezogen haben, eben weil Apple aktiv vieles verhindert; darunter auch viel sinnvolles.
Der Laie wird sich erst wundern, warum er dies und das nicht machen kann, obwohl es z.B. eine legitimie Freeware ist, dann wird er googlen oder Freunde fragen und dann wird’s ausgeschaltet, also wieder alles für die Katz.
Was die Menschen brauchen ist ein Sicherheitskonzept und Aufklärung, nicht so bruchstückhaftes Zeug.
Hab’s jetzt an vier verschiedenen unsignierten Programmen versucht – funktioniert leider nicht. Schade … :=(.
@Mike, die Sache hat (wie Vieles) leider zwei Seiten. Einerseits finde ich die Tendenz, nur noch signierte Software auf die Systeme zu lassen, extrem gefährlich, da ich selbst Entwickler (Windows) bin. Wenn jemanden also meine Nase nicht passt, bin ich kurzerhand draußen.
Andererseits führt wohl kein Weg dran vorbei, um den Wildwuchs wieder etwas einzudämmen. Es ist doch hirnrissig, permanent ein Überwachungssystem im Hintergrund laufen zu lassen (und somit die Performance herunter zu ziehen), anstatt gleich die Ursache (Installation) zu beseitigen. Das geht halt nur, indem der Installations- und Updateprozess überwacht wird.
Was passiert, wenn dem nicht so ist, sieht man gegenwärtig bei Windows. Man denkt, mit einem Antivieren-Programm, der Firewall und hinter einem Router ist man halbwegs sicher. Weit gefehlt. Es sind nicht die offenen Ports, die das Problem darstellen. Sofern eine Verbindung erst einmal erstellt ist, ist es vollkommen egal, ob dieses von Innen oder Außen (nur Letzteres wird standardmäßig geblockt) geschehen ist und so ziemlich jedes Mini-Tool, welches die sinnvoll erscheinende Option „automatisch auf Updates prüfen“ enthält, baut beim Systemstart eine Socket auf. Da brauch es keiner großen Sicherheitslücke, um gemächlich Stück für Stück ein paar Bytes zu ziehen und dank .NET kann man diese dann final just in time kompilieren und ausführen, ohne dass der Virenscanner auch nur zuckt.
Dafür bräuchte man aber ein (böswilliges) Programm, welches der User erst einmal installiert. Eine Hürde, aber keine unlösbare. Mittlerweile finden sich immer mehr Download-Portale, die für die Downloads extra Sub-Domains (z.B. mozilla.xxx.com) anlegen, so dass man zweimal hinschauen muss, ob man wirklich von der Herstellereite herunterlädt. Ein falscher Blick und man erhält ein MSI, welches zwar das gewünschte Programm, aber halt auch noch allen möglichen Schrott mit installiert. Ein MSI zu öffnen und um eine DLL zu ergänzen, ist mit ganz offiziellen Tools wie Install Shield ein Kinderspiel. Wenn man dann noch weiß, dass man unter Windows mittels eines Registry-Eintrags DLLs angeben kann, die beim Starten eines Prozesses zusätzlich mit geladen werden sollen (ursprünglich mal für AddIns etc. gedacht), welchen man ebenfalls im MSI hinterlegt, hat man eigentlich alles zusammen, um selbst ein an sich „grünes“ Programm entsprechend zu präparieren.
Sicherlich ziemlich weit hergeholt, aber dennoch ohne große Hacker-Kenntnisse möglich. Es sollte auch nur verdeutlichen, dass die Probleme, um ein System wirklich sicher zu machen, teilweise ganz woanders liegen. Es ergibt daher schon einen Sinn, dass ein Prozess die Updates überprüft und den Pactketinhalt überwacht und nicht jedes x-beliebige App auf Verdacht eine Socket nach Hause aufmacht und nach belieben Binaries nachlädt. Den unbedarften User schützt es jedenfalls schon vor der ein oder anderen Attacke, auch wenn das nicht alle erdenklichen Szenarien ausschließt. Das soll es auch nicht.
Auf meinem Mac habe ich leider keine STRG Taste auf der Tastatur. Sorry