On Mon, 2011-08-29 at 11:47 +0200, guilde@??? wrote:
> Hello folks,
>
> Comment empêcher, inconditionnellement, un utilisateur "normal" de
> mettre des permissions trop élevées sur ses fichiers ? umask ne règle le
> pb que pour les valeurs par défaut, mais n'empêche pas que l'utilisateur
> change les permissions ensuite.
>
> Scanner les fichiers après coup est trop lent et trop tard. Et je
> deviens dingue à force d'expliquer que non, on ne suit pas les conseils
> de joomla qui dit de tout passer en 777 pour installer... et de ne pas
> le faire non plus via FTP avec Filezilla ou autre.
Je ne connais pas de solution bas niveau (filesystem ou vfs). Il y a
bien la possibilité d'utiliser un filesystem VFAT et l'options de
montage 'umask' mais on doit être d'accord que c'est un peu
désespéré ... Il y a aussi la piste des filesystems réseaux : je crois
avoir essayé sans succès avec NFSv3, peut être NFSv4 ?
Par contre plus haut niveau c'est possible : par exemple si ton
utilisateur n'utilise que FTP, tu peux utiliser 'pure-ftpd -R' [0] pour
l'empêcher de faire des chmod() et ton umask ne sera jamais
contourné...
Enfin sauf par PHP qui peut lui-même appeler chmod() et comme tu le
mentionnes certains installeurs n'hésitent pas à le faire à mauvais
escient. Et AMHA ni le défunt 'safe_mode' [1] ni Suhosin [2] n'ont prévu
d'empêcher chmod() d'être librement appelé. A la rigueur un trick à coup
de LD_PRELOAD et un wrapper minimaliste chmod/chattr pourrait boucher le
trou, mais je doute que beaucoup se soient embêtés à aller jusque là.
Il y aussi Samba/CIFS si tu dois partager un volume sur plusieurs
serveurs, pas une solution traditionnelle sous Unix, mais je crois que
ça fait le café et autorise à peu près tous les scenarii; et ça peut
fournir une solution effective au niveau du filesystem.
Je crois que ceux qui hébergent du "mutualisé" ont en partie renoncé à
policer leurs utilisateurs : ils se contentent de les isoler (chroot,
jails, containers, etc) et les laissent se débrouiller avec leur bazar.
Je pense que le 0777 n'est plus vraiment un pb de sécu quand un site
web est isolé des autres. Pour le bit 'r': une seule appli, pas de fuite
de data (il faut deux comptes pour que la fuite circule... mais ça
mérite une plus longue discussion). Pour le bit 'w': il existe toujours
un endroit dispo en écriture sur le filesystem car c'est requis par
99,99% des applis PHP, et un seul répertoire suffit pour qu'un worm se
pose (/tmp fera l'affaire). Et pour l'exécution, très souvent on peut
invoquer le loader directement (/ld/linux-so...) et ne pas nécessiter le
'+x' ou alors smiplement utiliser la populaire option de montage
'noexec'.
Personnellement pour les quelques "mutus" que j'ai, à titre perso avec
les copains ou au taf (je fait surtout du dédié au boulot), je n'utilise
aucune technique de protection particulière à part un compte Unix par
utilisateur + pas mal de temps à expliquer et former les gens/clients.
Ca marchez assez bien en les responsabilisant : on me demande souvent
"mon appli web veut écrire à tel endroit, comment je pourrais faire de
la manière la plus simple et sécurisée possible ?". Notez que je
préconise de simplement faire un "chmod 777 rép" (non récursif donc) et
si possible sur _un seul_ répertoire. Il y a des applis bien foutues qui
écrivent à un seul endroit dans le filesystem et tout devient simple et
clean. Non je déconne.
[0]
http://download.pureftpd.org/pub/pure-ftpd/doc/README
[1]
http://fr.php.net/manual/en/features.safe-mode.php
|2]
http://www.hardened-php.net/suhosin/configuration.html
