non-root

[Tomasz Kłoczko]

On Mon, 16 Jul 2001, Jacek Konieczny wrote:

> On Mon, Jul 16, 2001 at 04:36:07PM +0200, Blues wrote:
> > Wiele demonow chodzi u nas na uzytkowniku root, pomimo iz tego w zasadzie
> > nie potrzebuja. Tak od razu przychodza mi do glowy syslog czy tez arpd. O
> > ile ten drugi bezkarnie mozna przeniesc na innego uzytkownika to drugi
> > potrzebuje root'a (w zasadzie jedno capability) tylko do polaczen
> > sieciowych.
> A syslog jak stworzy swoje sockety w /dev?

Jacek zauważ, że przez 666 na /dev/log w zasadzie każdy unices jest
pieknie dosowalny. W tej chwili takie ładne źródło duzego strumienia można
wygemnerować z użytkownik uruchamiająć .. tcpd (uruchom to sobie i
poobserwuj load).
na dłużśża mete wartobyu zmienić uprawnienia do /dev/log takze by miała do
niego dosęp tylko wydzielona grupa uzytkowników.
Druga sprawa, że syslogd mógłby spokojnie startować z roota, zakłądać
/dev/log, ustawiać uprawnienia do tegoż i dalej zmienić uid procesu na
inne. To samo dotyczy wspomnianego arpd.
Tak czy inaczje tego typu zmiany wymagają poprostu poprawk w kodzie żeby
te procesy dokąłdnie tak funkcjonowały.

> > Propozycja jest taka, zeby przenosic z root'a demony, ktore tego nie
> > wymagaja wcale (np. arpd) i wszystkie niech chodza na jednym uzytkowniku
> 
> > (czy to dobry pomysl?).
> Nie najlepszy. Włam przez jednego z nich powoduje narażenie plików
> wszystkich. IMHO wszystko co nie ma własnych plików/katalogów/praw może
> chodzić jako nobody, ale jak już coś np. trzyma własną bazę, to już
> powinno mieć własnego użytkownika. Tak żeby "nobody" nie był
> właścicielem żadnego pliku i nie miał nigdzie praw zapisu i nadmiernych
> praw odczytu. No, w przypadku takiego /tmp to trudno zrobić :-)

Tu chyba też jest to do rozwiazania poprzez ustawienie TMPDIR przed
startem procesu na własna ścieżkę.
Tak wogóle powinniśmy zacżąć ścigać rogramy które używaja na stałe
zaszytej ścieżki /tmp, a nie $TMPDIR.
Jeżeli ktoś ma cheć robić takie testy to wystarczyłoby odciać system od
/tmp ustawiająć $TMPDIR inną lokację co powinno zacżąć w przypadku źle
napisanych programów skutkować niepoprawnym funkcjonowaniem.

> > Niech sie on nazywa non-root (uid=40 jest wolne na przyklad).
> Po co nowy user, skoro jest nobody?

W przypadku braku odwołań do plików jasne.

> > Dla tych,
> > ktore wymagaja jakiegos capability nalezaloby dawac oddzielny uid.  > Ale te
> > demony, ktore chca jednego capability niech chodza na 1 uid.
> To rozszerzenie tego co napisałem wyżej.
> 
> > Wymaga to jednak wprowadzenia poprawek w jajku.
> Wolałbym tego uniknąć. Dobrze by było gdyby jednak większość naszych
> pakietów działała także na "normalnym" kernelu, mimo że np. ja takiego
> nie uznaję.
> 
> > Dodatkowo _teraz_ mozna stworzyc syslog'a, ktory nie chodzi na roocie, ale
> > bez mozliwosci logowania sieciowego. W wiekszosci wypadkow jest to
> > wystarczajace, a troche bezpieczniejsze.
> Ale syslog czytający z sieci też jest bardzo potrzebny.

Mógłby on spokojnie wykonać bind do interfejsu po czym zmienić euid/uid
procesu (?).

> No i jak z uprawnieniami do logów? Gdy syslog chodzi jako root mogę nimi
> manipulować do woli, np. pozwalając niektórym userom czy analizatorom
> logów dostęp do niektórych logów.

Hmm .. o tym nie pomyślałem :>

kloczek
-- 
-----------------------------------------------------------
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
-----------------------------------------------------------
Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek w rudy.mif.pg.gda.pl*