Ca se tient pour une machine qui est utilisée par plusieurs personnes et
administrée par une unique personne. L'admin veut centraliser les
installations et l'usage.
C'est un peu le but et on ne peut pas faire un choix à l'install (je
suis seul, je ne suis pas seul), donc il faut penser au cas le plus
général.
Et encore, quel est le problème si un utilisateur qui a besoin d'un
client FTP se copie Cyberduck ou Transmit dans son ~/Applications!?
Ou GraphicConverter?
Ca dépend de la politique de la maison. Si un utilisateur utilise un
logiciel qu'il pirate en le copiant dans son home, c'est embêtant.
En tout cas pour une machine personelle, je suis de l'avis opposé, car
au moins les programmes ont des droits très limitées et ne peuvent pas
influencer ou détruire le système, que ce soit à l'installation ou à
l'utilisation.
Je ne vois pas de différence entre la machine multi-utilisateurs et la
machine mono-utilisateurs.
De plus, même en utilisateur standard un
programme peut faire des dégâts. S'il efface toutes les données de
l'utilisateur, crois-tu que ce dernier sera rassuré en voyant que son
système est sain et sauf ? perso j'accorde plus d'importances à mes
données qu'à mon OS, ce dernier, je peux le réinstaller et le
reparamétrer quand je veux.
Ca se tient pour une machine qui est utilisée par plusieurs personnes et
administrée par une unique personne. L'admin veut centraliser les
installations et l'usage.
C'est un peu le but et on ne peut pas faire un choix à l'install (je
suis seul, je ne suis pas seul), donc il faut penser au cas le plus
général.
Et encore, quel est le problème si un utilisateur qui a besoin d'un
client FTP se copie Cyberduck ou Transmit dans son ~/Applications!?
Ou GraphicConverter?
Ca dépend de la politique de la maison. Si un utilisateur utilise un
logiciel qu'il pirate en le copiant dans son home, c'est embêtant.
En tout cas pour une machine personelle, je suis de l'avis opposé, car
au moins les programmes ont des droits très limitées et ne peuvent pas
influencer ou détruire le système, que ce soit à l'installation ou à
l'utilisation.
Je ne vois pas de différence entre la machine multi-utilisateurs et la
machine mono-utilisateurs.
De plus, même en utilisateur standard un
programme peut faire des dégâts. S'il efface toutes les données de
l'utilisateur, crois-tu que ce dernier sera rassuré en voyant que son
système est sain et sauf ? perso j'accorde plus d'importances à mes
données qu'à mon OS, ce dernier, je peux le réinstaller et le
reparamétrer quand je veux.
Ca se tient pour une machine qui est utilisée par plusieurs personnes et
administrée par une unique personne. L'admin veut centraliser les
installations et l'usage.
C'est un peu le but et on ne peut pas faire un choix à l'install (je
suis seul, je ne suis pas seul), donc il faut penser au cas le plus
général.
Et encore, quel est le problème si un utilisateur qui a besoin d'un
client FTP se copie Cyberduck ou Transmit dans son ~/Applications!?
Ou GraphicConverter?
Ca dépend de la politique de la maison. Si un utilisateur utilise un
logiciel qu'il pirate en le copiant dans son home, c'est embêtant.
En tout cas pour une machine personelle, je suis de l'avis opposé, car
au moins les programmes ont des droits très limitées et ne peuvent pas
influencer ou détruire le système, que ce soit à l'installation ou à
l'utilisation.
Je ne vois pas de différence entre la machine multi-utilisateurs et la
machine mono-utilisateurs.
De plus, même en utilisateur standard un
programme peut faire des dégâts. S'il efface toutes les données de
l'utilisateur, crois-tu que ce dernier sera rassuré en voyant que son
système est sain et sauf ? perso j'accorde plus d'importances à mes
données qu'à mon OS, ce dernier, je peux le réinstaller et le
reparamétrer quand je veux.
Entièrement d'accord d'où l'intérêt du système de droits si performant (à
mon sens) dont est équipé OS X. Mais dans ce cas, pourquoi l'administrateur
n'aurait il pas la possibilité de modifier lui même ces droits ???
Même l'utilisateur "root" rencontre les ces difficultés...
Entièrement d'accord d'où l'intérêt du système de droits si performant (à
mon sens) dont est équipé OS X. Mais dans ce cas, pourquoi l'administrateur
n'aurait il pas la possibilité de modifier lui même ces droits ???
Même l'utilisateur "root" rencontre les ces difficultés...
Entièrement d'accord d'où l'intérêt du système de droits si performant (à
mon sens) dont est équipé OS X. Mais dans ce cas, pourquoi l'administrateur
n'aurait il pas la possibilité de modifier lui même ces droits ???
Même l'utilisateur "root" rencontre les ces difficultés...
Laurent Pertois wrote, On 30/12/07 2:14:Ca se tient pour une machine qui est utilisée par plusieurs personnes et
administrée par une unique personne. L'admin veut centraliser les
installations et l'usage.
C'est un peu le but et on ne peut pas faire un choix à l'install (je
suis seul, je ne suis pas seul), donc il faut penser au cas le plus
général.
Je suis seul sur ma machine, et j'en suis sûr à 100%, je n'ai pas besoin
du cas général, donc j'apprécie les applications qui me laissent gérer
comme je l'entends.
Ca dépend de la politique de la maison. Si un utilisateur utilise un
logiciel qu'il pirate en le copiant dans son home, c'est embêtant.
Note que c'est une protection bien futile. Même les logiciels demandant
les droits admins pour l'installation se laissent parfois installer
sans, en bidouillant un peu (typiquement en allant chercher à la main
les .app dans les .pkg).
En tout cas c'est comme du dis, ça dépend de la politique de la maison.
Quand tu as des utilisateurs un peu responsables et qui ont besoin de
flexibilité, c'est quand même bien pratique qu'ils puissent utiliser une
application comme bon leur semble sans avoir à appeller l'admin. En
plus, il n'y a aucun risque que l'installation influence les autres
utilisateurs.
Je ne vois pas de différence entre la machine multi-utilisateurs et la
machine mono-utilisateurs.
Tu as donnée une des différences plus haut: sur la machine
multi-utilisateurs cela vaut le coup d'avoir une gestion centralisée (et
donc protégée par des droits spécifiques). Sur la machine
mono-utilisateur, on peut par contre protéger le système contre les
modifications.
De plus, même en utilisateur standard un
programme peut faire des dégâts. S'il efface toutes les données de
l'utilisateur, crois-tu que ce dernier sera rassuré en voyant que son
système est sain et sauf ? perso j'accorde plus d'importances à mes
données qu'à mon OS, ce dernier, je peux le réinstaller et le
reparamétrer quand je veux.
Certes, mais entre une solution où un programme peut:
1. effacer toutes mes données
2. effacer toutes mes données et casser mon système
je préfère la solution 1. C'est le principe des moindres privilèges.
Note aussi que sous Windows la mode est aux applications sans
installation, pour pouvoir par exemple les stocker sur une clé USB et
les utiliser de manière mobile.
Un dernière point: un code malveillant (virus, cheval de troie...)
pourra se planquer avec une installation en tant qu'admin. C'est un
argument majeur à mon sens, même si ce problème est limité pour le
moment sur Mac. S'il n'a que les droits utilisateur, ce sera beaucoup
plus facile de le débusquer et de l'éradiquer.
Laurent Pertois wrote, On 30/12/07 2:14:
Ca se tient pour une machine qui est utilisée par plusieurs personnes et
administrée par une unique personne. L'admin veut centraliser les
installations et l'usage.
C'est un peu le but et on ne peut pas faire un choix à l'install (je
suis seul, je ne suis pas seul), donc il faut penser au cas le plus
général.
Je suis seul sur ma machine, et j'en suis sûr à 100%, je n'ai pas besoin
du cas général, donc j'apprécie les applications qui me laissent gérer
comme je l'entends.
Ca dépend de la politique de la maison. Si un utilisateur utilise un
logiciel qu'il pirate en le copiant dans son home, c'est embêtant.
Note que c'est une protection bien futile. Même les logiciels demandant
les droits admins pour l'installation se laissent parfois installer
sans, en bidouillant un peu (typiquement en allant chercher à la main
les .app dans les .pkg).
En tout cas c'est comme du dis, ça dépend de la politique de la maison.
Quand tu as des utilisateurs un peu responsables et qui ont besoin de
flexibilité, c'est quand même bien pratique qu'ils puissent utiliser une
application comme bon leur semble sans avoir à appeller l'admin. En
plus, il n'y a aucun risque que l'installation influence les autres
utilisateurs.
Je ne vois pas de différence entre la machine multi-utilisateurs et la
machine mono-utilisateurs.
Tu as donnée une des différences plus haut: sur la machine
multi-utilisateurs cela vaut le coup d'avoir une gestion centralisée (et
donc protégée par des droits spécifiques). Sur la machine
mono-utilisateur, on peut par contre protéger le système contre les
modifications.
De plus, même en utilisateur standard un
programme peut faire des dégâts. S'il efface toutes les données de
l'utilisateur, crois-tu que ce dernier sera rassuré en voyant que son
système est sain et sauf ? perso j'accorde plus d'importances à mes
données qu'à mon OS, ce dernier, je peux le réinstaller et le
reparamétrer quand je veux.
Certes, mais entre une solution où un programme peut:
1. effacer toutes mes données
2. effacer toutes mes données et casser mon système
je préfère la solution 1. C'est le principe des moindres privilèges.
Note aussi que sous Windows la mode est aux applications sans
installation, pour pouvoir par exemple les stocker sur une clé USB et
les utiliser de manière mobile.
Un dernière point: un code malveillant (virus, cheval de troie...)
pourra se planquer avec une installation en tant qu'admin. C'est un
argument majeur à mon sens, même si ce problème est limité pour le
moment sur Mac. S'il n'a que les droits utilisateur, ce sera beaucoup
plus facile de le débusquer et de l'éradiquer.
Laurent Pertois wrote, On 30/12/07 2:14:Ca se tient pour une machine qui est utilisée par plusieurs personnes et
administrée par une unique personne. L'admin veut centraliser les
installations et l'usage.
C'est un peu le but et on ne peut pas faire un choix à l'install (je
suis seul, je ne suis pas seul), donc il faut penser au cas le plus
général.
Je suis seul sur ma machine, et j'en suis sûr à 100%, je n'ai pas besoin
du cas général, donc j'apprécie les applications qui me laissent gérer
comme je l'entends.
Ca dépend de la politique de la maison. Si un utilisateur utilise un
logiciel qu'il pirate en le copiant dans son home, c'est embêtant.
Note que c'est une protection bien futile. Même les logiciels demandant
les droits admins pour l'installation se laissent parfois installer
sans, en bidouillant un peu (typiquement en allant chercher à la main
les .app dans les .pkg).
En tout cas c'est comme du dis, ça dépend de la politique de la maison.
Quand tu as des utilisateurs un peu responsables et qui ont besoin de
flexibilité, c'est quand même bien pratique qu'ils puissent utiliser une
application comme bon leur semble sans avoir à appeller l'admin. En
plus, il n'y a aucun risque que l'installation influence les autres
utilisateurs.
Je ne vois pas de différence entre la machine multi-utilisateurs et la
machine mono-utilisateurs.
Tu as donnée une des différences plus haut: sur la machine
multi-utilisateurs cela vaut le coup d'avoir une gestion centralisée (et
donc protégée par des droits spécifiques). Sur la machine
mono-utilisateur, on peut par contre protéger le système contre les
modifications.
De plus, même en utilisateur standard un
programme peut faire des dégâts. S'il efface toutes les données de
l'utilisateur, crois-tu que ce dernier sera rassuré en voyant que son
système est sain et sauf ? perso j'accorde plus d'importances à mes
données qu'à mon OS, ce dernier, je peux le réinstaller et le
reparamétrer quand je veux.
Certes, mais entre une solution où un programme peut:
1. effacer toutes mes données
2. effacer toutes mes données et casser mon système
je préfère la solution 1. C'est le principe des moindres privilèges.
Note aussi que sous Windows la mode est aux applications sans
installation, pour pouvoir par exemple les stocker sur une clé USB et
les utiliser de manière mobile.
Un dernière point: un code malveillant (virus, cheval de troie...)
pourra se planquer avec une installation en tant qu'admin. C'est un
argument majeur à mon sens, même si ce problème est limité pour le
moment sur Mac. S'il n'a que les droits utilisateur, ce sera beaucoup
plus facile de le débusquer et de l'éradiquer.
Je suis seul sur ma machine, et j'en suis sûr à 100%, je n'ai pas besoin
du cas général, donc j'apprécie les applications qui me laissent gérer
comme je l'entends.
<sarcastique>
Zut, tu as effacé les utilisateurs système ?
</sarcastique>
Question de point de vue, perso, si un installeur est rigide, je le
laisse faire sans me poser de questions.
En tout cas c'est comme du dis, ça dépend de la politique de la maison.
Quand tu as des utilisateurs un peu responsables et qui ont besoin de
flexibilité, c'est quand même bien pratique qu'ils puissent utiliser une
application comme bon leur semble sans avoir à appeller l'admin. En
plus, il n'y a aucun risque que l'installation influence les autres
utilisateurs.
Ce n'est pas une question d'influencer, c'est une question de légalité.
Et puis, c'est le boulot de l'admin de faire ça, pas des utilisateurs,
enfin, àmha.
Tu as donnée une des différences plus haut: sur la machine
multi-utilisateurs cela vaut le coup d'avoir une gestion centralisée (et
donc protégée par des droits spécifiques). Sur la machine
mono-utilisateur, on peut par contre protéger le système contre les
modifications.
/Applications est système ? selon Apple, non, le domaine système c'est
/System, qui ne doit pas être touché sauf pour les extensions.
Perso, j'ai dans /Applications un dossier pour les applis tierces qui
s'installent où on veut, le reste se met comme il le souhaite et je n'y
touche pas.Certes, mais entre une solution où un programme peut:
1. effacer toutes mes données
2. effacer toutes mes données et casser mon système
je préfère la solution 1. C'est le principe des moindres privilèges.
Je ne vois pas de différence, comme je l'ai dit. Mon système n'a aucune
valeur pour moi, il est remplaçable à l'envie. Mes données elles, par
contre, ont un grand intérêt et le principe des moindres privilèges ne
peut pas les protéger.
Un dernière point: un code malveillant (virus, cheval de troie...)
pourra se planquer avec une installation en tant qu'admin. C'est un
argument majeur à mon sens, même si ce problème est limité pour le
moment sur Mac. S'il n'a que les droits utilisateur, ce sera beaucoup
plus facile de le débusquer et de l'éradiquer.
Ah ? tu me fais une démo du "plus facile à débusquer s'il n'a que les
droits utilisateur" ? parce que s'il tourne, je vois à peu près (encore
que rien ne lui interdit d'embarquer un binaire setuid...) et s'il ne
tourne pas tu ne verras même pas qu'il est installé vu que tu risques de
ne pas avoir accès à l'élément das le dossier départ de l'utilisateur.
Je suis seul sur ma machine, et j'en suis sûr à 100%, je n'ai pas besoin
du cas général, donc j'apprécie les applications qui me laissent gérer
comme je l'entends.
<sarcastique>
Zut, tu as effacé les utilisateurs système ?
</sarcastique>
Question de point de vue, perso, si un installeur est rigide, je le
laisse faire sans me poser de questions.
En tout cas c'est comme du dis, ça dépend de la politique de la maison.
Quand tu as des utilisateurs un peu responsables et qui ont besoin de
flexibilité, c'est quand même bien pratique qu'ils puissent utiliser une
application comme bon leur semble sans avoir à appeller l'admin. En
plus, il n'y a aucun risque que l'installation influence les autres
utilisateurs.
Ce n'est pas une question d'influencer, c'est une question de légalité.
Et puis, c'est le boulot de l'admin de faire ça, pas des utilisateurs,
enfin, àmha.
Tu as donnée une des différences plus haut: sur la machine
multi-utilisateurs cela vaut le coup d'avoir une gestion centralisée (et
donc protégée par des droits spécifiques). Sur la machine
mono-utilisateur, on peut par contre protéger le système contre les
modifications.
/Applications est système ? selon Apple, non, le domaine système c'est
/System, qui ne doit pas être touché sauf pour les extensions.
Perso, j'ai dans /Applications un dossier pour les applis tierces qui
s'installent où on veut, le reste se met comme il le souhaite et je n'y
touche pas.
Certes, mais entre une solution où un programme peut:
1. effacer toutes mes données
2. effacer toutes mes données et casser mon système
je préfère la solution 1. C'est le principe des moindres privilèges.
Je ne vois pas de différence, comme je l'ai dit. Mon système n'a aucune
valeur pour moi, il est remplaçable à l'envie. Mes données elles, par
contre, ont un grand intérêt et le principe des moindres privilèges ne
peut pas les protéger.
Un dernière point: un code malveillant (virus, cheval de troie...)
pourra se planquer avec une installation en tant qu'admin. C'est un
argument majeur à mon sens, même si ce problème est limité pour le
moment sur Mac. S'il n'a que les droits utilisateur, ce sera beaucoup
plus facile de le débusquer et de l'éradiquer.
Ah ? tu me fais une démo du "plus facile à débusquer s'il n'a que les
droits utilisateur" ? parce que s'il tourne, je vois à peu près (encore
que rien ne lui interdit d'embarquer un binaire setuid...) et s'il ne
tourne pas tu ne verras même pas qu'il est installé vu que tu risques de
ne pas avoir accès à l'élément das le dossier départ de l'utilisateur.
Je suis seul sur ma machine, et j'en suis sûr à 100%, je n'ai pas besoin
du cas général, donc j'apprécie les applications qui me laissent gérer
comme je l'entends.
<sarcastique>
Zut, tu as effacé les utilisateurs système ?
</sarcastique>
Question de point de vue, perso, si un installeur est rigide, je le
laisse faire sans me poser de questions.
En tout cas c'est comme du dis, ça dépend de la politique de la maison.
Quand tu as des utilisateurs un peu responsables et qui ont besoin de
flexibilité, c'est quand même bien pratique qu'ils puissent utiliser une
application comme bon leur semble sans avoir à appeller l'admin. En
plus, il n'y a aucun risque que l'installation influence les autres
utilisateurs.
Ce n'est pas une question d'influencer, c'est une question de légalité.
Et puis, c'est le boulot de l'admin de faire ça, pas des utilisateurs,
enfin, àmha.
Tu as donnée une des différences plus haut: sur la machine
multi-utilisateurs cela vaut le coup d'avoir une gestion centralisée (et
donc protégée par des droits spécifiques). Sur la machine
mono-utilisateur, on peut par contre protéger le système contre les
modifications.
/Applications est système ? selon Apple, non, le domaine système c'est
/System, qui ne doit pas être touché sauf pour les extensions.
Perso, j'ai dans /Applications un dossier pour les applis tierces qui
s'installent où on veut, le reste se met comme il le souhaite et je n'y
touche pas.Certes, mais entre une solution où un programme peut:
1. effacer toutes mes données
2. effacer toutes mes données et casser mon système
je préfère la solution 1. C'est le principe des moindres privilèges.
Je ne vois pas de différence, comme je l'ai dit. Mon système n'a aucune
valeur pour moi, il est remplaçable à l'envie. Mes données elles, par
contre, ont un grand intérêt et le principe des moindres privilèges ne
peut pas les protéger.
Un dernière point: un code malveillant (virus, cheval de troie...)
pourra se planquer avec une installation en tant qu'admin. C'est un
argument majeur à mon sens, même si ce problème est limité pour le
moment sur Mac. S'il n'a que les droits utilisateur, ce sera beaucoup
plus facile de le débusquer et de l'éradiquer.
Ah ? tu me fais une démo du "plus facile à débusquer s'il n'a que les
droits utilisateur" ? parce que s'il tourne, je vois à peu près (encore
que rien ne lui interdit d'embarquer un binaire setuid...) et s'il ne
tourne pas tu ne verras même pas qu'il est installé vu que tu risques de
ne pas avoir accès à l'élément das le dossier départ de l'utilisateur.
Laurent Pertois wrote, On 30/12/07 12:02:<sarcastique>
Zut, tu as effacé les utilisateurs système ?
</sarcastique>
Je démarre toujours en utilisateur. J'ai du me logger 2 fois en admin en
1 an peut-être.
Question de point de vue, perso, si un installeur est rigide, je le
laisse faire sans me poser de questions.
Moi je rale et j'essaie de contourner :)
Ce n'est pas une question d'influencer, c'est une question de légalité.
Et puis, c'est le boulot de l'admin de faire ça, pas des utilisateurs,
enfin, àmha.
Ca dépend des politiques.
Dans les grandes boites, elles sont souvent tellement rigides que tu es
obligé d'installer des outils gratuits pour être efficace.
Par exemple, si tu veux faire quelques retouches minimes à une image
dans une grande structure (sous Windows pour l'exemple), tu as le choix
entre:
1. le procédé officiel avec un outil commercial
a) faire faire un devis
b) le faire valider par le département/la direction
c) passer la commande
d) faire valider l'outil par les admins
e) faire installer l'outil par les admins
Effort: 1 journée de boulot
Délai: 2 semaines (optimiste)
2. installer Paint.NET en tant qu'utilisateur
Effort: 10min
Délai: 10min
C'est un exemple vécu et courant.
La solution 2 est éventuellement interdite par la charte, mais tout le
monde le fait, et les admins ne disent rien quand ils le voient. Ils
savent bien que c'est la solution raisonnable, et que la voie officielle
ne vaut le coup que pour les usages importants et à long terme.
Bien sûr, il y a d'autres modes d'administration, typiquement dans les
PME PMI, où l'administrateur/administration est plus flexible et les
temps de réaction sont plus courts.
J'ai l'impression que c'est ton cas et que c'est la base de ton
raisonnement. C'est peut-être un mode d'administration plus courant dans
le monde Mac, mais c'est loin d'être la règle.
Pouvoir installer des outils en tant qu'utilisateur est une possibilité
utile et utilisée sous tous les OS, c'est un fait, et c'est très bien
comme ça.
/Applications est système ? selon Apple, non, le domaine système c'est
/System, qui ne doit pas être touché sauf pour les extensions.
Ben justement, quand un installeur te demande les droits admins, tu n'as
aucun moyen de savoir s'il va taper seulement dans /Applications ou s'il
va aussi aller dans /System
Je ne vois pas de différence, comme je l'ai dit. Mon système n'a aucune
valeur pour moi, il est remplaçable à l'envie. Mes données elles, par
contre, ont un grand intérêt et le principe des moindres privilèges ne
peut pas les protéger.
Pour moi le système a de la valeur, car si j'ai des problèmes avec,
c'est du temps de perdu.
Ce n'est pas parce qu'il est facilement remplacable (au contraire des
données) que je n'y fais pas attention.
Ah ? tu me fais une démo du "plus facile à débusquer s'il n'a que les
droits utilisateur" ? parce que s'il tourne, je vois à peu près (encore
que rien ne lui interdit d'embarquer un binaire setuid...) et s'il ne
tourne pas tu ne verras même pas qu'il est installé vu que tu risques de
ne pas avoir accès à l'élément das le dossier départ de l'utilisateur.
Le binaire suid ne va pas faire grand chose si le code malveillant n'a
que des droits utilisateur depuis le début.
Certes, tu peux mettre le bit à 1, mais tu ne peux pas changer le
propriétaire, donc il tournera toujours en utilisateur.
Pour ce qui est du reste, les rootkits ne sont pas rares.
Typiquement ils changent le système de telle manière à ce que netstat,
ls, le Finder, etc. ne montrent pas les fichiers ou les process
malveillants.
Ces techniques de rootkits ne marchent que si le code malveillant a un
accès root à un moment ou à un autre (dès qu'il l'a, il peut se mettre
en setuid et se camoufler).
Je ne comprends pas la toute dernière partie de ton message.
Si tu as un doute sur la présence de code malveillant, mais que par
contre tu es sûr qu'il n'a jamais eu les droits admins, il suffit de se
logger en admin, et d'aller voir dans le répertoire de l'utilisateur ce
qui s'y passe, ou de démarrer netstat ou le moniteur d'activité pour
analyser tout ça.
De manière générale, il est clair sous MacOS X qu'il est *techniquement*
possible de faire des applications complexes sans installeur ni droits
admins.
Ca ne t'arrange pas car cela va à l'encontre de ta politique
d'administration, soit, mais pour d'autres, c'est une fonctionnalité
utile et utilisée.
J'ai l'impression que ce qu'il te faut, c'est un système efficace et
bien pensé pour limiter les applications utilisées, dont l'usage serait
optionel (ca existe pas ça d'ailleurs?)
Mais dire que le problème peut-être réglé en exigeant les droits admins
pour toutes les installations, c'est oublier que ça retire des
possibilités à ceux qui n'ont pas le même cahier des charges, et qui
voient ça comme une fonctionnalité.
Laurent Pertois wrote, On 30/12/07 12:02:
<sarcastique>
Zut, tu as effacé les utilisateurs système ?
</sarcastique>
Je démarre toujours en utilisateur. J'ai du me logger 2 fois en admin en
1 an peut-être.
Question de point de vue, perso, si un installeur est rigide, je le
laisse faire sans me poser de questions.
Moi je rale et j'essaie de contourner :)
Ce n'est pas une question d'influencer, c'est une question de légalité.
Et puis, c'est le boulot de l'admin de faire ça, pas des utilisateurs,
enfin, àmha.
Ca dépend des politiques.
Dans les grandes boites, elles sont souvent tellement rigides que tu es
obligé d'installer des outils gratuits pour être efficace.
Par exemple, si tu veux faire quelques retouches minimes à une image
dans une grande structure (sous Windows pour l'exemple), tu as le choix
entre:
1. le procédé officiel avec un outil commercial
a) faire faire un devis
b) le faire valider par le département/la direction
c) passer la commande
d) faire valider l'outil par les admins
e) faire installer l'outil par les admins
Effort: 1 journée de boulot
Délai: 2 semaines (optimiste)
2. installer Paint.NET en tant qu'utilisateur
Effort: 10min
Délai: 10min
C'est un exemple vécu et courant.
La solution 2 est éventuellement interdite par la charte, mais tout le
monde le fait, et les admins ne disent rien quand ils le voient. Ils
savent bien que c'est la solution raisonnable, et que la voie officielle
ne vaut le coup que pour les usages importants et à long terme.
Bien sûr, il y a d'autres modes d'administration, typiquement dans les
PME PMI, où l'administrateur/administration est plus flexible et les
temps de réaction sont plus courts.
J'ai l'impression que c'est ton cas et que c'est la base de ton
raisonnement. C'est peut-être un mode d'administration plus courant dans
le monde Mac, mais c'est loin d'être la règle.
Pouvoir installer des outils en tant qu'utilisateur est une possibilité
utile et utilisée sous tous les OS, c'est un fait, et c'est très bien
comme ça.
/Applications est système ? selon Apple, non, le domaine système c'est
/System, qui ne doit pas être touché sauf pour les extensions.
Ben justement, quand un installeur te demande les droits admins, tu n'as
aucun moyen de savoir s'il va taper seulement dans /Applications ou s'il
va aussi aller dans /System
Je ne vois pas de différence, comme je l'ai dit. Mon système n'a aucune
valeur pour moi, il est remplaçable à l'envie. Mes données elles, par
contre, ont un grand intérêt et le principe des moindres privilèges ne
peut pas les protéger.
Pour moi le système a de la valeur, car si j'ai des problèmes avec,
c'est du temps de perdu.
Ce n'est pas parce qu'il est facilement remplacable (au contraire des
données) que je n'y fais pas attention.
Ah ? tu me fais une démo du "plus facile à débusquer s'il n'a que les
droits utilisateur" ? parce que s'il tourne, je vois à peu près (encore
que rien ne lui interdit d'embarquer un binaire setuid...) et s'il ne
tourne pas tu ne verras même pas qu'il est installé vu que tu risques de
ne pas avoir accès à l'élément das le dossier départ de l'utilisateur.
Le binaire suid ne va pas faire grand chose si le code malveillant n'a
que des droits utilisateur depuis le début.
Certes, tu peux mettre le bit à 1, mais tu ne peux pas changer le
propriétaire, donc il tournera toujours en utilisateur.
Pour ce qui est du reste, les rootkits ne sont pas rares.
Typiquement ils changent le système de telle manière à ce que netstat,
ls, le Finder, etc. ne montrent pas les fichiers ou les process
malveillants.
Ces techniques de rootkits ne marchent que si le code malveillant a un
accès root à un moment ou à un autre (dès qu'il l'a, il peut se mettre
en setuid et se camoufler).
Je ne comprends pas la toute dernière partie de ton message.
Si tu as un doute sur la présence de code malveillant, mais que par
contre tu es sûr qu'il n'a jamais eu les droits admins, il suffit de se
logger en admin, et d'aller voir dans le répertoire de l'utilisateur ce
qui s'y passe, ou de démarrer netstat ou le moniteur d'activité pour
analyser tout ça.
De manière générale, il est clair sous MacOS X qu'il est *techniquement*
possible de faire des applications complexes sans installeur ni droits
admins.
Ca ne t'arrange pas car cela va à l'encontre de ta politique
d'administration, soit, mais pour d'autres, c'est une fonctionnalité
utile et utilisée.
J'ai l'impression que ce qu'il te faut, c'est un système efficace et
bien pensé pour limiter les applications utilisées, dont l'usage serait
optionel (ca existe pas ça d'ailleurs?)
Mais dire que le problème peut-être réglé en exigeant les droits admins
pour toutes les installations, c'est oublier que ça retire des
possibilités à ceux qui n'ont pas le même cahier des charges, et qui
voient ça comme une fonctionnalité.
Laurent Pertois wrote, On 30/12/07 12:02:<sarcastique>
Zut, tu as effacé les utilisateurs système ?
</sarcastique>
Je démarre toujours en utilisateur. J'ai du me logger 2 fois en admin en
1 an peut-être.
Question de point de vue, perso, si un installeur est rigide, je le
laisse faire sans me poser de questions.
Moi je rale et j'essaie de contourner :)
Ce n'est pas une question d'influencer, c'est une question de légalité.
Et puis, c'est le boulot de l'admin de faire ça, pas des utilisateurs,
enfin, àmha.
Ca dépend des politiques.
Dans les grandes boites, elles sont souvent tellement rigides que tu es
obligé d'installer des outils gratuits pour être efficace.
Par exemple, si tu veux faire quelques retouches minimes à une image
dans une grande structure (sous Windows pour l'exemple), tu as le choix
entre:
1. le procédé officiel avec un outil commercial
a) faire faire un devis
b) le faire valider par le département/la direction
c) passer la commande
d) faire valider l'outil par les admins
e) faire installer l'outil par les admins
Effort: 1 journée de boulot
Délai: 2 semaines (optimiste)
2. installer Paint.NET en tant qu'utilisateur
Effort: 10min
Délai: 10min
C'est un exemple vécu et courant.
La solution 2 est éventuellement interdite par la charte, mais tout le
monde le fait, et les admins ne disent rien quand ils le voient. Ils
savent bien que c'est la solution raisonnable, et que la voie officielle
ne vaut le coup que pour les usages importants et à long terme.
Bien sûr, il y a d'autres modes d'administration, typiquement dans les
PME PMI, où l'administrateur/administration est plus flexible et les
temps de réaction sont plus courts.
J'ai l'impression que c'est ton cas et que c'est la base de ton
raisonnement. C'est peut-être un mode d'administration plus courant dans
le monde Mac, mais c'est loin d'être la règle.
Pouvoir installer des outils en tant qu'utilisateur est une possibilité
utile et utilisée sous tous les OS, c'est un fait, et c'est très bien
comme ça.
/Applications est système ? selon Apple, non, le domaine système c'est
/System, qui ne doit pas être touché sauf pour les extensions.
Ben justement, quand un installeur te demande les droits admins, tu n'as
aucun moyen de savoir s'il va taper seulement dans /Applications ou s'il
va aussi aller dans /System
Je ne vois pas de différence, comme je l'ai dit. Mon système n'a aucune
valeur pour moi, il est remplaçable à l'envie. Mes données elles, par
contre, ont un grand intérêt et le principe des moindres privilèges ne
peut pas les protéger.
Pour moi le système a de la valeur, car si j'ai des problèmes avec,
c'est du temps de perdu.
Ce n'est pas parce qu'il est facilement remplacable (au contraire des
données) que je n'y fais pas attention.
Ah ? tu me fais une démo du "plus facile à débusquer s'il n'a que les
droits utilisateur" ? parce que s'il tourne, je vois à peu près (encore
que rien ne lui interdit d'embarquer un binaire setuid...) et s'il ne
tourne pas tu ne verras même pas qu'il est installé vu que tu risques de
ne pas avoir accès à l'élément das le dossier départ de l'utilisateur.
Le binaire suid ne va pas faire grand chose si le code malveillant n'a
que des droits utilisateur depuis le début.
Certes, tu peux mettre le bit à 1, mais tu ne peux pas changer le
propriétaire, donc il tournera toujours en utilisateur.
Pour ce qui est du reste, les rootkits ne sont pas rares.
Typiquement ils changent le système de telle manière à ce que netstat,
ls, le Finder, etc. ne montrent pas les fichiers ou les process
malveillants.
Ces techniques de rootkits ne marchent que si le code malveillant a un
accès root à un moment ou à un autre (dès qu'il l'a, il peut se mettre
en setuid et se camoufler).
Je ne comprends pas la toute dernière partie de ton message.
Si tu as un doute sur la présence de code malveillant, mais que par
contre tu es sûr qu'il n'a jamais eu les droits admins, il suffit de se
logger en admin, et d'aller voir dans le répertoire de l'utilisateur ce
qui s'y passe, ou de démarrer netstat ou le moniteur d'activité pour
analyser tout ça.
De manière générale, il est clair sous MacOS X qu'il est *techniquement*
possible de faire des applications complexes sans installeur ni droits
admins.
Ca ne t'arrange pas car cela va à l'encontre de ta politique
d'administration, soit, mais pour d'autres, c'est une fonctionnalité
utile et utilisée.
J'ai l'impression que ce qu'il te faut, c'est un système efficace et
bien pensé pour limiter les applications utilisées, dont l'usage serait
optionel (ca existe pas ça d'ailleurs?)
Mais dire que le problème peut-être réglé en exigeant les droits admins
pour toutes les installations, c'est oublier que ça retire des
possibilités à ceux qui n'ont pas le même cahier des charges, et qui
voient ça comme une fonctionnalité.
Mais là, ils ne disent rien parce que le contournement n'est pas un
piratage, mais s'il avait fallu pirater, tu crois que ça passerait aussi
bien ?
Pour moi le système a de la valeur, car si j'ai des problèmes avec,
c'est du temps de perdu.
Ca se restaure.
Ce n'est pas parce qu'il est facilement remplacable (au contraire des
données) que je n'y fais pas attention.
Oui, mais je tiens quand même plus à mes données.
Ah ? tu me fais une démo du "plus facile à débusquer s'il n'a que les
droits utilisateur" ? parce que s'il tourne, je vois à peu près (encore
que rien ne lui interdit d'embarquer un binaire setuid...) et s'il ne
tourne pas tu ne verras même pas qu'il est installé vu que tu risques de
ne pas avoir accès à l'élément das le dossier départ de l'utilisateur.
Le binaire suid ne va pas faire grand chose si le code malveillant n'a
que des droits utilisateur depuis le début.
Alors, si je lance passwd depuis mon shell il ne va pas modifier le mot
de passe de l'utilisateur dans un fichier réservé à root ?
Certes, tu peux mettre le bit à 1, mais tu ne peux pas changer le
propriétaire, donc il tournera toujours en utilisateur.
Rien n'oblige à ce que le binaire soit la propriété de l'utilisateur
courant, si l'installeur te permet de le placer dans ton dossier départ
mais le copie tel quel avec comme propriétaire root, il appartiendra à
root.
Pour ce qui est du reste, les rootkits ne sont pas rares.
Typiquement ils changent le système de telle manière à ce que netstat,
ls, le Finder, etc. ne montrent pas les fichiers ou les process
malveillants.
Ces techniques de rootkits ne marchent que si le code malveillant a un
accès root à un moment ou à un autre (dès qu'il l'a, il peut se mettre
en setuid et se camoufler).
Et un installeur ne peut pas l'avoir peut-être ?
Si tu as un doute sur la présence de code malveillant, mais que par
contre tu es sûr qu'il n'a jamais eu les droits admins, il suffit de se
logger en admin, et d'aller voir dans le répertoire de l'utilisateur ce
qui s'y passe, ou de démarrer netstat ou le moniteur d'activité pour
analyser tout ça.
Parce qu'un admin peut aller voir chez un utilisateur sans prendre des
droits root même temporairement ?
Mais là, ils ne disent rien parce que le contournement n'est pas un
piratage, mais s'il avait fallu pirater, tu crois que ça passerait aussi
bien ?
Pour moi le système a de la valeur, car si j'ai des problèmes avec,
c'est du temps de perdu.
Ca se restaure.
Ce n'est pas parce qu'il est facilement remplacable (au contraire des
données) que je n'y fais pas attention.
Oui, mais je tiens quand même plus à mes données.
Ah ? tu me fais une démo du "plus facile à débusquer s'il n'a que les
droits utilisateur" ? parce que s'il tourne, je vois à peu près (encore
que rien ne lui interdit d'embarquer un binaire setuid...) et s'il ne
tourne pas tu ne verras même pas qu'il est installé vu que tu risques de
ne pas avoir accès à l'élément das le dossier départ de l'utilisateur.
Le binaire suid ne va pas faire grand chose si le code malveillant n'a
que des droits utilisateur depuis le début.
Alors, si je lance passwd depuis mon shell il ne va pas modifier le mot
de passe de l'utilisateur dans un fichier réservé à root ?
Certes, tu peux mettre le bit à 1, mais tu ne peux pas changer le
propriétaire, donc il tournera toujours en utilisateur.
Rien n'oblige à ce que le binaire soit la propriété de l'utilisateur
courant, si l'installeur te permet de le placer dans ton dossier départ
mais le copie tel quel avec comme propriétaire root, il appartiendra à
root.
Pour ce qui est du reste, les rootkits ne sont pas rares.
Typiquement ils changent le système de telle manière à ce que netstat,
ls, le Finder, etc. ne montrent pas les fichiers ou les process
malveillants.
Ces techniques de rootkits ne marchent que si le code malveillant a un
accès root à un moment ou à un autre (dès qu'il l'a, il peut se mettre
en setuid et se camoufler).
Et un installeur ne peut pas l'avoir peut-être ?
Si tu as un doute sur la présence de code malveillant, mais que par
contre tu es sûr qu'il n'a jamais eu les droits admins, il suffit de se
logger en admin, et d'aller voir dans le répertoire de l'utilisateur ce
qui s'y passe, ou de démarrer netstat ou le moniteur d'activité pour
analyser tout ça.
Parce qu'un admin peut aller voir chez un utilisateur sans prendre des
droits root même temporairement ?
Mais là, ils ne disent rien parce que le contournement n'est pas un
piratage, mais s'il avait fallu pirater, tu crois que ça passerait aussi
bien ?
Pour moi le système a de la valeur, car si j'ai des problèmes avec,
c'est du temps de perdu.
Ca se restaure.
Ce n'est pas parce qu'il est facilement remplacable (au contraire des
données) que je n'y fais pas attention.
Oui, mais je tiens quand même plus à mes données.
Ah ? tu me fais une démo du "plus facile à débusquer s'il n'a que les
droits utilisateur" ? parce que s'il tourne, je vois à peu près (encore
que rien ne lui interdit d'embarquer un binaire setuid...) et s'il ne
tourne pas tu ne verras même pas qu'il est installé vu que tu risques de
ne pas avoir accès à l'élément das le dossier départ de l'utilisateur.
Le binaire suid ne va pas faire grand chose si le code malveillant n'a
que des droits utilisateur depuis le début.
Alors, si je lance passwd depuis mon shell il ne va pas modifier le mot
de passe de l'utilisateur dans un fichier réservé à root ?
Certes, tu peux mettre le bit à 1, mais tu ne peux pas changer le
propriétaire, donc il tournera toujours en utilisateur.
Rien n'oblige à ce que le binaire soit la propriété de l'utilisateur
courant, si l'installeur te permet de le placer dans ton dossier départ
mais le copie tel quel avec comme propriétaire root, il appartiendra à
root.
Pour ce qui est du reste, les rootkits ne sont pas rares.
Typiquement ils changent le système de telle manière à ce que netstat,
ls, le Finder, etc. ne montrent pas les fichiers ou les process
malveillants.
Ces techniques de rootkits ne marchent que si le code malveillant a un
accès root à un moment ou à un autre (dès qu'il l'a, il peut se mettre
en setuid et se camoufler).
Et un installeur ne peut pas l'avoir peut-être ?
Si tu as un doute sur la présence de code malveillant, mais que par
contre tu es sûr qu'il n'a jamais eu les droits admins, il suffit de se
logger en admin, et d'aller voir dans le répertoire de l'utilisateur ce
qui s'y passe, ou de démarrer netstat ou le moniteur d'activité pour
analyser tout ça.
Parce qu'un admin peut aller voir chez un utilisateur sans prendre des
droits root même temporairement ?
Laurent Pertois wrote, On 30/12/07 14:11:Mais là, ils ne disent rien parce que le contournement n'est pas un
piratage, mais s'il avait fallu pirater, tu crois que ça passerait aussi
bien ?
Bien sûr que non, mais ça n'a rien à voir avec le sujet initial.
Pour moi le système a de la valeur, car si j'ai des problèmes avec,
c'est du temps de perdu.
Ca se restaure.
Les données aussi.
Ce que je dis, c'est que c'est une perte de temps.
Ce n'est pas parce qu'il est facilement remplacable (au contraire des
données) que je n'y fais pas attention.
Oui, mais je tiens quand même plus à mes données.
Moi aussi, mais a < b n'implique pas a = 0.
Alors, si je lance passwd depuis mon shell il ne va pas modifier le mot
de passe de l'utilisateur dans un fichier réservé à root ?
Je ne vois pas le rapport.
Les setuid root de l'OS (comme passwd) sont connus, audités en long en
large et en travers, et tous a priori sûrs.
Rien n'oblige à ce que le binaire soit la propriété de l'utilisateur
courant, si l'installeur te permet de le placer dans ton dossier départ
mais le copie tel quel avec comme propriétaire root, il appartiendra à
root.
Si l'installeur et le logiciel tournent en utilisateur depuis le début
(mon hypothèse ci-dessus), à aucun moment aucun des deux ne pourra créer
son propre programme setuid root sur le système.
Pour créer un setuid root, il faut être root.
Et un installeur ne peut pas l'avoir peut-être ?
Je comprends pas où tu veux en venir.
Ce que je dis, c'est que si à aucun moment l'installeur ou le logiciel
ne demandent le mot de passe admin, les techniques de rootkit sont
inaccessibles, d'où de bien meilleures possibilités d'analyses en cas de
compromission.
Un compte est compromis, mais le système est sain.
Parce qu'un admin peut aller voir chez un utilisateur sans prendre des
droits root même temporairement ?
Ben non, mais je vois pas le rapport.
Je dis que si tu penses qu'un compte utilisateur est compromis, tu te
logges en tant qu'admin, et tu peux analyser ce qui se passe sur une
base saine (à coup de sudo typiquement).
Je n'ai jamais dit que tu n'avais pas besoin de root, juste que le
compte admin sert de plate-forme saine, et que les outils systèmes sont
dignes de confiance, ce qui n'est pas le cas si l'installeur ou le
logiciel ont eu un mot de passe admin à un moment ou à un autre.
Laurent Pertois wrote, On 30/12/07 14:11:
Mais là, ils ne disent rien parce que le contournement n'est pas un
piratage, mais s'il avait fallu pirater, tu crois que ça passerait aussi
bien ?
Bien sûr que non, mais ça n'a rien à voir avec le sujet initial.
Pour moi le système a de la valeur, car si j'ai des problèmes avec,
c'est du temps de perdu.
Ca se restaure.
Les données aussi.
Ce que je dis, c'est que c'est une perte de temps.
Ce n'est pas parce qu'il est facilement remplacable (au contraire des
données) que je n'y fais pas attention.
Oui, mais je tiens quand même plus à mes données.
Moi aussi, mais a < b n'implique pas a = 0.
Alors, si je lance passwd depuis mon shell il ne va pas modifier le mot
de passe de l'utilisateur dans un fichier réservé à root ?
Je ne vois pas le rapport.
Les setuid root de l'OS (comme passwd) sont connus, audités en long en
large et en travers, et tous a priori sûrs.
Rien n'oblige à ce que le binaire soit la propriété de l'utilisateur
courant, si l'installeur te permet de le placer dans ton dossier départ
mais le copie tel quel avec comme propriétaire root, il appartiendra à
root.
Si l'installeur et le logiciel tournent en utilisateur depuis le début
(mon hypothèse ci-dessus), à aucun moment aucun des deux ne pourra créer
son propre programme setuid root sur le système.
Pour créer un setuid root, il faut être root.
Et un installeur ne peut pas l'avoir peut-être ?
Je comprends pas où tu veux en venir.
Ce que je dis, c'est que si à aucun moment l'installeur ou le logiciel
ne demandent le mot de passe admin, les techniques de rootkit sont
inaccessibles, d'où de bien meilleures possibilités d'analyses en cas de
compromission.
Un compte est compromis, mais le système est sain.
Parce qu'un admin peut aller voir chez un utilisateur sans prendre des
droits root même temporairement ?
Ben non, mais je vois pas le rapport.
Je dis que si tu penses qu'un compte utilisateur est compromis, tu te
logges en tant qu'admin, et tu peux analyser ce qui se passe sur une
base saine (à coup de sudo typiquement).
Je n'ai jamais dit que tu n'avais pas besoin de root, juste que le
compte admin sert de plate-forme saine, et que les outils systèmes sont
dignes de confiance, ce qui n'est pas le cas si l'installeur ou le
logiciel ont eu un mot de passe admin à un moment ou à un autre.
Laurent Pertois wrote, On 30/12/07 14:11:Mais là, ils ne disent rien parce que le contournement n'est pas un
piratage, mais s'il avait fallu pirater, tu crois que ça passerait aussi
bien ?
Bien sûr que non, mais ça n'a rien à voir avec le sujet initial.
Pour moi le système a de la valeur, car si j'ai des problèmes avec,
c'est du temps de perdu.
Ca se restaure.
Les données aussi.
Ce que je dis, c'est que c'est une perte de temps.
Ce n'est pas parce qu'il est facilement remplacable (au contraire des
données) que je n'y fais pas attention.
Oui, mais je tiens quand même plus à mes données.
Moi aussi, mais a < b n'implique pas a = 0.
Alors, si je lance passwd depuis mon shell il ne va pas modifier le mot
de passe de l'utilisateur dans un fichier réservé à root ?
Je ne vois pas le rapport.
Les setuid root de l'OS (comme passwd) sont connus, audités en long en
large et en travers, et tous a priori sûrs.
Rien n'oblige à ce que le binaire soit la propriété de l'utilisateur
courant, si l'installeur te permet de le placer dans ton dossier départ
mais le copie tel quel avec comme propriétaire root, il appartiendra à
root.
Si l'installeur et le logiciel tournent en utilisateur depuis le début
(mon hypothèse ci-dessus), à aucun moment aucun des deux ne pourra créer
son propre programme setuid root sur le système.
Pour créer un setuid root, il faut être root.
Et un installeur ne peut pas l'avoir peut-être ?
Je comprends pas où tu veux en venir.
Ce que je dis, c'est que si à aucun moment l'installeur ou le logiciel
ne demandent le mot de passe admin, les techniques de rootkit sont
inaccessibles, d'où de bien meilleures possibilités d'analyses en cas de
compromission.
Un compte est compromis, mais le système est sain.
Parce qu'un admin peut aller voir chez un utilisateur sans prendre des
droits root même temporairement ?
Ben non, mais je vois pas le rapport.
Je dis que si tu penses qu'un compte utilisateur est compromis, tu te
logges en tant qu'admin, et tu peux analyser ce qui se passe sur une
base saine (à coup de sudo typiquement).
Je n'ai jamais dit que tu n'avais pas besoin de root, juste que le
compte admin sert de plate-forme saine, et que les outils systèmes sont
dignes de confiance, ce qui n'est pas le cas si l'installeur ou le
logiciel ont eu un mot de passe admin à un moment ou à un autre.
Par exemple, si tu veux faire quelques retouches minimes à une image
dans une grande structure (sous Windows pour l'exemple), tu as le choix
entre:
1. le procédé officiel avec un outil commercial
a) faire faire un devis
b) le faire valider par le département/la direction
c) passer la commande
d) faire valider l'outil par les admins
e) faire installer l'outil par les admins
Effort: 1 journée de boulot
Délai: 2 semaines (optimiste)
2. installer Paint.NET en tant qu'utilisateur
Effort: 10min
Délai: 10min
C'est un exemple vécu et courant.
La solution 2 est éventuellement interdite par la charte, mais tout le
monde le fait, et les admins ne disent rien quand ils le voient. Ils
savent bien que c'est la solution raisonnable, et que la voie officielle
ne vaut le coup que pour les usages importants et à long terme.
Par exemple, si tu veux faire quelques retouches minimes à une image
dans une grande structure (sous Windows pour l'exemple), tu as le choix
entre:
1. le procédé officiel avec un outil commercial
a) faire faire un devis
b) le faire valider par le département/la direction
c) passer la commande
d) faire valider l'outil par les admins
e) faire installer l'outil par les admins
Effort: 1 journée de boulot
Délai: 2 semaines (optimiste)
2. installer Paint.NET en tant qu'utilisateur
Effort: 10min
Délai: 10min
C'est un exemple vécu et courant.
La solution 2 est éventuellement interdite par la charte, mais tout le
monde le fait, et les admins ne disent rien quand ils le voient. Ils
savent bien que c'est la solution raisonnable, et que la voie officielle
ne vaut le coup que pour les usages importants et à long terme.
Par exemple, si tu veux faire quelques retouches minimes à une image
dans une grande structure (sous Windows pour l'exemple), tu as le choix
entre:
1. le procédé officiel avec un outil commercial
a) faire faire un devis
b) le faire valider par le département/la direction
c) passer la commande
d) faire valider l'outil par les admins
e) faire installer l'outil par les admins
Effort: 1 journée de boulot
Délai: 2 semaines (optimiste)
2. installer Paint.NET en tant qu'utilisateur
Effort: 10min
Délai: 10min
C'est un exemple vécu et courant.
La solution 2 est éventuellement interdite par la charte, mais tout le
monde le fait, et les admins ne disent rien quand ils le voient. Ils
savent bien que c'est la solution raisonnable, et que la voie officielle
ne vaut le coup que pour les usages importants et à long terme.
la vraie solution utilisée dans 95% des cas c'est de faire les retouches
d'image dans Word.
la vraie solution utilisée dans 95% des cas c'est de faire les retouches
d'image dans Word.
la vraie solution utilisée dans 95% des cas c'est de faire les retouches
d'image dans Word.
Et si l'installeur est lui-même dans une image-disque avec droits
activés avec un binaire suid qui installe des éléments ?
Et un installeur ne peut pas l'avoir peut-être ?
Je comprends pas où tu veux en venir.
Ben, si l'installeur est lui-même suid, il va faire ce qu'il veut même
s'il pose des éléments chez toi.
Pas sûr, le bundle de l'installeur peut contenir lui-même un script suid
qui sera exécuté pendant l'installation.
Un compte est compromis, mais le système est sain.
Ah ? et si ce compte contient des informations importantes qui sont
ensuite envoyées ailleurs, c'est moins grave que de perdre le système ?
Et si l'installeur est lui-même dans une image-disque avec droits
activés avec un binaire suid qui installe des éléments ?
Et un installeur ne peut pas l'avoir peut-être ?
Je comprends pas où tu veux en venir.
Ben, si l'installeur est lui-même suid, il va faire ce qu'il veut même
s'il pose des éléments chez toi.
Pas sûr, le bundle de l'installeur peut contenir lui-même un script suid
qui sera exécuté pendant l'installation.
Un compte est compromis, mais le système est sain.
Ah ? et si ce compte contient des informations importantes qui sont
ensuite envoyées ailleurs, c'est moins grave que de perdre le système ?
Et si l'installeur est lui-même dans une image-disque avec droits
activés avec un binaire suid qui installe des éléments ?
Et un installeur ne peut pas l'avoir peut-être ?
Je comprends pas où tu veux en venir.
Ben, si l'installeur est lui-même suid, il va faire ce qu'il veut même
s'il pose des éléments chez toi.
Pas sûr, le bundle de l'installeur peut contenir lui-même un script suid
qui sera exécuté pendant l'installation.
Un compte est compromis, mais le système est sain.
Ah ? et si ce compte contient des informations importantes qui sont
ensuite envoyées ailleurs, c'est moins grave que de perdre le système ?