uh non, pas dans le cas général en tout cas, pour exécuter du php avec moins de droits, voir module suphp de apache
Attention à ne pas confondre deux choses :
- D'une part la descente de droits. A savoir que le process initialisé par Apache se récupère un autre uid au moment de l'execution et de fait perd des droits.
- D'autre part l'isolation : à savoir que IIS ne peut pas du tout faute de droit initaliser tel fonction ou tel objet.
Pour modéliser rapidement dans un cas on a un utilisateur système qui gère tout et qui ensuite rabaisse les droits des différents processus, et dans l'autre on a plusieurs utilisateurs qui gèrent chacun leur morceau et pas plus et qui communiquent entre eux.
suphp permet de rabaisser les droits du script d'execution à ceux du propriétaire du fichier, mais rien n'empècherait l'utilisateur httpd de lancer le fichier sans passer par suphp et de fait de l'executer avec les mêmes drotis que ceux d'Apache. Donc si il y a une faille dans le script PHP lui même, on est protéger, mais si il y a une faille dans httpd la porte est grande ouverte et l'intrus qui gagnerait les droits pourrait alors avoir accès à l'ensemble des fichiers et des modules/CGI gérés par Apache.
A contrario si il y a une faille dans IIS 6.0 en mode isolation, l'intrus peut arreter et redemarer IIS envoyer des requètes au différents modules et objets COM normalement appelés directement par IIS, mais il n'a pas accès, aux source des pages, aux scripts .Net ni aux comportement des objets COM.
[^] # Re: Plusieurs hypothèses
Posté par Jerome Herman . En réponse au journal apache perd du terrain face à IIS de manière inquiétante. Évalué à 1.
Attention à ne pas confondre deux choses :
- D'une part la descente de droits. A savoir que le process initialisé par Apache se récupère un autre uid au moment de l'execution et de fait perd des droits.
- D'autre part l'isolation : à savoir que IIS ne peut pas du tout faute de droit initaliser tel fonction ou tel objet.
Pour modéliser rapidement dans un cas on a un utilisateur système qui gère tout et qui ensuite rabaisse les droits des différents processus, et dans l'autre on a plusieurs utilisateurs qui gèrent chacun leur morceau et pas plus et qui communiquent entre eux.
suphp permet de rabaisser les droits du script d'execution à ceux du propriétaire du fichier, mais rien n'empècherait l'utilisateur httpd de lancer le fichier sans passer par suphp et de fait de l'executer avec les mêmes drotis que ceux d'Apache. Donc si il y a une faille dans le script PHP lui même, on est protéger, mais si il y a une faille dans httpd la porte est grande ouverte et l'intrus qui gagnerait les droits pourrait alors avoir accès à l'ensemble des fichiers et des modules/CGI gérés par Apache.
A contrario si il y a une faille dans IIS 6.0 en mode isolation, l'intrus peut arreter et redemarer IIS envoyer des requètes au différents modules et objets COM normalement appelés directement par IIS, mais il n'a pas accès, aux source des pages, aux scripts .Net ni aux comportement des objets COM.