[Précédent (date)] [Suivant (date)] [Précédent (sujet)] [Suivant (sujet)] [Index par date] [Index par sujet]

Re: Stratégies pour les fichiers setuid ?

--- Hugo Villeneuve <[email protected]> wrote:
> On Sun, Dec 29, 2002 at 02:31:39PM -0500, Etienne
> Robillard wrote:
> > bonjour,
> > 
> > je sais pas quoi faire vraiment avec les fichiers
> > setuid/sgid... je sais que, puisque mon kernel est
> en
> > insecure mode, il s'agit d'un risque de s?curit?
> 
> insecure/secure mode? Je croyais pas que Linux
> utilisait ce genre
> de concepts.
> 
> C'est typiquement BSD par contre.
> 
> > potentiel si un programme malicieux aurait acc?s a
> > /dev/kmem...
> 
> En principe, les restrictions d'accès sur le fichier
> /dev/kmem font
> que seulement l'usagé root puisse y écrire.
> 
> Mais si qqn réussi à exploiter un daemon roulant
> sous l'usager root
> ou un programme setuid root, il posséde déjà ta
> machine par d'autre
> moyen beaucoup plus simple et qu'il ait accès à kmem
> est le dernier
> de tes soucis.
> 
> Mais ça c'est un problème vieux comme le monde pour
> les Unix. Parce
> qu'ils ont seulement 2 systèmes de restrictions
> d'accès (root user
> peut faire tout et droits d'accès aux fichiers pour
> les autres) ce
> qui n'est pas suffisant pour tout le monde.
> 
> C'est pour sa que des trucs come SELinux existent. 
> 
> > 
> > ma solution est de chmod 0 tous ces fichiers mais
> > c'est plutot long et c'est pas trop ?l?gant...
> 
> Tu risques plus de briser des fonctionnalités de ta
> machine avec
> cette méthode.
> 
> Il faut que tu fasses du cas par cas. Si tu ne vois
> pas pourquoi
> un programme serait disponible à un usager normal
> via un setuid
> root, tu enlèves le setuid bit et seulement root
> pourra utiliser
> ce programme.
> 
> Certain programme sont setuid un autre usager que
> root pour permettre
> à des programmes de coopérer entre eux. C'est
> peut-être dangeureux
> ou pas. Ça dépend si certain de ses programmes
> roulent sous l'usager
> root ou ont accès à des devices important parce
> qu'il possède la
> device filei (droit de fichier). 
> 
> Tu peux aussi mieux controller l'accès à certain
> programme en
> utilisant "sudo" pour permettre à seulement quelques
> usager de les
> utiliser plutot que tout le monde via un setuid root
> bit.
> 
> Et si tu trouves des setuid bit sur un programme
> faisant parti d'un
> package que tu n'utiliseras pas. Enlèves tout le
> package. 
> 
> > 
> > je voulais savoir s'il n'aurait pas d'autres
> > solutions,
> 
> Ce n'est pas que les programmes setuid/setgid qui
> peuvent causer
> des problèmes. D'autant plus, qu'ils sont souvent
> qu'exploitable
> que par un usager ayant déjà un compte sur ta
> machine.
> 
> Il est beaucoup plus important de vérifier si on est
> exploitable
> via des daemons lancer au démarrage de la machine
> (parce qu'ils
> sont lancer par l'usager root, il n'ont pas besoin
> de setuid bit)
> et qui offre des services via le réseaux.
> 
> 
> Anyway, utilise "find" pour les trouver tes
> programmes setuid.
> Genre:
> 
> find / -perm +04000 -user root -type f
> 
> > a part de s?curiser le kernel biensur :-)
> > 
> > sinc?rement,
> > 
> > etienne
> >  
> 
> -- 
> Hugo Villeneuve <[email protected]>
> http://EINTR.net/ 
> 
> --
> Liste de diffusion aide
> http://linux-quebec.org/mailman/listinfo/aide

"insecure/secure mode? Je croyais pas que Linux
utilisait ce genre
de concepts.

C'est typiquement BSD par contre."

yep :)








=====
Unix - Live Free or Die!
[Project Colibri] @ http://etud.cmontmorency.qc.ca/arts/erobillard/

______________________________________________________________________ 
Post your free ad now! http://personals.yahoo.ca