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.
Dans le message <news:45d08980$0$965$, *Alain* tapota sur f.c.o.l.configuration :
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 ?
Pas besoin d'apt-get pour installer une application. Faut arrêter de raisonner Debian et de croire que sur une Debian tout passe par apt-get.
Et de même, pas besoin d'être root ou d'avoir des permissions particulières pour installer une application.
Et s'il n'y a pas de passerelle, il a tout de même accès à un réseau local ?
-- Sébastien Monbrun aka TiChou
patpro ~ Patrick Proniewski
In article , Sébastien Monbrun aka TiChou wrote:
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.
je ne sais pas ce que cela donnerait sur linux, ni même sur d'autres OS, mais un coup d'ACL avec en plus un /home/ monté en noexec, ça ferait pas l'affaire ? C'est juste une remarque théorique.
patpro
-- http://www.patpro.net/
In article <pwet.20070212162113@florizarre.tichou.org>,
Sébastien Monbrun aka TiChou <gro.uohcit@uohcit> wrote:
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.
je ne sais pas ce que cela donnerait sur linux, ni même sur d'autres OS,
mais un coup d'ACL avec en plus un /home/ monté en noexec, ça ferait pas
l'affaire ?
C'est juste une remarque théorique.
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.
je ne sais pas ce que cela donnerait sur linux, ni même sur d'autres OS, mais un coup d'ACL avec en plus un /home/ monté en noexec, ça ferait pas l'affaire ? C'est juste une remarque théorique.
patpro
-- http://www.patpro.net/
Alain
Dans le message <news:45d08980$0$965$, *Alain* tapota sur f.c.o.l.configuration :
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 ?
Pas besoin d'apt-get pour installer une application. Faut arrêter de raisonner Debian et de croire que sur une Debian tout passe par apt-get.
Et de même, pas besoin d'être root ou d'avoir des permissions particulières pour installer une application.
Et s'il n'y a pas de passerelle, il a tout de même accès à un réseau local ?
Dans le cas présent j'envisafeais de modifier les règles iptables pour
n'autoriser que le serveur central.
Dans le message <news:45d08980$0$965$426a74cc@news.free.fr>,
*Alain* tapota sur f.c.o.l.configuration :
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 ?
Pas besoin d'apt-get pour installer une application. Faut arrêter de
raisonner Debian et de croire que sur une Debian tout passe par apt-get.
Et de même, pas besoin d'être root ou d'avoir des permissions
particulières pour installer une application.
Et s'il n'y a pas de passerelle, il a tout de même accès à un réseau
local ?
Dans le cas présent j'envisafeais de modifier les règles iptables pour
Dans le message <news:45d08e72$0$424$, *Alain* tapota sur f.c.o.l.configuration :
Dans le cas présent j'envisafeais de modifier les règles iptables pour n'autoriser que le serveur central.
Il ne reste donc plus qu'à empêcher l'accès aux périphériques externes et on en revient à la solution que je donnais dans ma première réponse.
-- Sébastien Monbrun aka TiChou
Arol
"Sébastien Monbrun aka TiChou" a écrit dans le message de news:
Pas besoin d'apt-get pour installer une application. Faut arrêter de raisonner Debian et de croire que sur une Debian tout passe par apt-get.
Et de même, pas besoin d'être root ou d'avoir des permissions particulières
pour installer une application.
Faut peut être tenir compte du contexte hein : Grande surface.
C'est pas un haut lieu de la piraterie mondiale non plus.
Et le petit malin qui veut faire des conneries dessus, il va pas y passer la nuit, donc si compte avec accès rétreint et internet filtré, ça résout 99.9% des problèmes.
J'ai l'impression que vous voulez sortir la grosse artillerie pour 3 fois rien, faut pas exagérer non plus.
"Sébastien Monbrun aka TiChou" a écrit dans le message de news:
Pas besoin d'apt-get pour installer une application. Faut arrêter de
raisonner Debian et de croire que sur une Debian tout passe par apt-get.
Et de même, pas besoin d'être root ou d'avoir des permissions
particulières
pour installer une application.
Faut peut être tenir compte du contexte hein :
Grande surface.
C'est pas un haut lieu de la piraterie mondiale non plus.
Et le petit malin qui veut faire des conneries dessus, il va pas y passer la
nuit, donc si compte avec accès rétreint et internet filtré, ça résout 99.9%
des problèmes.
J'ai l'impression que vous voulez sortir la grosse artillerie pour 3 fois
rien, faut pas exagérer non plus.
"Sébastien Monbrun aka TiChou" a écrit dans le message de news:
Pas besoin d'apt-get pour installer une application. Faut arrêter de raisonner Debian et de croire que sur une Debian tout passe par apt-get.
Et de même, pas besoin d'être root ou d'avoir des permissions particulières
pour installer une application.
Faut peut être tenir compte du contexte hein : Grande surface.
C'est pas un haut lieu de la piraterie mondiale non plus.
Et le petit malin qui veut faire des conneries dessus, il va pas y passer la nuit, donc si compte avec accès rétreint et internet filtré, ça résout 99.9% des problèmes.
J'ai l'impression que vous voulez sortir la grosse artillerie pour 3 fois rien, faut pas exagérer non plus.
Sébastien Monbrun aka TiChou
Dans le message <news:, *patpro ~ Patrick Proniewski* tapota sur f.c.o.l.configuration :
je ne sais pas ce que cela donnerait sur linux, ni même sur d'autres OS, mais un coup d'ACL avec en plus un /home/ monté en noexec, ça ferait pas l'affaire ?
Si l'utilisateur a, par exemple, un accès à un terminal (shell), alors le fait que la partition soit montée en noexec ne l'empêchera pas de faire :
$ exec fichier
-- Sébastien Monbrun aka TiChou
Dans le message <news:patpro-9FA9DC.16541512022007@localhost>,
*patpro ~ Patrick Proniewski* tapota sur f.c.o.l.configuration :
je ne sais pas ce que cela donnerait sur linux, ni même sur d'autres OS,
mais un coup d'ACL avec en plus un /home/ monté en noexec, ça ferait pas
l'affaire ?
Si l'utilisateur a, par exemple, un accès à un terminal (shell), alors le
fait que la partition soit montée en noexec ne l'empêchera pas de faire :
Dans le message <news:, *patpro ~ Patrick Proniewski* tapota sur f.c.o.l.configuration :
je ne sais pas ce que cela donnerait sur linux, ni même sur d'autres OS, mais un coup d'ACL avec en plus un /home/ monté en noexec, ça ferait pas l'affaire ?
Si l'utilisateur a, par exemple, un accès à un terminal (shell), alors le fait que la partition soit montée en noexec ne l'empêchera pas de faire :
$ exec fichier
-- Sébastien Monbrun aka TiChou
Nicolas S.
Je crois que ça pourrait me simplifier la vie.
Je n'y vois aucun intérêt. D'autant que question maintenance (màj, etc), il faudra systématiquement repasser par un cycle construction/tests/redémarrage-postes-clients du live-bidule.
Je crois que ça pourrait me simplifier la vie.
Je n'y vois aucun intérêt. D'autant que question maintenance (màj, etc),
il faudra systématiquement repasser par un cycle
construction/tests/redémarrage-postes-clients du live-bidule.
Je n'y vois aucun intérêt. D'autant que question maintenance (màj, etc), il faudra systématiquement repasser par un cycle construction/tests/redémarrage-postes-clients du live-bidule.
Arol
"Sébastien Monbrun aka TiChou" a écrit dans le message de news:
je ne sais pas ce que cela donnerait sur linux, ni même sur d'autres OS, mais un coup d'ACL avec en plus un /home/ monté en noexec, ça ferait pas l'affaire ?
Si l'utilisateur a, par exemple, un accès à un terminal (shell), alors le fait que la partition soit montée en noexec ne l'empêchera pas de faire :
$ exec fichier
Bon, on a compris que tu es un bon en linux. Mais est ce que tu pourrais revenir au sujet initial ? C'est des pc de grande surface ou les gens ont autre chose à foutre que les utiliser pour pirater le pentagone ou télécharger le dernier mp3 à la mode pour le mettre sur leur clé usb/balladeur.
"Sébastien Monbrun aka TiChou" a écrit dans le message de news:
je ne sais pas ce que cela donnerait sur linux, ni même sur d'autres OS,
mais un coup d'ACL avec en plus un /home/ monté en noexec, ça ferait pas
l'affaire ?
Si l'utilisateur a, par exemple, un accès à un terminal (shell), alors le
fait que la partition soit montée en noexec ne l'empêchera pas de faire :
$ exec fichier
Bon, on a compris que tu es un bon en linux.
Mais est ce que tu pourrais revenir au sujet initial ?
C'est des pc de grande surface ou les gens ont autre chose à foutre que les
utiliser pour pirater le pentagone ou télécharger le dernier mp3 à la mode
pour le mettre sur leur clé usb/balladeur.
"Sébastien Monbrun aka TiChou" a écrit dans le message de news:
je ne sais pas ce que cela donnerait sur linux, ni même sur d'autres OS, mais un coup d'ACL avec en plus un /home/ monté en noexec, ça ferait pas l'affaire ?
Si l'utilisateur a, par exemple, un accès à un terminal (shell), alors le fait que la partition soit montée en noexec ne l'empêchera pas de faire :
$ exec fichier
Bon, on a compris que tu es un bon en linux. Mais est ce que tu pourrais revenir au sujet initial ? C'est des pc de grande surface ou les gens ont autre chose à foutre que les utiliser pour pirater le pentagone ou télécharger le dernier mp3 à la mode pour le mettre sur leur clé usb/balladeur.
Alain
Dans le message <news:45d08e72$0$424$, *Alain* tapota sur f.c.o.l.configuration :
Dans le cas présent j'envisafeais de modifier les règles iptables pour n'autoriser que le serveur central.
Il ne reste donc plus qu'à empêcher l'accès aux périphériques externes et on en revient à la solution que je donnais dans ma première réponse.
[Dixit] Donc, il faut empêcher l'accès aux supports et périphériques amovibles : CD-ROM, disquette, USB, Firewire, Ethernet, ... Et interdire l'accès réseau à des machines permettant la récupération d'applications : Internet, machine locale non maitrisée, ... [/Dixit]
C'est peut être effectivement simple.
mais comment l'interdire (hors ethernet) ?
Dans le message <news:45d08e72$0$424$426a74cc@news.free.fr>,
*Alain* tapota sur f.c.o.l.configuration :
Dans le cas présent j'envisafeais de modifier les règles iptables pour
n'autoriser que le serveur central.
Il ne reste donc plus qu'à empêcher l'accès aux périphériques externes
et on en revient à la solution que je donnais dans ma première réponse.
[Dixit]
Donc, il faut empêcher l'accès aux supports et périphériques amovibles :
CD-ROM, disquette, USB, Firewire, Ethernet, ...
Et interdire l'accès réseau à des machines permettant la récupération
d'applications : Internet, machine locale non maitrisée, ...
[/Dixit]
Dans le message <news:45d08e72$0$424$, *Alain* tapota sur f.c.o.l.configuration :
Dans le cas présent j'envisafeais de modifier les règles iptables pour n'autoriser que le serveur central.
Il ne reste donc plus qu'à empêcher l'accès aux périphériques externes et on en revient à la solution que je donnais dans ma première réponse.
[Dixit] Donc, il faut empêcher l'accès aux supports et périphériques amovibles : CD-ROM, disquette, USB, Firewire, Ethernet, ... Et interdire l'accès réseau à des machines permettant la récupération d'applications : Internet, machine locale non maitrisée, ... [/Dixit]
C'est peut être effectivement simple.
mais comment l'interdire (hors ethernet) ?
patpro ~ Patrick Proniewski
In article , Sébastien Monbrun aka TiChou wrote:
Dans le message <news:, *patpro ~ Patrick Proniewski* tapota sur f.c.o.l.configuration :
je ne sais pas ce que cela donnerait sur linux, ni même sur d'autres OS, mais un coup d'ACL avec en plus un /home/ monté en noexec, ça ferait pas l'affaire ?
Si l'utilisateur a, par exemple, un accès à un terminal (shell), alors le fait que la partition soit montée en noexec ne l'empêchera pas de faire :
$ exec fichier
c'est le but de mon "coup d'ACL" :) tu peux interdire l'utilisation d'exec (et autres) pour une catégorie d'utilisateurs. Apres je ne sais pas du tout comment sont implémentées les ACL sur linux. Je suis plus familier de Mac OS X pour les ACL, et des *BSD pour la tambouille en général.
patpro
-- http://www.patpro.net/
In article <gniii.20070212170344@florizarre.tichou.org>,
Sébastien Monbrun aka TiChou <gro.uohcit@uohcit> wrote:
Dans le message <news:patpro-9FA9DC.16541512022007@localhost>,
*patpro ~ Patrick Proniewski* tapota sur f.c.o.l.configuration :
je ne sais pas ce que cela donnerait sur linux, ni même sur d'autres OS,
mais un coup d'ACL avec en plus un /home/ monté en noexec, ça ferait pas
l'affaire ?
Si l'utilisateur a, par exemple, un accès à un terminal (shell), alors le
fait que la partition soit montée en noexec ne l'empêchera pas de faire :
$ exec fichier
c'est le but de mon "coup d'ACL" :)
tu peux interdire l'utilisation d'exec (et autres) pour une catégorie
d'utilisateurs. Apres je ne sais pas du tout comment sont implémentées
les ACL sur linux. Je suis plus familier de Mac OS X pour les ACL, et
des *BSD pour la tambouille en général.
Dans le message <news:, *patpro ~ Patrick Proniewski* tapota sur f.c.o.l.configuration :
je ne sais pas ce que cela donnerait sur linux, ni même sur d'autres OS, mais un coup d'ACL avec en plus un /home/ monté en noexec, ça ferait pas l'affaire ?
Si l'utilisateur a, par exemple, un accès à un terminal (shell), alors le fait que la partition soit montée en noexec ne l'empêchera pas de faire :
$ exec fichier
c'est le but de mon "coup d'ACL" :) tu peux interdire l'utilisation d'exec (et autres) pour une catégorie d'utilisateurs. Apres je ne sais pas du tout comment sont implémentées les ACL sur linux. Je suis plus familier de Mac OS X pour les ACL, et des *BSD pour la tambouille en général.
