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-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
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 à chacun e à leur >> zone applicative bien cloisonnée, et garder l'accès root à une s eule >> 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'évit eras 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 o u 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 machi ne alors qu'on peut obtenir le niveau de sécurité comparable avec un bêt e (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 adminis trer, et avec un lot de commandes sudo autorisées restreint et bien défini po ur chaque intervenant. On peut aussi alors donner accés à des fichiers particuliers de /etc en les (hard)linkant dans le chroot de l'utilisateur q ui 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 respons able du matos.
Mais je plussoie sur l'idée que multiplier les comptes en uid 0 est une hérésie.
++, MATT
-- 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 with a subject of "unsubscribe". Trouble? Contact
Le samedi 10 janvier 2009, Cornichon a écrit :
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 à chacun e à leur
>> zone applicative bien cloisonnée, et garder l'accès root à une s eule
>> 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'évit eras
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 o u
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 machi ne
alors qu'on peut obtenir le niveau de sécurité comparable avec un bêt e (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 adminis trer,
et avec un lot de commandes sudo autorisées restreint et bien défini po ur
chaque intervenant. On peut aussi alors donner accés à des fichiers
particuliers de /etc en les (hard)linkant dans le chroot de l'utilisateur q ui
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 respons able
du matos.
Mais je plussoie sur l'idée que multiplier les comptes en uid 0 est une
hérésie.
++, MATT
--
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-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
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 à chacun e à leur >> zone applicative bien cloisonnée, et garder l'accès root à une s eule >> 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'évit eras 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 o u 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 machi ne alors qu'on peut obtenir le niveau de sécurité comparable avec un bêt e (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 adminis trer, et avec un lot de commandes sudo autorisées restreint et bien défini po ur chaque intervenant. On peut aussi alors donner accés à des fichiers particuliers de /etc en les (hard)linkant dans le chroot de l'utilisateur q ui 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 respons able du matos.
Mais je plussoie sur l'idée que multiplier les comptes en uid 0 est une hérésie.
++, MATT
-- 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 with a subject of "unsubscribe". Trouble? Contact
Yves Rutschle
On Sat, Jan 10, 2009 at 08:00:51AM +0100, Mathieu JANIN wrote:
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.
-- 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 with a subject of "unsubscribe". Trouble? Contact
On Sat, Jan 10, 2009 at 08:00:51AM +0100, Mathieu JANIN wrote:
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.
--
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-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
On Sat, Jan 10, 2009 at 08:00:51AM +0100, Mathieu JANIN wrote:
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.
-- 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 with a subject of "unsubscribe". Trouble? Contact
mouss
Frédéric Massot a écrit :
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 !
-- 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 with a subject of "unsubscribe". Trouble? Contact
Frédéric Massot a écrit :
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 !
--
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-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
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 !
-- 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 with a subject of "unsubscribe". Trouble? Contact
Stephane Bortzmeyer
On Fri, Jan 09, 2009 at 11:25:11PM +0100, Thierry Leurent wrote a message of 91 lines which said:
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.
-- 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 with a subject of "unsubscribe". Trouble? Contact
On Fri, Jan 09, 2009 at 11:25:11PM +0100,
Thierry Leurent <thierry.leurent@asgardian.be> wrote
a message of 91 lines which said:
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.
--
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-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
On Fri, Jan 09, 2009 at 11:25:11PM +0100, Thierry Leurent wrote a message of 91 lines which said:
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.
-- 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 with a subject of "unsubscribe". Trouble? Contact
