Linux - l'utente può essere nella directory proibita se su di esso da utente con accesso - è questo riguardo?

6

Ero in una directory su CentOS come utente1 (root in questo caso) e poi ho fatto su a user2 che normalmente non può accedere a quella directory a causa della mancanza dell'autorizzazione "execute" su una directory padre, ma come utente2 I è stato in grado di leggere quello che c'era dentro bene. Non ritengo che ciò costituisca un rischio per la sicurezza poiché dovevo iniziare come utente con accesso, ma c'è qualche implicazione a cui non sto pensando che ciò costituisca un problema?

    
posta sa289 15.02.2016 - 06:09
fonte

1 risposta

5

Non userei la parola "concern", ma è qualcosa di cui dovresti essere a conoscenza. Quando esegui un programma con privilegi diversi, devi sempre fare attenzione all'ambiente in cui viene eseguito il programma con privilegi differenti.

Se il programma viene eseguito con privilegi elevati, deve fare attenzione a quale ambiente viene eseguito - le variabili di ambiente sono un rischio ben noto ( PATH , LD_PRELOAD , EDITOR , ... per citarne alcuni tra molti ).

Se il programma viene eseguito con privilegi ridotti, l'ambiente deve prestare attenzione a quali credenziali il programma riceve. Le credenziali includono utenti e gruppi, ma anche descrittori di file aperti e cose simili. La directory corrente conta come una cosa simile. In questa nota, sudo chiude tutti i descrittori di file tranne quelli standard (0, 1, 2), mentre invece (almeno su Linux) su non li tocca.

Il passaggio a processi con privilegi ridotti come una directory corrente o descrittori di file può essere utile. Nel tuo caso, ciò consente a un programma di essere eseguito come utente2 e di elaborare i file in quella specifica directory, senza consentire al programma di accedere a tutte le altre directory a cui l'utente1 può accedere ma non all'utente2. Un classico esempio con descrittori di file è quello di avviare un processo server come root con una porta TCP privilegiata aperta, e quindi rilasciare i privilegi prima di eseguire l'applicazione server - in questo modo l'applicazione può servire questa specifica porta privilegiata ma nessun altro.

A proposito, c'è un altro modo in cui questa situazione (un processo non può cambiare nella sua directory corrente) può sorgere: se le autorizzazioni della directory cambiano dopo che il processo è cambiato in quella directory, ciò non influenzerà la directory corrente del processo.

Se questo rappresenta un rischio per la sicurezza dipende dallo scenario specifico. Prima di modificare i privilegi, la directory corrente è una delle cose che potrebbe dover essere disinfettata, come l'ambiente, i descrittori di file, ecc.

    
risposta data 18.02.2016 - 19:41
fonte

Leggi altre domande sui tag