Silnik SecurityCheck i reguły walidacji

Zanim Speedwave uruchomi kontenery, generuje specyfikację compose dla danego projektu i przekazuje ją do silnika walidacji SecurityCheck. Moduł SecurityCheck analizuje wygenerowany plik YAML, sprawdza go pod kątem reguł bezpieczeństwa oraz weryfikuje uprawnienia w systemie plików hosta. Wykrycie jakiejkolwiek niezgodności natychmiast zatrzymuje start środowiska.

Mechanizm ten gwarantuje, że środowisko wykonawcze ściśle przestrzega zasad określonych w modelu izolacji.

Zasada działania fail-closed

SecurityCheck działa w modelu fail-closed: pojedyncze naruszenie reguły bezwzględnie blokuje uruchomienie kontenerów i nie ma flagi pozwalającej pominąć ten test. Weryfikacja jest wymuszana przez polecenia CLI speedwave oraz speedwave check, a w aplikacji Desktop w przypadku błędu wyświetla się blokujący komunikat diagnostyczny. Zestawienie poleceń znajdziesz w rozdziale Dokumentacja CLI.

Polecenie speedwave check służy do audytu konfiguracji i raportowania naruszeń. Standardowe procedury startowe potrafią automatycznie naprawić nieprawidłowe uprawnienia plików na hoście. Jeśli problem dotyczy nieprawidłowego właściciela plików (co wymaga uprawnień administratora/root), narzędzie wyświetla dokładne polecenia do wykonania ręcznie.

Weryfikowane grupy reguł bezpieczeństwa

Zestaw testów weryfikuje granice ochrony danych opisane w rozdziale Zarządzanie danymi uwierzytelniającymi. Wszystkie reguły są sprawdzane kompleksowo, a wykryte naruszenia agregowane w jednym raporcie.

Grupa reguł	Zakres weryfikacji
Zabezpieczenia kontenerów	Odebrane capabilities Linuksa, zablokowana eskalacja uprawnień, kontenery claude/mcp-hub/proxy w trybie tylko do odczytu z niewykonywalnym /tmp
Tokeny i sekrety	Kontenery claude i mcp-hub odrzucają zmienne środowiskowe przypominające poświadczenia (poza ścisłą listą dozwoloną); klucze zewnętrznych dostawców LLM nie mogą trafić do claude
Granice sieciowe	Porty nasłuchują wyłącznie na 127.0.0.1, socket silnika kontenerów na hoście jest zablokowany przed montowaniem, wbudowane workery MCP nie wystawiają portów
Tożsamość procesu	Kontenery wykonują się wyłącznie jako zdefiniowany użytkownik bez uprawnień root
Wolumeny proxy	Punkty montowania kontenera proxy odpowiadają ściśle zdefiniowanemu profilowi bezpieczeństwa
Ograniczenia wtyczek	Brak trybu uprzywilejowanego i dostępu do sieci hosta, poprawny podpis manifestu oraz montowanie wolumenów zgodne z listą dozwolonych
Profile integracji (SharePoint, Slack)	Integracje przestrzegają zadeklarowanych ścieżek wolumenów i trybów dostępu bez nadmiarowych punktów montowania
Uprawnienia na hoście (Unix)	Pliki i foldery pod ~/.speedwave/ mają wymagane uprawnienia (0o600/0o700) oraz właściwego właściciela

Weryfikacja uprawnień na hoście jest pomijana w systemie Windows, gdzie dostęp regulują listy kontroli dostępu (DACL). Sprawdzanie metadanych odbywa się bezpiecznie bez podążania za symlinkami.

Obsługa naruszeń

W przypadku wykrycia problemu raport diagnostyczny wskazuje nazwę kontenera, identyfikator niespełnionej reguły, opis problemu oraz zalecane kroki naprawcze. Weryfikacja wymagań systemowych (np. dostępność WSL2 na Windowsie) działa w analogiczny sposób.

Zakres walidacji

SecurityCheck odpowiada za weryfikację wygenerowanych specyfikacji compose oraz katalogu ~/.speedwave/ na hoście. Zabezpieczenia na poziomie aplikacji Desktop (takie jak ochrona przed SSRF dla linków wychodzących, obsługa dźwięku czy izolacja procesów lokalnych) podlegają odrębnym modułom ochronnym opisanym w odpowiednich rozdziałach dokumentacji.