P

trace(2) jest wspaniałym narzędziem do rozwiązywania problemów dla programistów, którzy chcą poznać jak funkcjonują procesy w systemie Linux. Umożliwia odnajdywanie błędów programistycznych, czy wycieków pamięci. Z drugiej strony ptrace może zostać wykorzystane przez osoby o złych intencjach np. w celu debugowania procesu jako nieuprzywilejowany użytkownik, aby odczytać zawartość pamięci programu.

Przed tego typu niepowołanym użyciem ptrace przychodzi Yama – moduł bezpieczeństwa, który zawiera cały szereg zabezpieczeń typu DAC:

Discretionary Access Control – uznaniowa metoda kontroli dostępu, w której prawo dostępu do wybranych obiektów jest wyznaczone na podstawie prawa własności obiektu, identyfikacji podmiotu próbującego uzyskać dostęp do danego zasobu oraz pośrednio lub bezpośrednio sformułowanych praw dostępu do zasobu przyznanych podmiotowi przez właściciela zasobu.

Sterowanie wyborem, jakie procesy mogą zostać zdebugowane za pomocą ptrace odbywa się za pomocą parametru jądra: kernel.yama.ptrace_scope. Jego wartość możemy określić za pomocą sysctl lub pseudo systemu plików /proc:

# sysctl kernel.yama.ptrace_scope
kernel.yama.ptrace_scope = 1

oraz

# cat /proc/sys/kernel/yama/ptrace_scope
1

Dla tego konkretnego klucza są cztery poprawne wartości (0-3):

• 0 – wszystkie procesy mogą być debugowane o ile posiadają ten sam uid (standardowa praca),
• 1 – tylko proces macierzysty może być debugowany,
• 2 – tylko administrator może używać ptrace (procesy muszą posiadać ustawione CAP_SYS_PTRACE),
• 3 – żaden proces nie może zostać śledzony za pomocą ptrace (wymaga restartu do przywrócenia innego trybu).

Systemy procesujące wrażliwe dane powinny raczej posiadać całkowicie wyłączoną możliwość używania ptrace (3). Dla domowych komputerów można wybrać nieco mniej restrykcyjne ustawienia (2 lub 1). Jako ciekawostkę warto zapamiętać, że Google Chrome Sandbox wykorzystuje Yama LSM na systemach wspierających to rozwiązanie.

Więcej informacji: Yama