2015-04-16 29 views
13

Zauważyłem, że niektórzy z moich użytkowników nie otrzymali w ogóle rabunku po awarii, nawet jeśli wszystko inne w ich konfiguracji wydawało się poprawne.Upuszczanie przywilejów roota i wciąż generowanie coredumpów

po przeczytaniu strona core(5) człowiekowi kilka razy, i zauważył, ten szczególny punkt:

[Rdzeń zrzut nie jest wytwarzany, gdy] Proces wykonuje określoną ID użytkownika (zestaw -group-ID), który jest własnością użytkownika (grupy) innego niż rzeczywisty identyfikator użytkownika (grupy) procesu.

Mój demon nie jest setuid korzeń, ale w wielu konfiguracjach, to zaczęło się jako root, a jeśli plik .conf określa nazwę użytkownika, spada przywileje, ze zwykłymi kombinacji:

setgid(gid); 
setuid(uid); 

Kiedy to robi, coredumps nie są już generowane. Wszystko inne w środowisku wydaje się poprawne, usunięcie tych wywołań (i pozostanie jako root) przynosi mi coredumps jak zwykle.

Starałem się zmienić „prawdziwe” uid/gid jako strona mężczyzna wydawał się sugerować, wywołując mniej przenośny setresgid/uid który wydaje się być sugerowane często spadać przywileje stałe:

setresgid(gid, gid, gid); 
setresuid(uid, uid, uid); 

Spodziewałem się, że to rozwiąże problem, ale ... w ogóle się nie poprawiło. Nadal nie ma coredump.

Sooo ... co teraz?


kod badania:

#include <stdlib.h> 

int main(int argc, char **argv) { 
     if (argc > 1) { 
       setgid(atoi(argv[2])); 
       setuid(atoi(argv[1])); 
     } 
     abort(); 
} 

Zastosowanie:

  • ./a.out jako dowolny użytkownik po prostu usunąć bez setgid/setuid
  • ./a.out 1000 100 (gdzie 1000 UID 100 jest GID) jako root upuść przywileje i oglądać coredumps nie zdarzają się.
  • Niepożądana funkcja bonusu: należy przekazać jeden parametr, a nie dwa, aby uzyskać SIGSEGV zamiast SIGABRT.

Ja już przetestowane w Arch Linux, CentOS 6.5 i OpenBSD 5.3

+0

A nieuprzywilejowany użytkownik/grupa nie wyłączył wyładowań głównych ('ulimit -c' nie zgłasza' 0')? –

+0

Tak, nieograniczona po obu stronach. Użycie go jako identyfikatora UID (0 i 1000) bez wywołań setuid/gid powoduje powstanie coredumpów. – dequis

+0

Naprawdę trzeba być bardziej specyficznym dla tego rodzaju rzeczy, dystrybucje Linuksa robią tu różne rzeczy. W szczególności są tam moduły PAM, pamiętaj o ubuntu, które wchodzą w interakcje z tworzeniem zrzutów rdzenia. –

Odpowiedz

2

Aby wymusić proces zawsze zrzutu pamięci, należy użyć wywołania systemowego prctl.

prctl(PR_SET_DUMPABLE, 1, 0, 0, 0); 
+0

Interesujące! Testuję to później. Wydaje się być specyficznym dla Linuksa, a BSD również to zachowanie. – dequis

+0

Na openbsd unieważnij bit KERN_NOSUIDCOREDUMP z sysctl() http://nixdoc.net/man-pages/OpenBSD/sysctl.3.html – clockley1

0

Musisz włączyć rdzeń wysypisk dla aplikacji, które zmieniły ich przywileje:

echo 2 > /proc/sys/fs/suid_dumpable 

radzę się umieść to w /etc/rc.local.


Na przykład, oto co mam tam:

# This is to enable debugging as a normal user, rather than root 
sysctl kernel.yama.ptrace_scope=0 

# This is a convenient core file pattern 
# '%e' is the name of the process 
# '%p' is the pid of process 
sysctl kernel.core_pattern="/tmp/core.%e.%p" 

# Enable dump for processes with lowered privileges 
echo 2 > /proc/sys/fs/suid_dumpable 

# Remove limit for the size of core files 
ulimit -c unlimited 

Edit:

Można spojrzeć na to schludny biblioteki, który pozwala ręcznie pisać zrzuty główne do niestandardowego pliku: https://code.google.com/p/google-coredumper/

Uważam, że jest dokładnie to, czego potrzebujesz.

+0

Dzięki! Ale jestem tylko programistą demona, nie mam kontroli nad systemami, w których będzie on zainstalowany. Próbuję to naprawić, abym mógł uzyskać coredumpy od użytkowników, którzy nie spodziewali się awarii, więc ... Gdybym musiał im to powiedzieć, równie dobrze mógłbym im powiedzieć, żeby uruchomili gdb. Szukam czegoś, co mogę naprawić w moim kodzie. – dequis

+1

@dequis, niestety, nie wiem, jak to zrobić * z twojej strony *. Jest to swego rodzaju luka w zabezpieczeniach, i dlatego zrzut rdzenia jest wyłączony, chyba że włączysz go ręcznie (jako "root"). W twoim przypadku upuszczasz przywileje, tak jak dla mnie wydaje się to bezpieczne. Ale są aplikacje, które promują przywileje ('passwd'), a pozwalanie im na zrzucanie rdzenia jest ogromnym ryzykiem. – GreenScape

+0

@dequis, proszę przeczytać moje ostatnie edycje, mam nadzieję, że to jest to, czego potrzebujesz. – GreenScape