Je suis dans le cadre d'une utilisation professionnelle de Linux au sein
d'une grande surface.
Je voudrais remplacer des PC sous Windows par des machines sous Linux et
brider les utilisateurs en rayon afin qu'ils n'aient accès qu'au
applications installées sans pouvoir en ajouter d'autres ou en ajouter.
En fait, je voudrais qu'il soit impossible de modifier la configuration
de la machine.
Quels sont les éléments qu'il faut configurer pour installer les
applications requises et interdire toute modification ultérieure?
Les applications seraient :
firefox pour un intranet
ssh (si, si :-) ) pour un serveur local
openoffice dans certains cas.
restreindre les droits au maximum (sécurité niveau paranoïaque), pas de console (interdiction des tty etc), Si, j'en aurai besoin pour un ssh vers mon serveur central.
Pas besoin de tty pour un accès ssh à distance, tu peux tous les virer. C'est ce que j'ai fait sur un vieux server, ça a libéré quelques Mo de ram.
"Alain" a écrit dans le message de news:
restreindre les droits au
maximum (sécurité niveau paranoïaque), pas de console (interdiction des
tty etc),
Si, j'en aurai besoin pour un ssh vers mon serveur central.
Pas besoin de tty pour un accès ssh à distance, tu peux tous les virer.
C'est ce que j'ai fait sur un vieux server, ça a libéré quelques Mo de ram.
restreindre les droits au maximum (sécurité niveau paranoïaque), pas de console (interdiction des tty etc), Si, j'en aurai besoin pour un ssh vers mon serveur central.
Pas besoin de tty pour un accès ssh à distance, tu peux tous les virer. C'est ce que j'ai fait sur un vieux server, ça a libéré quelques Mo de ram.
Michel Tatoute
Rakotomandimby (R12y) Mihamina wrote:
Arol wrote:
Et bien, tu n'as pas grand chose à faire. En règle générale, faut être root pour installer/modifier/supprimer des logiciels.
Oui et non. Pour reprendre ton exemple, si un utilisateur prend les binaires fournis par Mozilla et openoffice, il peut tout à fait les installer dans son HOME. Et ti il lui faut les headers de quoi que ce soit, il peut les télécharger et indiquer au compilateur que les headers se trouve dans $HOME/include par exemple. Et dans le scenario parano, imagine que comme ça, il installe qemu, il arrivera a faire tourner un OS de/dans son $HOME! Bref,...
Mais non, en plus de bloquer root pour toi seul, il te suffit de mettre la partition home (et celle de tmp) en noexec. Aucun binaire ne poiurra plus y être utilisé. De même tu fais la même chose avec les montages auto de cdrom, floppy & clefs usb. Si tu crains qu'ils aillent jusqu'au reboot tu verrouille le bios par mot de passe apres avoir viré le boot sur autre chose que le disque. Enfin tu fais une protection contre l'ouverture du PC.
Apres ca tu n'as plus grand chose à craindre, excepté la furerur de tes utilisateurs.
Note qu'avec une telle config il est déconseillé de jouer la DSI arrogante, mais bien au contraire la serviabilité et la bonne volonté.
Michel.
Rakotomandimby (R12y) Mihamina wrote:
Arol wrote:
Et bien, tu n'as pas grand chose à faire.
En règle générale, faut être root pour installer/modifier/supprimer des
logiciels.
Oui et non.
Pour reprendre ton exemple, si un utilisateur prend les binaires fournis
par Mozilla et openoffice, il peut tout à fait les installer dans son
HOME. Et ti il lui faut les headers de quoi que ce soit, il peut les
télécharger et indiquer au compilateur que les headers se trouve dans
$HOME/include par exemple.
Et dans le scenario parano, imagine que comme ça, il installe qemu, il
arrivera a faire tourner un OS de/dans son $HOME!
Bref,...
Mais non, en plus de bloquer root pour toi seul, il te suffit de mettre la
partition home (et celle de tmp) en noexec. Aucun binaire ne poiurra plus y
être utilisé. De même tu fais la même chose avec les montages auto de
cdrom, floppy & clefs usb. Si tu crains qu'ils aillent jusqu'au reboot tu
verrouille le bios par mot de passe apres avoir viré le boot sur autre
chose que le disque. Enfin tu fais une protection contre l'ouverture du PC.
Apres ca tu n'as plus grand chose à craindre, excepté la furerur de tes
utilisateurs.
Note qu'avec une telle config il est déconseillé de jouer la DSI arrogante,
mais bien au contraire la serviabilité et la bonne volonté.
Et bien, tu n'as pas grand chose à faire. En règle générale, faut être root pour installer/modifier/supprimer des logiciels.
Oui et non. Pour reprendre ton exemple, si un utilisateur prend les binaires fournis par Mozilla et openoffice, il peut tout à fait les installer dans son HOME. Et ti il lui faut les headers de quoi que ce soit, il peut les télécharger et indiquer au compilateur que les headers se trouve dans $HOME/include par exemple. Et dans le scenario parano, imagine que comme ça, il installe qemu, il arrivera a faire tourner un OS de/dans son $HOME! Bref,...
Mais non, en plus de bloquer root pour toi seul, il te suffit de mettre la partition home (et celle de tmp) en noexec. Aucun binaire ne poiurra plus y être utilisé. De même tu fais la même chose avec les montages auto de cdrom, floppy & clefs usb. Si tu crains qu'ils aillent jusqu'au reboot tu verrouille le bios par mot de passe apres avoir viré le boot sur autre chose que le disque. Enfin tu fais une protection contre l'ouverture du PC.
Apres ca tu n'as plus grand chose à craindre, excepté la furerur de tes utilisateurs.
Note qu'avec une telle config il est déconseillé de jouer la DSI arrogante, mais bien au contraire la serviabilité et la bonne volonté.
Michel.
Alain
"Alain" a écrit dans le message de news:
restreindre les droits au maximum (sécurité niveau paranoïaque), pas de console (interdiction des tty etc), Si, j'en aurai besoin pour un ssh vers mon serveur central.
Pas besoin de tty pour un accès ssh à distance, tu peux tous les virer. C'est ce que j'ai fait sur un vieux server, ça a libéré quelques Mo de ram.
Bonjour Arol
A ce compte là, je me demande si je ne devrais pas me faire un live cd avec les fichiers de travail sur un /tmp ...... Tout compte fait ...
Amicalement Alain
"Alain" a écrit dans le message de news:
restreindre les droits au
maximum (sécurité niveau paranoïaque), pas de console (interdiction des
tty etc),
Si, j'en aurai besoin pour un ssh vers mon serveur central.
Pas besoin de tty pour un accès ssh à distance, tu peux tous les virer.
C'est ce que j'ai fait sur un vieux server, ça a libéré quelques Mo de ram.
Bonjour Arol
A ce compte là, je me demande si je ne devrais pas me faire un live cd
avec les fichiers de travail sur un /tmp ......
Tout compte fait ...
restreindre les droits au maximum (sécurité niveau paranoïaque), pas de console (interdiction des tty etc), Si, j'en aurai besoin pour un ssh vers mon serveur central.
Pas besoin de tty pour un accès ssh à distance, tu peux tous les virer. C'est ce que j'ai fait sur un vieux server, ça a libéré quelques Mo de ram.
Bonjour Arol
A ce compte là, je me demande si je ne devrais pas me faire un live cd avec les fichiers de travail sur un /tmp ...... Tout compte fait ...
Amicalement Alain
Arol
"Alain" a écrit dans le message de news:
A ce compte là, je me demande si je ne devrais pas me faire un live cd avec les fichiers de travail sur un /tmp ......
Un live cd sur une machine sans disque dur, tu risqueras pas grand chose en effet.
"Alain" a écrit dans le message de news:
A ce compte là, je me demande si je ne devrais pas me faire un live cd
avec les fichiers de travail sur un /tmp ......
Un live cd sur une machine sans disque dur, tu risqueras pas grand chose en
effet.
A ce compte là, je me demande si je ne devrais pas me faire un live cd avec les fichiers de travail sur un /tmp ......
Un live cd sur une machine sans disque dur, tu risqueras pas grand chose en effet.
Nina Popravka
On Mon, 12 Feb 2007 15:57:15 +0100, Alain wrote:
A ce compte là, je me demande si je ne devrais pas me faire un live cd avec les fichiers de travail sur un /tmp ...... Ou des clés USB si tu peux booter dessus... Verrouillées en écriture.
-- Nina
On Mon, 12 Feb 2007 15:57:15 +0100, Alain <a.ferriol@free.fr> wrote:
A ce compte là, je me demande si je ne devrais pas me faire un live cd
avec les fichiers de travail sur un /tmp ......
Ou des clés USB si tu peux booter dessus... Verrouillées en écriture.
A ce compte là, je me demande si je ne devrais pas me faire un live cd avec les fichiers de travail sur un /tmp ...... Ou des clés USB si tu peux booter dessus... Verrouillées en écriture.
-- Nina
Alain
"Alain" a écrit dans le message de news:
A ce compte là, je me demande si je ne devrais pas me faire un live cd avec les fichiers de travail sur un /tmp ......
Un live cd sur une machine sans disque dur, tu risqueras pas grand chose en effet.
Je crois que ça pourrait me simplifier la vie. Reste à voir comment fabriquer un live cd mais je crois que mon copain google va m'aider :-)
Merci à tous ! Alain
"Alain" a écrit dans le message de news:
A ce compte là, je me demande si je ne devrais pas me faire un live cd
avec les fichiers de travail sur un /tmp ......
Un live cd sur une machine sans disque dur, tu risqueras pas grand chose en
effet.
Je crois que ça pourrait me simplifier la vie.
Reste à voir comment fabriquer un live cd mais je crois que mon copain
google va m'aider :-)
A ce compte là, je me demande si je ne devrais pas me faire un live cd avec les fichiers de travail sur un /tmp ......
Un live cd sur une machine sans disque dur, tu risqueras pas grand chose en effet.
Je crois que ça pourrait me simplifier la vie. Reste à voir comment fabriquer un live cd mais je crois que mon copain google va m'aider :-)
Merci à tous ! Alain
Sébastien Monbrun aka TiChou
Dans le message <news:45d075f8$0$437$, *Alain* tapota sur f.c.o.l.configuration :
logiciel : ne mettre dans le modèle que le strict minimum nécessaire à l'utilisation prescrite, donc éliminer toute la partie "développement" (gcc & co), gicler rpm, urpmi, apt, etc (pas d'installation de nouveaux programmes), C'est vrai qu'en éliminant tous les rpm de compile, tar, gz et autres, on
limite pas mal la casse ! Bien vu !
J'aimerai qu'on m'explique en quoi supprimer gestionnaire de paquets, outils de compilations et outils d'archivage peut empêcher l'installation d'applications ou de fichiers. Qui dit compilation, dit rapatriement des sources. Qui dit gestion de paquets, dit rapatriement de paquets. Qui dit manipulation d'archives, dit rapatriement d'archives. Qui dit rapatriement de sources, de paquets ou d'archives, dit aussi rapatriement de n'importe quels fichiers dont des applications précompilées. Donc, c'est vraisemblablement inutile de vouloir cacher ou supprimer ce qui est cité précédemment. Ça ressemble à de le sécurité par obscurantisme. Il faut s'attarder au vrai problème, la possibilité à un utilisateur d'amener ce qu'il souhaite sur la machine et d'avoir la main sur le contrôle de l'interface auquel on lui donne accès.
-- Sébastien Monbrun aka TiChou
Dans le message <news:45d075f8$0$437$426a74cc@news.free.fr>,
*Alain* tapota sur f.c.o.l.configuration :
logiciel :
ne mettre dans le modèle que le strict minimum nécessaire à
l'utilisation prescrite, donc éliminer toute la partie
"développement" (gcc & co), gicler rpm, urpmi, apt, etc (pas
d'installation de nouveaux programmes),
C'est vrai qu'en éliminant tous les rpm de compile, tar, gz et autres, on
limite pas mal la casse !
Bien vu !
J'aimerai qu'on m'explique en quoi supprimer gestionnaire de paquets, outils
de compilations et outils d'archivage peut empêcher l'installation
d'applications ou de fichiers.
Qui dit compilation, dit rapatriement des sources. Qui dit gestion de
paquets, dit rapatriement de paquets. Qui dit manipulation d'archives, dit
rapatriement d'archives.
Qui dit rapatriement de sources, de paquets ou d'archives, dit aussi
rapatriement de n'importe quels fichiers dont des applications précompilées.
Donc, c'est vraisemblablement inutile de vouloir cacher ou supprimer ce qui
est cité précédemment. Ça ressemble à de le sécurité par obscurantisme.
Il faut s'attarder au vrai problème, la possibilité à un utilisateur
d'amener ce qu'il souhaite sur la machine et d'avoir la main sur le contrôle
de l'interface auquel on lui donne accès.
Dans le message <news:45d075f8$0$437$, *Alain* tapota sur f.c.o.l.configuration :
logiciel : ne mettre dans le modèle que le strict minimum nécessaire à l'utilisation prescrite, donc éliminer toute la partie "développement" (gcc & co), gicler rpm, urpmi, apt, etc (pas d'installation de nouveaux programmes), C'est vrai qu'en éliminant tous les rpm de compile, tar, gz et autres, on
limite pas mal la casse ! Bien vu !
J'aimerai qu'on m'explique en quoi supprimer gestionnaire de paquets, outils de compilations et outils d'archivage peut empêcher l'installation d'applications ou de fichiers. Qui dit compilation, dit rapatriement des sources. Qui dit gestion de paquets, dit rapatriement de paquets. Qui dit manipulation d'archives, dit rapatriement d'archives. Qui dit rapatriement de sources, de paquets ou d'archives, dit aussi rapatriement de n'importe quels fichiers dont des applications précompilées. Donc, c'est vraisemblablement inutile de vouloir cacher ou supprimer ce qui est cité précédemment. Ça ressemble à de le sécurité par obscurantisme. Il faut s'attarder au vrai problème, la possibilité à un utilisateur d'amener ce qu'il souhaite sur la machine et d'avoir la main sur le contrôle de l'interface auquel on lui donne accès.
-- Sébastien Monbrun aka TiChou
Sébastien Monbrun aka TiChou
Dans le message <news:45d0859e$0$310$, *Alain* tapota sur f.c.o.l.configuration :
A ce compte là, je me demande si je ne devrais pas me faire un live cd avec les fichiers de travail sur un /tmp ......
Dans quel but ? Quel intérêt ?
Un live cd sur une machine sans disque dur, tu risqueras pas grand chose en effet.
En quoi la présence d'un disque dur augmenterai le risque ?
Je crois que ça pourrait me simplifier la vie.
C'est vraiment se compliquer la vie...
Reste à voir comment fabriquer un live cd mais je crois que mon copain google va m'aider :-)
Bon courage.
-- Sébastien Monbrun aka TiChou
Dans le message <news:45d0859e$0$310$426a74cc@news.free.fr>,
*Alain* tapota sur f.c.o.l.configuration :
A ce compte là, je me demande si je ne devrais pas me faire un live cd
avec les fichiers de travail sur un /tmp ......
Dans quel but ? Quel intérêt ?
Un live cd sur une machine sans disque dur, tu risqueras pas grand chose
en effet.
En quoi la présence d'un disque dur augmenterai le risque ?
Je crois que ça pourrait me simplifier la vie.
C'est vraiment se compliquer la vie...
Reste à voir comment fabriquer un live cd mais je crois que mon copain
google va m'aider :-)
Dans le message <news:45d0859e$0$310$, *Alain* tapota sur f.c.o.l.configuration :
A ce compte là, je me demande si je ne devrais pas me faire un live cd avec les fichiers de travail sur un /tmp ......
Dans quel but ? Quel intérêt ?
Un live cd sur une machine sans disque dur, tu risqueras pas grand chose en effet.
En quoi la présence d'un disque dur augmenterai le risque ?
Je crois que ça pourrait me simplifier la vie.
C'est vraiment se compliquer la vie...
Reste à voir comment fabriquer un live cd mais je crois que mon copain google va m'aider :-)
Bon courage.
-- Sébastien Monbrun aka TiChou
Alain
Dans le message <news:45d075f8$0$437$, *Alain* tapota sur f.c.o.l.configuration :
logiciel : ne mettre dans le modèle que le strict minimum nécessaire à l'utilisation prescrite, donc éliminer toute la partie "développement" (gcc & co), gicler rpm, urpmi, apt, etc (pas d'installation de nouveaux programmes), C'est vrai qu'en éliminant tous les rpm de compile, tar, gz et autres,
on limite pas mal la casse ! Bien vu !
J'aimerai qu'on m'explique en quoi supprimer gestionnaire de paquets, outils de compilations et outils d'archivage peut empêcher l'installation d'applications ou de fichiers. Qui dit compilation, dit rapatriement des sources. Qui dit gestion de paquets, dit rapatriement de paquets. Qui dit manipulation d'archives, dit rapatriement d'archives. Qui dit rapatriement de sources, de paquets ou d'archives, dit aussi rapatriement de n'importe quels fichiers dont des applications précompilées. Donc, c'est vraisemblablement inutile de vouloir cacher ou supprimer ce qui est cité précédemment. Ça ressemble à de le sécurité par obscurantisme. Il faut s'attarder au vrai problème, la possibilité à un utilisateur d'amener ce qu'il souhaite sur la machine et d'avoir la main sur le contrôle de l'interface auquel on lui donne accès.
Bonjour,
Ben sans parler d'obscurantisme, s'il n'a pas de passerelle pour faire un apt-get et s'il n'est pas root ça va quand même être dur non ?
Amicalement Alain
Dans le message <news:45d075f8$0$437$426a74cc@news.free.fr>,
*Alain* tapota sur f.c.o.l.configuration :
logiciel :
ne mettre dans le modèle que le strict minimum nécessaire à
l'utilisation prescrite, donc éliminer toute la partie
"développement" (gcc & co), gicler rpm, urpmi, apt, etc (pas
d'installation de nouveaux programmes),
C'est vrai qu'en éliminant tous les rpm de compile, tar, gz et autres,
on limite pas mal la casse !
Bien vu !
J'aimerai qu'on m'explique en quoi supprimer gestionnaire de paquets,
outils de compilations et outils d'archivage peut empêcher
l'installation d'applications ou de fichiers.
Qui dit compilation, dit rapatriement des sources. Qui dit gestion de
paquets, dit rapatriement de paquets. Qui dit manipulation d'archives,
dit rapatriement d'archives.
Qui dit rapatriement de sources, de paquets ou d'archives, dit aussi
rapatriement de n'importe quels fichiers dont des applications
précompilées.
Donc, c'est vraisemblablement inutile de vouloir cacher ou supprimer ce
qui est cité précédemment. Ça ressemble à de le sécurité par obscurantisme.
Il faut s'attarder au vrai problème, la possibilité à un utilisateur
d'amener ce qu'il souhaite sur la machine et d'avoir la main sur le
contrôle de l'interface auquel on lui donne accès.
Bonjour,
Ben sans parler d'obscurantisme, s'il n'a pas de passerelle pour faire
un apt-get et s'il n'est pas root ça va quand même être dur non ?
Dans le message <news:45d075f8$0$437$, *Alain* tapota sur f.c.o.l.configuration :
logiciel : ne mettre dans le modèle que le strict minimum nécessaire à l'utilisation prescrite, donc éliminer toute la partie "développement" (gcc & co), gicler rpm, urpmi, apt, etc (pas d'installation de nouveaux programmes), C'est vrai qu'en éliminant tous les rpm de compile, tar, gz et autres,
on limite pas mal la casse ! Bien vu !
J'aimerai qu'on m'explique en quoi supprimer gestionnaire de paquets, outils de compilations et outils d'archivage peut empêcher l'installation d'applications ou de fichiers. Qui dit compilation, dit rapatriement des sources. Qui dit gestion de paquets, dit rapatriement de paquets. Qui dit manipulation d'archives, dit rapatriement d'archives. Qui dit rapatriement de sources, de paquets ou d'archives, dit aussi rapatriement de n'importe quels fichiers dont des applications précompilées. Donc, c'est vraisemblablement inutile de vouloir cacher ou supprimer ce qui est cité précédemment. Ça ressemble à de le sécurité par obscurantisme. Il faut s'attarder au vrai problème, la possibilité à un utilisateur d'amener ce qu'il souhaite sur la machine et d'avoir la main sur le contrôle de l'interface auquel on lui donne accès.
Bonjour,
Ben sans parler d'obscurantisme, s'il n'a pas de passerelle pour faire un apt-get et s'il n'est pas root ça va quand même être dur non ?
Amicalement Alain
Nina Popravka
On Mon, 12 Feb 2007 16:20:02 +0100, Alain wrote:
Reste à voir comment fabriquer un live cd mais je crois que mon copain google va m'aider :-) Je vais me faire tuer de dire ça ici, mais tu peux regarder aussi du
côté de BartPE. -- Nina
On Mon, 12 Feb 2007 16:20:02 +0100, Alain <a.ferriol@free.fr> wrote:
Reste à voir comment fabriquer un live cd mais je crois que mon copain
google va m'aider :-)
Je vais me faire tuer de dire ça ici, mais tu peux regarder aussi du
Reste à voir comment fabriquer un live cd mais je crois que mon copain google va m'aider :-) Je vais me faire tuer de dire ça ici, mais tu peux regarder aussi du
