Remote-Administration unter OS X El Capitan

Apples erstes Software-Update für El Capitan, Version 10.11.1 hatte es in sich für Admins und Support-Mitarbeiter. Liest man sich die Informationen zum Sicherheitsinhalt durch, die Apple hier bereitgestellt hat (https://support.apple.com/de-de/HT205375), steht dort unter dem letzten Punkt:

SecurityAgent
Verfügbar für: OS X El Capitan 10.11
Auswirkung: Ein Schadprogramm kann programmatisch Aufforderungen der Schlüsselbundverwaltung steuern
Beschreibung: Es bestand eine Methode für Programme, bei Schlüsselbund-Aufforderungen synthetische Klicks zu erzeugen. Dieses Problem wurde behoben, indem synthetische Klicks für Fenster der Schlüsselbundverwaltung deaktiviert wurden.
CVE-ID
CVE-2015-5943

Schön und gut, sollte man meinen, Apple hat also eine weitere Schwachstelle ausgeräumt. Konkret ging es darum, dass Schadsoftware bekannt geworden war, die die genaue Position von Dialogfeldern auf dem Computerbildschirm ausfindig machen und selbst betätigen konnte, also z.B. selbständig auf ‚OK‘ klicken.

Apple hat diese Lücke in OS X 10.11.1 mit Fokus auf Warnmeldungen des Schlüsselbundes geschlossen, ist allerdings möglicherweise über das Ziel hinausgeschossen: Die Schlüsselbundverwaltung erlaubt seither nur noch Eingaben von verifizierten Eingabegeräten. Ein per Remote-Sitzung mit Apple Remote Desktop, Bildschirmfreigabe oder TeamViewer verbundener Anwender (typischerweise ein Administrator oder Support-Mitarbeiter) zählt nicht dazu. An einem Mac mit OS X 10.11.1 werden sämtliche entfernte Eingaben in Schlüsselbund-Dialogfenstern oder auch in der Schlüsselbundverwaltung ignoriert! Übrigens selbst dann, wenn ein Anwender lokal vor dem Rechner sitzt und auf Anweisung des remote zugeschalteten Support-Mitarbeiters auf das Feld klicken will. Im System.log erscheint dann folgende Fehlermeldung:

SecurityAgent: Ignoring User action since the dialog has received events from an untrusted source

ARDCautionWie Apple sich zukünftig die Administration eines Macs mit OS X 10.11.1 in einer entfernten Co-Location ohne physikalischen Zugriff vorstellt, ist mir schleierhaft.

Referenzen:

https://discussions.apple.com/thread/7305746?start=0&tstart=0

Update: Mittlerweile hat Apple das Problem gelöst.

El Capitan und Software Update Server

Dieser Artikel ist nicht mehr aktuell, das beschriebene Problem wurde zwischenzeitlich durch ein Software-Update von Apple behoben.

Man kann noch so viel testen und mit Beta-Versionen arbeiten, manche Probleme werden einfach erst „in freier Wildbahn“ entdeckt. So geschehen mit Apples neuester Betriebssystemversion OS X 10.11 El Capitan und der neuen Server-Version 5.
Ist am Server der Caching-Dienst sowie der Software-Aktualisierungsdienst aktiviert, bekommen Clients im lokalen Netzwerk (die auf den Software-Aktualisierungsserver eingestellt sind) die verfügbaren Software-Updates zwar noch angezeigt, aber wenn diese installiert werden sollen, bricht der Ladevorgang bei 0 KB ab.

Im System-Log erscheint zeitgleich folgende Fehlermeldung:

Oct 27 20:39:24 xserve AssetCache[93595]: #7sadM4t2Eeo7 Request by "Softwareaktualisierung" for http://192.168.0.111:55399/content/downloads/43/63/zzzz031-36002/5cnamdr2ij90oyafgyjlcwcyrvzly6j71r/CoreFP.pkg?source=xserve.example.de%3A8088 denied because the source is not whitelisted

Offenbar hat Apple irgendwo eine statische Liste vertrauter Domains fest hinterlegt. Der lokale Software-Aktualisierungsserver ist dort natürlich nicht hinterlegt und deshalb wird das Update für den Client nicht freigegeben.

Man beachte, dass der Prozess AssetCache das Update nicht freigibt. Das bedeutet, dass der Caching-Server die Finger im Spiel hat. Da ich weder in den Config-Dateien noch in den Serveradmin-Settings im Terminal eine Möglichkeit gefunden habe, den Server der Whitelist hinzuzufügen, gibt es derzeit für mich nur eine Möglichkeit, den Software Update Server mit Server 5 und El Capitan zu nutzen: indem man den Caching-Dienst ausschaltet.

SUS-Server5Mit OS X 10.11.1 und Server 5.0.15 ist das Problem übrigens nicht nicht behoben. Wir warten …

Update

Mit OS X 10.11.2 gehört der Fehler der Vergangenheit an. Software Update Server und Caching Server können also wieder parallel benutzt werden.

Wer mehr über die Hintergründe und über andere Workarounds zum Problem erfahren möchte, lese hier weiter: https://onemoreadmin.wordpress.com/2015/10/21/the-evil-triangle-el-capitan-sus-and-caching/

TRIM in macOS aktivieren

SSD-Gehäuse

Seit macOS 10.10 Yosemite ist es möglich, den TRIM-Befehl auf nachträglich installierten SSDs  zu aktivieren (um genau zu sein: seit OS X 10.10.4, das am 30. Juni 2015 veröffentlicht wurde). Dieser war bislang nur auf von Apple gelieferten SSDs verfügbar. Folgender Terminal-Befehl ist nötig, um TRIM zu aktivieren:

sudo trimforce enable

Daraufhin erfolgt folgende Warnmeldung, die man bestätigen muss. Danach startet das System neu und TRIM ist aktiv.

IMPORTANT NOTICE:  This tool force-enables TRIM for all relevant attached
devices, even though such devices may not have been validated for data
integrity while using TRIM.  Use of this tool to enable TRIM may result in
unintended data loss or data corruption.  It should not be used in a commercial
operating environment or with important data. Before using this tool, you
should back up all of your data and regularly back up data while TRIM is
enabled.  This tool is provided on an “as is” basis. APPLE MAKES NO WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING WITHOUT LIMITATION THE IMPLIED WARRANTIES OF
NON-INFRINGEMENT, MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE,
REGARDING THIS TOOL OR ITS USE ALONE OR IN COMBINATION WITH YOUR DEVICES,
SYSTEMS, OR SERVICES. BY USING THIS TOOL TO ENABLE TRIM, YOU AGREE THAT, TO THE
EXTENT PERMITTED BY APPLICABLE LAW, USE OF THE TOOL IS AT YOUR SOLE RISK AND
THAT THE ENTIRE RISK AS TO SATISFACTORY QUALITY, PERFORMANCE, ACCURACY AND
EFFORT IS WITH YOU.
Are you sure you wish to proceed (y/N)? y
Your system will immediately reboot when this is complete.
Is this OK (y/N)? y
Enabling TRIM…
.
.
Operation succeeded. Your system will reboot momentarily, please wait…

Zugriff auf entfernte CD/DVD aktivieren

Entfernte CD/DVD
Finder-Seitenleiste

Als die ersten Macs ohne optisches Laufwerk auf den Markt kamen – etwa 2008 mit dem Macbook Air – führte Apple eine neue Funktion namens Entfernte CD/DVD ein, um diesen Geräten eine einfache Möglichkeit zu geben, das optische Laufwerk eines anderen Macs oder PCs im lokalen Netzwerk zu verwenden.

Mittlerweile gibt es überhaupt nur noch ein Gerät, nämlich das kleine Einsteiger-Macbook Pro mit 13,3″ Display, das über ein optisches Laufwerk verfügt.

Viele User, die ihre Macs über mehrere Jahre benutzen und sich nicht alle zwei Jahre ein neues Modell zulegen, haben ihrerseits Speicher aufgerüstet, wofür so mancher DVD-Brenner einer SSD weichen musste. So auch bei meinem Macbook Pro, Modell Anfang 2011.

Was also, wenn man mit einem so umgerüsteten Modell mal kein externes USB-Laufwerk zur Hand hat und die Funktion Externe CD/DVD gern nutzen möchte? Dann stellt man erstaunt fest, dass man sie nicht finden kann. Eigentlich sollte sie in der Seitenleiste des Finders zu sehen sein, aber Apple hat die Funktion auf Macs eingeschränkt, die von Werk aus ohne optisches Laufwerk ausgeliefert werden. Was tun?

Wie für so vieles gibt es auch hier einen Terminal-Befehl, der Abhilfe schafft. Man öffne dazu das Programm Terminal im Ordner Dienstprogramme und gebe folgende zwei Befehle ein, jeweils mit Enter-Taste bestätigt:

defaults write com.apple.NetworkBrowser EnableODiskBrowsing -bool true
defaults write com.apple.NetworkBrowser ODSSupported -bool true

Danach den Mac neu starten und anschließend gibt es den vermissten Menüpunkt in der Finder-Seitenleiste.

WordPress Cookie Hinweis von Real Cookie Banner