Plusieurs utilisateurs Root
Thierry Leurent
J'ai un système Linux sur le plusieurs sociètés peuvent intervenir à un
moment ou un autre.
Je voudrais différencier les actions que font ces différentes personnes.
La machine n'étant pas encore en production tout le monde utilise Root,
mais dans le futur, je voudrais que chaque personne ayant des droits
d'administration utilise son propre identifiant.
Pour l'instant, j'ai crée un utilisateur root2 ayant comme groupe primaire
root. Mais je constate que beaucoups de fichiers de config sont uniquement
lisible et modifiable par l'utilisateur root et par personne d'autre.
Je pourrais utiliser root pour donner plus de permission mais je me
demande si il n'existe pas d'autres problèmes liés à cet utilisateur comme
un script qui vérifierait les droits d'un fichier.
Je ne sais pas si quelqu'un parmis vous à déjà mis en place ce genre de
solution.
Des idées, des retours d'expérience ?
Merci
--
Thierry Leurent
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/DebFrFrenchLists
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to debian-user-f...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Basile STARYNKEVITCH
> Bonjour,
>
> J'ai un système Linux sur le plusieurs sociètés peuvent intervenir à un
> moment ou un autre.
>
> Je voudrais différencier les actions que font ces différentes personnes.
raison.
Mais le principal problème demeure la tracabilité. J'ai un peu du mal à
comprendre que l'administration d'un serveur de production soit confié à
plusieurs sociétés différentes. De mon point de vue, c'est courir vers
de serieux ennuis. Qui sera responsable des pepins?
J'ai même du mal à comprendre que des prestataires puissent accepter celà.
Librement.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
membre de l'APRIL "promouvoir et défendre le logiciel libre"
Rejoignez maitenant pplus de 3900 adhérents http://www.april.org
Kevin Hinault
<thierry...@asgardian.be> a écrit :
> Des idées, des retours d'expérience ?
Bonjour,
A mon avis, la solution sudo est plus ce que vous recherchez : ce sera
beaucoup plus souple que les groupe.
http://fr.wikipedia.org/wiki/Sudo
http://www.lea-linux.org/cached/index/Admin-admin_env-sudo.html
Kévin
Grégory Bulot
2009 14:32:28 +0100 (CET)
> Bonjour,
>
> J'ai un système Linux sur le plusieurs sociètés peuvent intervenir à
> un moment ou un autre.
>
> Je voudrais différencier les actions que font ces différentes
> personnes. La machine n'étant pas encore en production tout le monde
> utilise Root, mais dans le futur, je voudrais que chaque personne
> ayant des droits d'administration utilise son propre identifiant.
>
> Pour l'instant, j'ai crée un utilisateur root2 ayant comme groupe
> primaire root. Mais je constate que beaucoups de fichiers de config
> sont uniquement lisible et modifiable par l'utilisateur root et par
> personne d'autre.
dans /etc/passwd, pour mon 2ieme utilisateurs 'comme root' j'ai fait :
admin:x:0:0:Admin local,,,:/home/admin:/bin/bash
ça permet de désactiver son mot de passe si besoin était, sans toucher
aux uid/gid
je ne trouve pas ça très 'jolis' mais ça marche
--
Cordialement
Grégory BULOT
Etienne CROMBEZ
Bonjour,
J'ai un système Linux sur le plusieurs sociètés peuvent intervenir à un
moment ou un autre.
Je voudrais différencier les actions que font ces différentes personnes.
La machine n'étant pas encore en production tout le monde utilise Root,
mais dans le futur, je voudrais que chaque personne ayant des droits
d'administration utilise son propre identifiant.
Dradge
Sudo ne ferait-il pas l'affaire ?
Bonne journée
Thierry Leurent
encore la configurer.
Pourquois confier l'administration d'une machine de prod à plusieurs
sociètés ?
Simplement qu'elle ont en charge une partie des logitiels présents et
qu'il est probabale qu'un jour ou l'autre, elles devront effectuer des
opérations de maintenance sur leurs produits ou pour d'autres opérations.
Si je contente de leur donner le root, je ne peux pas les coller toute la
journée pour voir ce qu'ils font.
Je veux :
- Limiter leur pouvoir sur la machine à leur application et
eventuellement d'autres éléments périphériques.
- Tracer leur modifications.
- Libérer l'accès de ces users en fonction des besoins.
Plusieurs personnes internes peuvent également administrer la machine et
je préfère mettre en place une solution pour différencier l'action de
chacun.
Basile STARYNKEVITCH a écrit :
--
Thierry Leurent
Phone : +32 476/20.23.98
E-mail : thierry...@asgardian.be
Website (en developpement) : http://www.asgardian.be
François TOURDE
Thierry Leurent écrivait:
> Merci à tous, il semble que sudo est la commande idéale mais il faut
> encore la configurer.
Mais attention, si tu dois arbitrer un jour le fait que tel ou tel
prestataire a modifié tel ou tel fichier, ça va pas forcément être
simple.
> Pourquois confier l'administration d'une machine de prod à plusieurs
> sociètés ?
> Simplement qu'elle ont en charge une partie des logitiels présents et
> qu'il est probabale qu'un jour ou l'autre, elles devront effectuer des
> opérations de maintenance sur leurs produits ou pour d'autres
> opérations.
Je ne comprends pas non plus que ces sociétés aient accepté d'assurer
la maintenance applicative (avec accès root oO) à plusieurs.
A mon avis, il serait préférable de leur donner accès à chacune à leur
zone applicative bien cloisonnée, et garder l'accès root à une seule
personne.
Même au sein d'une seule boite, et pour des admins assez proches, je
me souviens avoir mis en place un mécanisme de configuration à l'aide
de CVS, de commits, et d'un ou deux petits scripts cron pour
l'implantation des droits/privilèges des fichiers de config.
Après, libre à toi de faire ce que tu veux, mais bon...
Yves Rutschle
> A mon avis, il serait préférable de leur donner accès à chacune à leur
> zone applicative bien cloisonnée, et garder l'accès root à une seule
> personne.
Ouaip, et si l'accès root est indispensable, déplacer chaque
serveur dans une machine virtuelle, une machine virtuelle
par boite.
Y.
Frédéric Massot
> Merci à tous, il semble que sudo est la commande idéale mais il faut
> encore la configurer.
>
> Pourquois confier l'administration d'une machine de prod à plusieurs
> sociètés ?
> Simplement qu'elle ont en charge une partie des logitiels présents et
> qu'il est probabale qu'un jour ou l'autre, elles devront effectuer des
> opérations de maintenance sur leurs produits ou pour d'autres opérations.
>
> Si je contente de leur donner le root, je ne peux pas les coller toute la
> journée pour voir ce qu'ils font.
> Je veux :
> - Limiter leur pouvoir sur la machine à leur application et
> eventuellement d'autres éléments périphériques.
> - Tracer leur modifications.
sudo enregistre les actions dans le fichier /var/log/auth.log
Maintenant, il faut bien configurer sudo.
--
==============================================
| FRÉDÉRIC MASSOT |
| http://www.juliana-multimedia.com |
| mailto:fred...@juliana-multimedia.com |
===========================Debian=GNU/Linux===
Thierry Leurent
- Les roots dédiés ne seront activés qu'a la demande.
- Je verrai qui a modifié un fichier et quand.
- Je voudrais utiliser svn pour stocker les modifs.
Les machines ont été achetées clé en main à une socièté qui sous-traite mais
nous remarquons qu'ils ont certains problèmes au niveau des délais, que les
applis ne sont pas testées et que la socièté maitre d'oeuvre ne fait pas son
boulot de coordination. Donc les sous-traitants passent pas nous directement.
Nous avons peur que si un de socièté doit faire une modif qu'elle fasse des
conneries et que le système se plante. Nous avons des données très
confidentielles et des règles très stictes a appliquer.
Je compte définir plusieurs types d'admin. Les admins internes des roots avec
d'autres nom afin de tracer qui fait quoi, des admins externes limités au
domaine de leur boite et des admins internes restreint pour les backup, et
d'autres choses.
Comme nous avons 2 systèmes identiques, 1 de test et 1 de prod, il va falloir
mettre en place toute une politique au niveau des développeur et des mises en
prods. Mais ça, je dois encore voir.
Je pensais a svn pour stocker l'historique des modifs mais j'ai pas encore
approfondit la chose. Il sera mis en place pour le devel.
Puppet serait peut-être une solution aussi a voir.
--
---
Thierry Leurent
Cornichon
> On Fri, Jan 09, 2009 at 03:46:50PM +0100, François TOURDE wrote:
>> A mon avis, il serait préférable de leur donner accès à chacune à leur
>> zone applicative bien cloisonnée, et garder l'accès root à une seule
>> personne.
>
> Ouaip, et si l'accès root est indispensable, déplacer chaque
> serveur dans une machine virtuelle, une machine virtuelle
> par boite.
>
> Y.
>
+1 +1 et encore +1
accès root partagé = galères à coups sur!
virtualiser les serveurs au moyen de xen, kvm, vmware ou peut-importe me
semble bien plus sécurisé ; et crois en mon expérience, tu t'éviteras
des grandes heures de galère ..
Mathieu JANIN
> Yves Rutschle a écrit :
> > On Fri, Jan 09, 2009 at 03:46:50PM +0100, François TOURDE wrote:
> >> A mon avis, il serait préférable de leur donner accès à chacune à leur
> >> zone applicative bien cloisonnée, et garder l'accès root à une seule
> >> personne.
> >
> > Ouaip, et si l'accès root est indispensable, déplacer chaque
> > serveur dans une machine virtuelle, une machine virtuelle
> > par boite.
> >
> > Y.
>
> +1 +1 et encore +1
> accès root partagé = galères à coups sur!
> virtualiser les serveurs au moyen de xen, kvm, vmware ou peut-importe me
> semble bien plus sécurisé ; et crois en mon expérience, tu t'éviteras
> des grandes heures de galère ..
Bonjour,
C'est quoi ces solutions "rouleau compresseur" pour écraser une mouche ?
Le but n'étant >que< de séparer les intervenants, je ne vois pas trop ou
mènent ces suggestions de séparer >aussi< les environnements, mais même dans
ce cas, quitte à séparer les services, pourquoi simuler toute une machine
alors qu'on peut obtenir le niveau de sécurité comparable avec un bête (d|
s)chroot, et éviter ainsi de faire tourner plusieurs noyaux sur un
processeur ?
Personnellement, j'isolerais éventuellement les services dans des chroot, et
je mettrais un compte pour chaque administrateur de service, avec un ssh
chrooté au même endroit que le service que cet intervenant doit administrer,
et avec un lot de commandes sudo autorisées restreint et bien défini pour
chaque intervenant. On peut aussi alors donner accés à des fichiers
particuliers de /etc en les (hard)linkant dans le chroot de l'utilisateur qui
en a besoin, et réserver les opérations dans l'arborescence réelle au seul
compte root général de la machine, qui reste entre les mains du responsable
du matos.
Mais je plussoie sur l'idée que multiplier les comptes en uid 0 est une
hérésie.
++, MATT
Yves Rutschle
> Bonjour,
> C'est quoi ces solutions "rouleau compresseur" pour écraser une mouche ?
> Le but n'étant >que< de séparer les intervenants, je ne vois pas trop ou
> mènent ces suggestions de séparer >aussi< les environnements, mais même dans
> ce cas, quitte à séparer les services, pourquoi simuler toute une machine
> alors qu'on peut obtenir le niveau de sécurité comparable avec un bête (d|
> s)chroot, et éviter ainsi de faire tourner plusieurs noyaux sur un
> processeur ?
>
> Personnellement, j'isolerais éventuellement les services dans des chroot,
T'énerves pas, les solutions linux-vserver et openvz sont
essentiellement la même chose qu'un chroot, mais faites avec
la sécurité en tête (un peu plus): chroot n'est *pas* une
solution de sécurité, il est trivial de sortir d'un chroot.
Dans linux-vserver, il n'y a qu'un noyau qui tourne, et on
peut mutualiser un grand nombre de fichiers entre les
environements (comme les hard links que tu suggères).
C'est pas pasque la virtualisation est à la mode que c'est
automatiquement la mauvaise solution ;)
Y.
mouss
> Thierry Leurent a écrit :
>> Merci à tous, il semble que sudo est la commande idéale mais il faut
>> encore la configurer.
>>
>> Pourquois confier l'administration d'une machine de prod à plusieurs
>> sociètés ?
>> Simplement qu'elle ont en charge une partie des logitiels présents et
>> qu'il est probabale qu'un jour ou l'autre, elles devront effectuer des
>> opérations de maintenance sur leurs produits ou pour d'autres opérations.
>>
>> Si je contente de leur donner le root, je ne peux pas les coller toute la
>> journée pour voir ce qu'ils font.
>> Je veux :
>> - Limiter leur pouvoir sur la machine à leur application et
>> eventuellement d'autres éléments périphériques.
>> - Tracer leur modifications.
>
> sudo enregistre les actions dans le fichier /var/log/auth.log
>
oui, mais il faut savoir que ça reste limité. par exemple,
# vi foo.sh
....
# sh foo.sh
# vi foo.sh
...
on sait plus ce qui a été fait par le "sh foo.sh", à moins de remplacer
vi par une commande shell qui sauve le contenu quelque part avant de
lancer l'éditeur... mais si on s'amuse à ça, on a plus vite fait de
lancer une machine virtuelle...
> Maintenant, il faut bien configurer sudo.
c'est sûr !
Stephane Bortzmeyer
Thierry Leurent <thierry...@asgardian.be> wrote
> Les machines ont été achetées clé en main à une socièté qui
> sous-traite mais nous remarquons qu'ils ont certains problèmes au
> niveau des délais, que les applis ne sont pas testées et que la
> socièté maitre d'oeuvre ne fait pas son boulot de coordination. Donc
> les sous-traitants passent pas nous directement. Nous avons peur
> que si un de socièté doit faire une modif qu'elle fasse des
> conneries et que le système se plante. Nous avons des données très
> confidentielles et des règles très stictes a appliquer.
Hmmm, du point de vue technique, la bonne approche, lorsqu'on veut
partager l'administration système, est sudo, comme indiqué par
plusieurs personnes.
Mais le paragraphe ci-dessus me donne à penser que vos problèmes ne
sont pas techniques, mais plutôt organisationnels. Car enfin, des
« données très confidentielles » et des « règles très strictes à
appliquer » alors que l'administration système est sous-traitée ? À
une société défaillante ? Et qui a elle-même des sous-traitants ? Ça
ne fait pas très sérieux.
D'autant plus que sudo n'est pas une solution miracle (il n'y a pas de
solution technique miracle aux problèmes organisationnels). Par
exemple, si un des titulaires fait un "sudo bash", ses commandes
ultérieures ne seront plus enregistrées.