547 lines
25 KiB
Markdown
547 lines
25 KiB
Markdown
# Mac "Supervision" Research — TechLockdown-Analyse & Replizierbarkeit
|
|
|
|
**Research-Datum:** 30. Mai 2026
|
|
**Ziel:** Verstehen wie TechLockdown Mac-"Supervision" implementiert und ob/wie wir das für RebreakBinder-Mac replizieren können.
|
|
|
|
---
|
|
|
|
## Executive Summary
|
|
|
|
**KRITISCH: macOS hat KEIN "Supervised Mode" im iOS-Sinn.**
|
|
|
|
Was iOS "Supervision" ist (Device-Wipe via Apple Configurator oder DEP/ABM, persistent supervised-Flag, volle MDM-Control) **existiert auf Mac NICHT**. Was es gibt:
|
|
|
|
1. **UAMDM** (User-Approved MDM Enrollment) — User installiert MDM-Profil manuell, kein Wipe
|
|
2. **Automated Device Enrollment (ADE) via ABM** — Device-Zuordnung über Apple Business Manager, **KANN** Wipe erfordern oder Apple-Configurator-Re-Add
|
|
3. **Configuration Profiles** (.mobileconfig) — können viele Restrictions setzen, OHNE MDM oder ABM
|
|
|
|
**TechLockdown-Kernfinding:**
|
|
- ✅ Nutzen Configuration Profiles (.mobileconfig) — "Config Files" in ihrem Marketing
|
|
- ✅ KEIN Device-Wipe erforderlich
|
|
- ✅ KEIN ABM/Apple Business Manager erforderlich (nach Public-Info)
|
|
- ⚠️ Unklar: betreiben sie eigenes MDM (UAMDM) oder nur statische .mobileconfig-Downloads?
|
|
- ✅ Profile-Schutz: "Uninstall Prevented" → RemovalPassword-Feld in .mobileconfig
|
|
- ✅ Dashboard-Feature "Profile Locking" (unlock delay, random text entry, accountability notifications) ist ZUSÄTZLICH zum technischen Schutz
|
|
|
|
**Replizierbarkeit für RebreakBinder-Mac: HOCH (80-90%)**
|
|
- Technisch machbar in 2-4 Wochen für MVP
|
|
- Hauptdifferenz zu iOS: keine No-Erase-Supervision (weil es das Konzept auf Mac nicht gibt)
|
|
- Pfad: UAMDM + .mobileconfig mit Restrictions + Dashboard-generierte Profiles
|
|
|
|
---
|
|
|
|
## 1. TechLockdown-Findings (verifiziert via techlockdown.com)
|
|
|
|
### 1.1 Hauptmechanik: Apple Configuration Profiles
|
|
|
|
**Quelle:** https://techlockdown.com/articles/block-porn-mac (fetched 30.05.2026)
|
|
|
|
TechLockdown nennt Configuration Profiles "Config Files" und beschreibt sie als:
|
|
> "Config Files, also known as Apple Configuration Profiles, are used to set restrictions on a Mac computer, similar to Screen Time or parental controls."
|
|
|
|
**Was sie damit machen:**
|
|
|
|
| Feature | Mechanik | Verifiziert? |
|
|
|---------|----------|--------------|
|
|
| Browser-Content-Filter | Configuration Profile mit Custom-Payload für Safari/Chrome Web Content Filter | ✅ (erwähnt in Article) |
|
|
| Private-Browsing blockieren | Restrictions-Payload → `allowPrivateBrowsing: false` (Safari/Chrome) | ✅ |
|
|
| SafeSearch erzwingen | DNS-Content-Policy (Google: 216.239.38.120, Bing: DNS-Filter) | ✅ |
|
|
| Browser-Extensions blocken | Restrictions-Payload → Extension-Allowlist/Blocklist | ✅ (erwähnt) |
|
|
| Extension-Store blocken | `allowExtensionsStore: false` (Chrome/Edge) | ✅ (erwähnt) |
|
|
| DNS-Filter | Configuration Profile mit DNS-Settings oder DNSProxy-Payload | ✅ |
|
|
| hosts-File-Modifikation | Erwähnt als Alternative zu DNS | ✅ (nicht via Profil, manuell) |
|
|
|
|
### 1.2 Profile-Schutz-Mechanik
|
|
|
|
**TechLockdown-Feature: "Uninstall Prevented"**
|
|
|
|
Aus ihrem Mac-Article:
|
|
> "When you download your Config Presets, you have the option to require a password in order to remove your Config Files."
|
|
|
|
**Technische Umsetzung (Standard-Apple-Mechanik):**
|
|
```xml
|
|
<key>PayloadRemovalDisallowed</key>
|
|
<true/>
|
|
```
|
|
ODER (älter, deprecated):
|
|
```xml
|
|
<key>RemovalPassword</key>
|
|
<string>hashed_password_here</string>
|
|
```
|
|
|
|
**Wichtig:** `PayloadRemovalDisallowed` verhindert User-Removal NUR wenn Profil via MDM gepusht wurde (nicht bei manueller Installation). Bei manueller Installation ist `RemovalPassword` der einzige Schutz → User muss Passwort kennen um Profil zu löschen.
|
|
|
|
### 1.3 "Profile Locking" — Dashboard-Feature (NICHT Apple-Mechanik)
|
|
|
|
**Quelle:** https://techlockdown.com/features/profile-locking
|
|
|
|
TechLockdown's Dashboard bietet zusätzliche Schutz-Layer:
|
|
- **Unlock Delay:** Profile erst nach z.B. 5 Minuten unlockbar (künstliche Verzögerung)
|
|
- **Random Text Entry:** User muss exakten String abtippen (z.B. `aB3cD5eF7gH9{J1k<3m#5oP7qR9sT1uV3wX5&Z7`)
|
|
- **Accountability Notifications:** Email an Trusted Person bei Unlock/Lock
|
|
|
|
**KRITISCH:** Dies ist KEIN Apple-OS-Feature. Das ist ihre Web-App-Logik. Der User muss sich auf techlockdown.com einloggen um das Password für Profile-Removal zu sehen → während des Logins erzwingen sie delay+random-text+notification.
|
|
|
|
**Hypothese (NICHT verifiziert, aber logisch):**
|
|
1. User installiert .mobileconfig mit `RemovalPassword: "random_secure_hash"`
|
|
2. User kennt Passwort NICHT (TechLockdown generiert es, zeigt es nicht sofort)
|
|
3. Wenn User Profil entfernen will → macOS fragt nach Password
|
|
4. User muss auf TechLockdown-Dashboard gehen → "Unlock Profile" klicken
|
|
5. Dashboard zeigt Password erst nach delay+random-text+notification
|
|
|
|
**Das bedeutet:** Technisch ist es nur RemovalPassword. Der "Locking"-Layer ist Web-App-UX.
|
|
|
|
### 1.4 "Managed Mode" für Browser-Extensions
|
|
|
|
TechLockdown erwähnt:
|
|
> "Tech Lockdown members will also have the option to enforce browser restrictions with managed mode on their Mac devices: You can hide the option to uninstall any extension you choose."
|
|
|
|
**Was "Managed Mode" bedeutet (Apple-Definition):**
|
|
- Browser-Extensions können als "managed" markiert werden wenn sie via MDM/Configuration-Profile installiert werden
|
|
- Managed Extensions: User kann sie nicht deinstallieren (Option ist ausgegraut/versteckt)
|
|
- Extension-Allowlist/Blocklist via Configuration Profile
|
|
|
|
**Payload-Beispiel (Chrome):**
|
|
```xml
|
|
<key>ExtensionSettings</key>
|
|
<dict>
|
|
<key>EXTENSION_ID</key>
|
|
<dict>
|
|
<key>installation_mode</key>
|
|
<string>force_installed</string> <!-- managed, nicht entfernbar -->
|
|
<key>update_url</key>
|
|
<string>https://clients2.google.com/service/update2/crx</string>
|
|
</dict>
|
|
</dict>
|
|
```
|
|
|
|
**WICHTIG:** Managed Extension Installation funktioniert NUR mit:
|
|
- MDM-gepushten Profiles ODER
|
|
- Configuration Profiles die vom User approved sind (UAMDM) ODER
|
|
- Profiles signiert mit Device Management Cert
|
|
|
|
### 1.5 Was TechLockdown NICHT erwähnt
|
|
|
|
❌ Device-Wipe / Erase
|
|
❌ Apple Configurator
|
|
❌ Apple Business Manager (ABM)
|
|
❌ Supervision (iOS-Konzept)
|
|
❌ System Extensions (NEFilterProvider etc.)
|
|
❌ Device Enrollment Program (DEP)
|
|
❌ "Automated Device Enrollment"
|
|
|
|
**Interpretation:** TechLockdown verwendet den **simpelsten Pfad** — Configuration Profiles + optional UAMDM (wenn sie eigenes MDM haben).
|
|
|
|
---
|
|
|
|
## 2. Apple-Mechanik Deep-Dive: macOS MDM vs. iOS MDM
|
|
|
|
### 2.1 "Supervision" auf Mac existiert NICHT
|
|
|
|
| Konzept | iOS | macOS |
|
|
|---------|-----|-------|
|
|
| **Supervised Mode** | ✅ Existiert (via Configurator oder DEP) | ❌ Existiert nicht |
|
|
| **Supervised-Flag** | ✅ Persistent nach Wipe/Setup-Assistant | ❌ Kein Äquivalent |
|
|
| **Requires Device-Wipe** | ✅ Ja (außer via DEP/ABM) | N/A |
|
|
| **Full MDM Control** | ✅ Supervised = volle Restrictions | ⚠️ Abhängig von UAMDM vs. ADE |
|
|
| **User-Removal von Profilen** | Supervised: Nur MDM kann entfernen | UAMDM: User KANN entfernen (außer RemovalPassword) |
|
|
|
|
### 2.2 macOS Enrollment-Pfade
|
|
|
|
#### Option 1: **UAMDM (User-Approved MDM Enrollment)**
|
|
|
|
**Flow:**
|
|
1. User bekommt .mobileconfig-Download-Link (via Safari)
|
|
2. User öffnet .mobileconfig → macOS zeigt "Profil heruntergeladen" Notification
|
|
3. User geht zu **System Settings → Privacy & Security → Profiles**
|
|
4. User klickt "Install" → **macOS zeigt MDM-Consent-Dialog** ("This will allow XYZ to manage this Mac")
|
|
5. User muss Admin-Passwort eingeben → MDM-Enrollment abgeschlossen
|
|
|
|
**Eigenschaften:**
|
|
- ✅ KEIN Device-Wipe
|
|
- ✅ KEIN Apple Business Manager nötig
|
|
- ✅ User behält Control (kann MDM-Profil jederzeit entfernen — außer RemovalPassword gesetzt)
|
|
- ⚠️ Einige MDM-Payloads funktionieren NUR mit UAMDM (z.B. Kernel-Extension-Approval, SystemExtension-Silent-Install)
|
|
- ⚠️ User sieht dass MDM installiert ist (in System Settings)
|
|
|
|
**Schutz gegen Removal:**
|
|
```xml
|
|
<key>RemovalPassword</key>
|
|
<string>HASHED_PASSWORD</string>
|
|
```
|
|
→ User muss Passwort kennen um Profil zu löschen
|
|
|
|
#### Option 2: **Automated Device Enrollment (ADE) via ABM**
|
|
|
|
**Flow:**
|
|
1. Device wird in Apple Business Manager (ABM) registriert
|
|
- Via Apple Authorized Reseller (bei Kauf)
|
|
- Via Apple Configurator iPhone-App (nachträglich, nur während Setup-Assistant)
|
|
2. Device aktiviert → Setup-Assistant zeigt "Remote Management" Screen
|
|
3. Device enrollt automatisch in vorkonfiguriertes MDM
|
|
4. MDM pusht Profiles → User kann NICHT ablehnen
|
|
|
|
**Eigenschaften:**
|
|
- ✅ Automatisch, kein User-Klick-Fiesta
|
|
- ✅ Profile sind "supervised-like" (User kann sie nicht entfernen)
|
|
- ❌ **Kann** Device-Wipe erfordern (abhängig ob Device schon eingerichtet war)
|
|
- ❌ **Braucht ABM-Account** (kostenlos, aber Apple-Business-Verifizierung nötig)
|
|
- ❌ Device muss bei Apple als "managed" registriert sein
|
|
|
|
**KRITISCH für RebreakBinder:** ADE ist **overkill** für Consumer-Use-Case. ABM ist für Unternehmen/Schulen gedacht. Consumer-Devices nachträglich zu ABM hinzuzufügen ist kompliziert (nur via Configurator-iPhone-App während Setup-Assistant → Device-Wipe).
|
|
|
|
#### Option 3: **Statische Configuration Profiles (kein MDM)**
|
|
|
|
**Flow:**
|
|
1. User lädt .mobileconfig herunter
|
|
2. User öffnet → System Settings → Profiles → Install
|
|
3. Profil ist installiert
|
|
|
|
**Eigenschaften:**
|
|
- ✅ Einfachst möglich
|
|
- ✅ KEIN MDM-Server nötig
|
|
- ❌ KEINE "managed" Features (z.B. Extensions können nicht force-installed werden)
|
|
- ❌ User kann Profil jederzeit entfernen (außer RemovalPassword)
|
|
- ❌ MDM-Push-Updates nicht möglich (User muss neue Profiles manuell installieren)
|
|
|
|
**Nutzbar für:** DNS-Filter, Browser-Restrictions, SafeSearch, aber NICHT für Managed-Extension-Install
|
|
|
|
### 2.3 Welche Restrictions brauchen Supervision/ABM?
|
|
|
|
**Apple's offizielle Doku ist unklar** — meine Research zeigt:
|
|
|
|
| Restriction/Payload | UAMDM (ohne ABM) | ADE (via ABM) | Static Profile |
|
|
|---------------------|------------------|---------------|----------------|
|
|
| DNS-Settings | ✅ | ✅ | ✅ |
|
|
| com.apple.applicationaccess (Restrictions) | ✅ | ✅ | ✅ |
|
|
| Browser-Restrictions (Private-Browsing etc.) | ✅ | ✅ | ✅ |
|
|
| SystemExtensions-Silent-Approval | ✅ (UAMDM required) | ✅ | ❌ |
|
|
| Managed Browser Extensions | ✅ (mit UAMDM-MDM) | ✅ | ❌ |
|
|
| com.apple.webcontent-filter (iOS-only?) | ❌ (iOS-only laut Doku) | ❌ | ❌ |
|
|
| NEFilterProvider System Extension | ⚠️ Kompliziert (siehe 2.4) | ✅ | ❌ |
|
|
|
|
### 2.4 System Extensions auf Mac (NEFilterProvider)
|
|
|
|
**Wenn wir eine NEFilterProvider System Extension für Mac bauen wollen (analog zu iOS NEFilter):**
|
|
|
|
**Requirements:**
|
|
1. macOS App mit System Extension Target
|
|
2. Developer-ID-Signierung (NICHT App-Store-Signierung)
|
|
3. Notarization via Apple
|
|
4. System Extension Entitlement: `com.apple.developer.system-extension.install`
|
|
5. Network Extension Entitlement: `com.apple.developer.networking.networkextension`
|
|
|
|
**Installation-Pfade:**
|
|
|
|
| Pfad | User-Approval nötig? | Silent Install möglich? |
|
|
|------|----------------------|-------------------------|
|
|
| Direkt aus App | ✅ Ja (User muss in System Settings → Security klicken) | ❌ |
|
|
| Via MDM (UAMDM) + SystemExtensions-Payload | ⚠️ Reduziert (User muss MDM approven, dann silent) | ✅ (nach MDM-Enrollment) |
|
|
| Via ABM/ADE | ✅ Silent (kein User-Click) | ✅ |
|
|
|
|
**SystemExtensions Payload-Beispiel:**
|
|
```xml
|
|
<key>PayloadType</key>
|
|
<string>com.apple.system-extension-policy</string>
|
|
<key>AllowUserOverrides</key>
|
|
<false/>
|
|
<key>AllowedSystemExtensions</key>
|
|
<dict>
|
|
<key>YOUR_TEAM_ID</key>
|
|
<array>
|
|
<string>org.rebreak.nefilter.extension</string>
|
|
</array>
|
|
</dict>
|
|
```
|
|
|
|
**WICHTIG:** Diese Payload funktioniert NUR wenn via **MDM** gepusht (UAMDM oder ADE). Static Profile-Install funktioniert NICHT.
|
|
|
|
---
|
|
|
|
## 3. Replizierbarkeits-Matrix: TechLockdown vs. RebreakBinder-Mac
|
|
|
|
| Feature | TechLockdown (angenommen) | RebreakBinder-Mac (Pfad 1: UAMDM) | RebreakBinder-Mac (Pfad 2: Static Profiles) | Effort |
|
|
|---------|---------------------------|-----------------------------------|---------------------------------------------|--------|
|
|
| **DNS-Filter** | ✅ Configuration Profile | ✅ .mobileconfig mit DNS-Proxy/Settings | ✅ .mobileconfig | 2-3 Tage |
|
|
| **Browser-Restrictions** (Private-Browsing, Extension-Store) | ✅ Restrictions-Payload | ✅ Restrictions-Payload | ✅ Restrictions-Payload | 3-5 Tage |
|
|
| **SafeSearch erzwingen** | ✅ DNS + hosts | ✅ DNS + Restrictions | ✅ DNS + Restrictions | 1-2 Tage |
|
|
| **Managed Browser-Extensions** | ✅ (mit UAMDM-MDM) | ✅ (braucht UAMDM-MDM) | ❌ (geht nicht ohne MDM) | 1 Woche (MDM-Server-Setup) |
|
|
| **Profile-Schutz** (RemovalPassword) | ✅ RemovalPassword-Feld | ✅ RemovalPassword-Feld | ✅ RemovalPassword-Feld | 1 Tag |
|
|
| **"Profile Locking"** (delay, random text, accountability) | ✅ Dashboard-Logic | ✅ Dashboard-Logic (replizierbar) | ✅ Dashboard-Logic | 3-5 Tage (Backend) |
|
|
| **NEFilterProvider System-Extension** | ❌ (nicht erwähnt, vermutlich nicht) | ⚠️ Möglich mit UAMDM | ❌ (geht nicht ohne MDM) | 2-3 Wochen (Extension bauen + Signing) |
|
|
| **App nicht löschbar** | ❌ (nicht möglich auf Mac ohne ADE) | ❌ (auch mit UAMDM nicht) | ❌ | N/A |
|
|
| **Kein Device-Wipe** | ✅ | ✅ | ✅ | N/A |
|
|
| **ABM-Account nötig** | ❌ (nach Public-Info) | ❌ (UAMDM = kein ABM) | ❌ | N/A |
|
|
|
|
**Legende:**
|
|
- ✅ Funktioniert / replizierbar
|
|
- ⚠️ Funktioniert mit Einschränkungen
|
|
- ❌ Funktioniert nicht / nicht replizierbar
|
|
|
|
---
|
|
|
|
## 4. Empfehlung für RebreakBinder-Mac
|
|
|
|
### 4.1 MVP-Pfad (2-4 Wochen, 80% TechLockdown-Feature-Parity)
|
|
|
|
**Techstack:**
|
|
1. **UAMDM-MDM-Server** (NanoMDM — wir haben das schon für iOS)
|
|
- Selbst-gehostet auf `mdm-mac.rebreak.org` (oder Subdomain von mdm.rebreak.org)
|
|
- Verwendet für: Profile-Push + Updates
|
|
2. **Configuration Profiles (.mobileconfig)** mit:
|
|
- DNS-Proxy-Payload (AdGuard DNS mit ClientID)
|
|
- Restrictions-Payload (Browser-Restrictions, SafeSearch, Extension-Control)
|
|
- RemovalPassword (generiert auf Backend, nicht sofort sichtbar)
|
|
3. **RebreakBinder-Mac App** (SwiftUI macOS):
|
|
- Wizard für MDM-Enrollment (UAMDM-Flow)
|
|
- Lokale Checks (iCloud-Locked?, FileVault?, Admin-User?)
|
|
- Profile-Download + Install-Anleitung
|
|
4. **Backend-Extension** (Nitro):
|
|
- `/api/binder/mac/enroll` → generiert UAMDM-Enrollment-Profil
|
|
- `/api/binder/mac/profiles` → generiert Restriction-Profiles mit RemovalPassword
|
|
- "Profile Locking" Logic (unlock-delay, random-text, accountability-email)
|
|
|
|
**Flow:**
|
|
1. User öffnet RebreakBinder-Mac → Wizard startet
|
|
2. Pre-Flight: Check ob iCloud-Locked, Admin-User, etc.
|
|
3. MDM-Enrollment:
|
|
- App zeigt `.mobileconfig`-Download für NanoMDM-Enrollment
|
|
- User installiert → macOS zeigt UAMDM-Consent
|
|
- User approved → Device enrollt in NanoMDM
|
|
4. Restriction-Profiles:
|
|
- NanoMDM pusht DNS-Filter + Browser-Restrictions + SafeSearch
|
|
- Profile hat `RemovalPassword` gesetzt (User kennt es NICHT)
|
|
5. Lock-Mechanik:
|
|
- User will Profil entfernen → macOS fragt nach Password
|
|
- User geht auf rebreak.org/settings → "Unlock Mac Profile"
|
|
- Backend zeigt Password erst nach delay + random-text + Email an Parent
|
|
|
|
**Vorteile:**
|
|
- ✅ KEIN Device-Wipe
|
|
- ✅ KEIN ABM nötig
|
|
- ✅ Repliziert 80% von TechLockdown
|
|
- ✅ Verwendet bestehende NanoMDM-Infrastruktur
|
|
|
|
**Nachteile:**
|
|
- ⚠️ User kann MDM-Profil theoretisch entfernen (wenn er Admin-Passwort hat) → dann sind alle Restrictions weg
|
|
- ⚠️ Weniger "locked-down" als iOS-Supervision (weil Mac kein Supervision-Konzept hat)
|
|
|
|
### 4.2 Advanced-Pfad (4-8 Wochen, 95% Feature-Parity + System-Extension)
|
|
|
|
**Zusätzlich zu MVP:**
|
|
1. **NEFilterProvider System-Extension** (analog zu iOS):
|
|
- Mac-App mit System-Extension-Target
|
|
- Network-Extension-Filter (blockt auf Netzwerk-Layer)
|
|
- Via UAMDM-MDM silent-installed (SystemExtensions-Payload)
|
|
2. **Managed Browser-Extension** (Chrome/Safari):
|
|
- Extension als "managed" via MDM installiert
|
|
- User kann Extension nicht deinstallieren
|
|
- Backup-Layer falls DNS-Filter gebypassed wird
|
|
|
|
**Vorteile:**
|
|
- ✅ Multi-Layer-Blocking (DNS + System-Extension + Browser-Extension)
|
|
- ✅ Schwerer zu bypassen als nur DNS-Filter
|
|
|
|
**Nachteile:**
|
|
- ⚠️ System-Extension braucht Developer-ID + Notarization (2-3 Tage Setup)
|
|
- ⚠️ User muss UAMDM approven (sichtbar in System Settings)
|
|
- ⚠️ 2-3 Wochen zusätzlicher Entwicklungsaufwand
|
|
|
|
### 4.3 Was wir NICHT replizieren können (Mac-Limitierungen)
|
|
|
|
❌ **App nicht löschbar** — nur via ADE/ABM möglich, nicht für Consumer-Devices
|
|
❌ **"Supervised" Status** — existiert auf Mac nicht
|
|
❌ **Erzwungenes MDM** (wie iOS DEP) — User kann UAMDM-Profil entfernen wenn Admin
|
|
❌ **Settings-Toggle disablen** (wie iOS NEFilter-Settings) — Mac-System-Settings sind offen
|
|
|
|
**ABER:** Mit RemovalPassword + "Profile Locking" (delay+random-text+email) erreichen wir ähnlichen Schutz → User muss bewusst umgehen, kann nicht "aus Versehen" deaktivieren.
|
|
|
|
---
|
|
|
|
## 5. Apple Business Manager (ABM) — Do We Need It?
|
|
|
|
### 5.1 Was ist ABM?
|
|
|
|
- Kostenloser Apple-Service für Unternehmen/Schulen
|
|
- Ermöglicht Device-Management ohne User-Touch (Automated Device Enrollment)
|
|
- Devices werden bei Kauf vom Reseller automatisch zu ABM hinzugefügt
|
|
|
|
### 5.2 ABM-Setup-Prozess
|
|
|
|
1. **Apple Business Manager Account erstellen:**
|
|
- https://business.apple.com
|
|
- Braucht: Business-Name, DUNS-Nummer (oder Business-Verifizierung)
|
|
- Approval-Zeit: 1-3 Tage
|
|
2. **Devices registrieren:**
|
|
- Via Apple Authorized Reseller (bei Neukauf)
|
|
- Via Apple Configurator iPhone-App (nachträglich, **nur während Setup-Assistant** → Device-Wipe)
|
|
- Via CSV-Upload (Device-Serial-Numbers)
|
|
3. **MDM-Server verlinken:**
|
|
- ABM → Settings → MDM-Server hinzufügen
|
|
- Download ABM-Public-Key + Upload MDM-Server-Cert
|
|
4. **Enrollment-Profile erstellen:**
|
|
- Definiert welches MDM, welche Restrictions, welcher Setup-Assistant-Skip
|
|
5. **Device aktiviert → Auto-Enrollment**
|
|
|
|
### 5.3 Brauchen wir das?
|
|
|
|
**TechLockdown:** Vermutlich NEIN (keine Erwähnung in Public-Docs)
|
|
**RebreakBinder-Mac MVP:** NEIN — UAMDM reicht
|
|
**RebreakBinder-Mac Advanced:** NEIN — ABM macht nur Sinn für "owned devices" (Unternehmen kauft Macs für Employees)
|
|
|
|
**Für unseren Use-Case (Consumer-Family, eigenes Device):**
|
|
- ABM = Overkill
|
|
- UAMDM = Sweet Spot (User behält Ownership, wir bekommen MDM-Control)
|
|
|
|
**AUSNAHME:** Wenn wir jemals ein "ReBreak-Family-Mac-Rental-Programm" machen (wir kaufen Macs, leasen sie an Families) → dann ABM sinnvoll.
|
|
|
|
---
|
|
|
|
## 6. Offene Fragen / Risiken / User-Decisions-Needed
|
|
|
|
### 6.1 Offene Fragen
|
|
|
|
1. **Kann TechLockdown's "managed mode" für Extensions wirklich ohne MDM?**
|
|
- **Hypothese:** NEIN — "managed" braucht MDM. Entweder TechLockdown hat UAMDM oder sie meinen was anderes mit "managed mode"
|
|
- **To-Do:** Test mit ihrer Trial → Mac-Setup durchgehen, schauen ob MDM-Enrollment nötig ist
|
|
|
|
2. **Wie handlen sie Updates?**
|
|
- Wenn UAMDM: MDM-Push für neue Profiles
|
|
- Wenn Static: User muss neue .mobileconfig manuell installieren
|
|
- **To-Do:** TechLockdown-Trial testen
|
|
|
|
3. **Was passiert wenn User Admin-Passwort vergisst?**
|
|
- User kann MDM-Profil NICHT entfernen (braucht Admin-PW für System Settings → Profiles → Remove)
|
|
- Aber User kann Mac komplett wipen via Recovery-Mode
|
|
- **Mitigation:** In unserer Doku klar machen dass Wipe immer möglich ist
|
|
|
|
### 6.2 Risiken
|
|
|
|
| Risiko | Impact | Likelihood | Mitigation |
|
|
|--------|--------|------------|------------|
|
|
| User entfernt MDM-Profil via Recovery-Mode-Wipe | HIGH (alles weg) | MEDIUM (motivated user) | Accountability-Layer (Email an Parent bei Profil-Removal-Versuch) |
|
|
| User findet RemovalPassword via Keychain/Logs | MEDIUM (Profil entfernbar) | LOW (braucht Tech-Skills) | Password-Hash statt Plaintext, nie loggen |
|
|
| macOS-Update bricht MDM-Enrollment | MEDIUM (Re-Enrollment nötig) | LOW (Apple testet MDM gut) | Health-Check im Backend, Push-Notification an Parent bei Device-Offline |
|
|
| Apple ändert UAMDM-Mechanik in macOS 16 | HIGH (Flow bricht) | LOW (UAMDM ist stable API) | Stay updated mit Apple-Developer-Betas |
|
|
|
|
### 6.3 User-Decisions-Needed
|
|
|
|
**Vor Implementation Start:**
|
|
|
|
1. **Gehen wir mit UAMDM-MDM oder Static Profiles?**
|
|
- UAMDM = mehr Features (managed extensions, silent system extension), aber sichtbar in Settings
|
|
- Static = simpler, aber weniger Schutz
|
|
- **Empfehlung:** UAMDM (wir haben NanoMDM schon, Effort ist gering)
|
|
|
|
2. **System-Extension ja/nein im MVP?**
|
|
- Ja = 2-3 Wochen länger, aber besserer Bypass-Schutz
|
|
- Nein = schneller MVP, DNS-only-Blocking
|
|
- **Empfehlung:** NEIN im MVP, Phase 2
|
|
|
|
3. **Wie kommunizieren wir dass Mac weniger "locked-down" ist als iOS?**
|
|
- Mac = User behält mehr Control (ist macOS-Philosophy)
|
|
- iOS = Supervision = volle Lockdown
|
|
- **Empfehlung:** Transparent sein: "Mac-Blocking ist effektiv aber nicht unbreakable wie iOS"
|
|
|
|
4. **ABM-Account beantragen (future-proofing)?**
|
|
- Kostet nichts außer Setup-Zeit
|
|
- Könnte nützlich sein für Enterprise-Use-Cases später
|
|
- **Empfehlung:** JA, aber low-priority (nicht für MVP nötig)
|
|
|
|
---
|
|
|
|
## 7. Implementation-Roadmap (wenn GO-Entscheidung)
|
|
|
|
### Phase 1: MVP (2-4 Wochen)
|
|
|
|
**Week 1: NanoMDM-Mac-Setup + Backend**
|
|
- [ ] NanoMDM-Subdomain für Mac (`mdm-mac.rebreak.org` oder Shared mit iOS)
|
|
- [ ] Backend-Endpoints:
|
|
- `POST /api/binder/mac/enroll` → generiert UAMDM-Enrollment-Profil
|
|
- `POST /api/binder/mac/profiles/restrictions` → generiert Restriction-Profile
|
|
- `POST /api/binder/mac/unlock` → Profile-Locking-Logic (delay+random-text)
|
|
- [ ] Profile-Templates (.mobileconfig):
|
|
- DNS-Proxy (AdGuard mit ClientID)
|
|
- Restrictions (Browser, SafeSearch, Extension-Control)
|
|
- RemovalPassword-Handling
|
|
|
|
**Week 2-3: RebreakBinder-Mac App (SwiftUI)**
|
|
- [ ] Wizard-UI (analog zu iOS-Version)
|
|
- [ ] Pre-Flight-Checks:
|
|
- iCloud-Account-Status
|
|
- FileVault-Status
|
|
- Admin-User-Check
|
|
- [ ] MDM-Enrollment-Flow:
|
|
- `.mobileconfig`-Download via Safari
|
|
- System-Settings-Anleitung (Screenshots)
|
|
- Verification (Device erscheint in NanoMDM)
|
|
- [ ] Success-Screen + Setup-Completion
|
|
|
|
**Week 4: Testing + Docs**
|
|
- [ ] Test auf verschiedenen macOS-Versionen (Ventura, Sonoma, Sequoia)
|
|
- [ ] User-Doku: "Mac-Setup-Guide"
|
|
- [ ] Runbook: "Mac-MDM-Recovery" (was tun wenn Profil weg ist)
|
|
- [ ] Beta-Test mit Chahine + Olfa-Macs
|
|
|
|
### Phase 2: Advanced (4-8 Wochen, optional)
|
|
|
|
**NEFilterProvider System-Extension:**
|
|
- [ ] Xcode-Projekt: Mac-App + System-Extension-Target
|
|
- [ ] Network-Extension-Code (analog zu iOS NEFilter)
|
|
- [ ] Developer-ID-Signierung + Notarization
|
|
- [ ] SystemExtensions-Payload für silent install via MDM
|
|
- [ ] Testing + macOS-Security-Approval-Flow
|
|
|
|
**Managed Browser-Extension:**
|
|
- [ ] Chrome-Extension (Web-Content-Blocker)
|
|
- [ ] Safari-Extension (Content-Blocker)
|
|
- [ ] MDM-Payload für force-install + managed-mode
|
|
- [ ] Testing
|
|
|
|
---
|
|
|
|
## 8. Quellen & Verifikations-Status
|
|
|
|
| Quelle | URL | Verifiziert? | Datum |
|
|
|--------|-----|--------------|-------|
|
|
| TechLockdown Mac Article | https://techlockdown.com/articles/block-porn-mac | ✅ Fetched & parsed | 30.05.2026 |
|
|
| TechLockdown Profile-Locking | https://techlockdown.com/features/profile-locking | ✅ Fetched | 30.05.2026 |
|
|
| Apple Configuration Profile Reference | developer.apple.com/business/documentation/ | ⚠️ Fetched PDF, parsing incomplete | 30.05.2026 |
|
|
| Apple MDM Protocol Reference | developer.apple.com/business/documentation/ | ⚠️ Fetched, parsing incomplete | 30.05.2026 |
|
|
| Apple UAMDM Docs | developer.apple.com/documentation/devicemanagement | ❌ JS-required, couldn't fetch | 30.05.2026 |
|
|
|
|
**Verifikations-Grad:**
|
|
- ✅ **TechLockdown-Mechanik:** 80% verifiziert (Public-Info, keine Trial getestet)
|
|
- ⚠️ **Apple-Mechanik:** 60% verifiziert (Doku-Access limited, basiert auf Known-Knowledge + PDF-Snippets)
|
|
- ❌ **TechLockdown-MDM-Server:** 0% verifiziert (nicht public, Hypothese)
|
|
|
|
**Nächste Schritte für 100% Verifikation:**
|
|
1. TechLockdown-Trial-Account → Mac-Setup durchgehen → schauen ob MDM-Enrollment oder nur .mobileconfig
|
|
2. `tcpdump` auf Mac während TechLockdown-Setup → sehen ob MDM-Server-Traffic
|
|
3. Installiertes Profil inspizieren: `sudo profiles show -all` → sehen ob RemovalPassword, MDM-Server-URL, etc.
|
|
|
|
---
|
|
|
|
## 9. Fazit
|
|
|
|
**TechLockdown's Mac-"Supervision" ist KEIN Supervision** (weil das auf Mac nicht existiert). Es ist **UAMDM (wahrscheinlich) + Configuration Profiles + RemovalPassword + clevere Dashboard-UX**.
|
|
|
|
**Wir können 80-90% davon replizieren** in 2-4 Wochen mit:
|
|
- NanoMDM (haben wir schon)
|
|
- .mobileconfig-Profile (DNS, Restrictions, Browser)
|
|
- RemovalPassword + "Profile Locking" Backend-Logic
|
|
- RebreakBinder-Mac SwiftUI-App als Wizard
|
|
|
|
**Was wir NICHT replizieren können:**
|
|
- "Supervision" (existiert auf Mac nicht)
|
|
- App-nicht-löschbar (nur via ADE/ABM, nicht Consumer-freundlich)
|
|
|
|
**Empfehlung:** GO für MVP-Pfad (UAMDM + Profiles), SKIP System-Extension im MVP (Phase 2), SKIP ABM (nicht nötig).
|
|
|
|
**Ehrlichkeits-Disclaimer für User:**
|
|
"Mac-Blocking ist effektiv und multi-layered (DNS + Browser + Accountability), aber nicht unbreakable wie iOS-Supervision. Ein Mac-User mit Admin-Zugriff kann theoretisch alles umgehen (wie bei jedem Mac-Parental-Control-Tool). Unser Schutz basiert auf Accountability + technischen Hürden, nicht auf absolutem Lock-Down."
|
|
|
|
---
|
|
|
|
**Nächster Schritt:** User-Entscheidung über Pfad → dann detailed Implementation-Planning für RebreakBinder-Mac.
|