Dans le cadre d'une formation je dois présenter un dossier sur le "theme"
Peux on remplacer Windows par linux sur le poste de travail en entreprise.
Je connais votre opinion sur le sujet (opinion dont je suis d' ailleurs
assez proche)
mais j'aimerai avoir un ou deux site présentant le sujet demanière
structurée.
Euh, non, les ACL, ca n'est pas fait pour l'admin, c'est fait pour les utilisateurs. L'admin il a accès a tout, quelque soit l'OS (meme sous Windows normalement), alors il ne compte pas dans ma comparaison.
Je ne suis pas d'accord, c'est meme un tres gros point faible d'Unix par rapport a d'autres systemes. L'administrateur doit avoir acces au systeme, mais les donnees, elles, ne le regardent en aucune facon.
Sur un systeme vraiment secure, root n'existerait pas et des utilisateurs systemes auraient charge de l'administration de parties ou de tout le systeme sans avoir d'acces aux donnees elle memes. C'est possible avec Unix, mais force est de constater que c'est rarement pris en application.
Sous Windows, je ne sais pas. Il me semble qu'on peut bloquer l'acces aux donnees, mais un specialiste pourra m'eclairer.
-- http://www.unices.org
Nicolas Le Scouarnec wrote:
Euh, non, les ACL, ca n'est pas fait pour l'admin, c'est fait pour les
utilisateurs. L'admin il a accès a tout, quelque soit l'OS (meme sous
Windows normalement), alors il ne compte pas dans ma comparaison.
Je ne suis pas d'accord, c'est meme un tres gros point faible d'Unix par
rapport a d'autres systemes. L'administrateur doit avoir acces au
systeme, mais les donnees, elles, ne le regardent en aucune facon.
Sur un systeme vraiment secure, root n'existerait pas et des
utilisateurs systemes auraient charge de l'administration de parties ou
de tout le systeme sans avoir d'acces aux donnees elle memes. C'est
possible avec Unix, mais force est de constater que c'est rarement pris
en application.
Sous Windows, je ne sais pas. Il me semble qu'on peut bloquer l'acces
aux donnees, mais un specialiste pourra m'eclairer.
Euh, non, les ACL, ca n'est pas fait pour l'admin, c'est fait pour les utilisateurs. L'admin il a accès a tout, quelque soit l'OS (meme sous Windows normalement), alors il ne compte pas dans ma comparaison.
Je ne suis pas d'accord, c'est meme un tres gros point faible d'Unix par rapport a d'autres systemes. L'administrateur doit avoir acces au systeme, mais les donnees, elles, ne le regardent en aucune facon.
Sur un systeme vraiment secure, root n'existerait pas et des utilisateurs systemes auraient charge de l'administration de parties ou de tout le systeme sans avoir d'acces aux donnees elle memes. C'est possible avec Unix, mais force est de constater que c'est rarement pris en application.
Sous Windows, je ne sais pas. Il me semble qu'on peut bloquer l'acces aux donnees, mais un specialiste pourra m'eclairer.
-- http://www.unices.org
Nicolas George
Stephane TOUGARD , dans le message , a écrit :
Je ne suis pas d'accord, c'est meme un tres gros point faible d'Unix par rapport a d'autres systemes. L'administrateur doit avoir acces au systeme, mais les donnees, elles, ne le regardent en aucune facon.
Sur un systeme vraiment secure, root n'existerait pas et des utilisateurs systemes auraient charge de l'administration de parties ou de tout le systeme sans avoir d'acces aux donnees elle memes. C'est possible avec Unix, mais force est de constater que c'est rarement pris en application.
Quel que soit l'OS, il y a un certain nombre d'opérations qui donnent mécaniquement à celui qui peut les effectuer tout pouvoir sur la machine, c'est inévitable. La possibilité de charger un module/driver dans le noyau, par exemple. D'ailleurs, même simplement le pouvoir d'upgrader le shell utilisé par d'autres donne le pouvoir de contrôler leurs actions (à condition d'attendre qu'ils se loguent).
Stephane TOUGARD , dans le message
<slrncqnhaf.vvg.stephane@gulliver.kirch>, a écrit :
Je ne suis pas d'accord, c'est meme un tres gros point faible d'Unix par
rapport a d'autres systemes. L'administrateur doit avoir acces au
systeme, mais les donnees, elles, ne le regardent en aucune facon.
Sur un systeme vraiment secure, root n'existerait pas et des
utilisateurs systemes auraient charge de l'administration de parties ou
de tout le systeme sans avoir d'acces aux donnees elle memes. C'est
possible avec Unix, mais force est de constater que c'est rarement pris
en application.
Quel que soit l'OS, il y a un certain nombre d'opérations qui donnent
mécaniquement à celui qui peut les effectuer tout pouvoir sur la machine,
c'est inévitable. La possibilité de charger un module/driver dans le noyau,
par exemple. D'ailleurs, même simplement le pouvoir d'upgrader le shell
utilisé par d'autres donne le pouvoir de contrôler leurs actions (à
condition d'attendre qu'ils se loguent).
Je ne suis pas d'accord, c'est meme un tres gros point faible d'Unix par rapport a d'autres systemes. L'administrateur doit avoir acces au systeme, mais les donnees, elles, ne le regardent en aucune facon.
Sur un systeme vraiment secure, root n'existerait pas et des utilisateurs systemes auraient charge de l'administration de parties ou de tout le systeme sans avoir d'acces aux donnees elle memes. C'est possible avec Unix, mais force est de constater que c'est rarement pris en application.
Quel que soit l'OS, il y a un certain nombre d'opérations qui donnent mécaniquement à celui qui peut les effectuer tout pouvoir sur la machine, c'est inévitable. La possibilité de charger un module/driver dans le noyau, par exemple. D'ailleurs, même simplement le pouvoir d'upgrader le shell utilisé par d'autres donne le pouvoir de contrôler leurs actions (à condition d'attendre qu'ils se loguent).
JustMe
JustMe wrote:
Dans le monde réel tu as aussi des applicatifs et des bases de données qui tournent sur les serveurs, et qu'il faut arreter avant de pouvoir rebooter le système. C'est pas aussi trivial qu'un simple shutdown -r.
Ca tombe bien, un unix bien configuré arrete lui meme les SGBD et autres demons quand ont fait un shutdown -r :-D
Va dire ça à un DBA Oracle, je pense que le pauvre va se pisser dessus de rire (ou de terreur à l'idée de devoir arrêter sa base).
Pas de probleme chez moi (2 oracles, 1 mysql, 3 postgresql...)
merci
JustMe <pasdespam@merci.beaucoup> wrote:
Dans le monde réel tu as aussi des applicatifs et des bases de données
qui tournent sur les serveurs, et qu'il faut arreter avant de pouvoir
rebooter le système. C'est pas aussi trivial qu'un simple shutdown -r.
Ca tombe bien, un unix bien configuré arrete lui meme les SGBD et
autres demons quand ont fait un shutdown -r :-D
Va dire ça à un DBA Oracle, je pense que le pauvre va se pisser dessus
de rire (ou de terreur à l'idée de devoir arrêter sa base).
Pas de probleme chez moi (2 oracles, 1 mysql, 3 postgresql...)
Dans le monde réel tu as aussi des applicatifs et des bases de données qui tournent sur les serveurs, et qu'il faut arreter avant de pouvoir rebooter le système. C'est pas aussi trivial qu'un simple shutdown -r.
Ca tombe bien, un unix bien configuré arrete lui meme les SGBD et autres demons quand ont fait un shutdown -r :-D
Va dire ça à un DBA Oracle, je pense que le pauvre va se pisser dessus de rire (ou de terreur à l'idée de devoir arrêter sa base).
Pas de probleme chez moi (2 oracles, 1 mysql, 3 postgresql...)
merci
JustMe
Stephane TOUGARD avait soumis l'idée :
Julien BLACHE wrote:
Et c'est quoi, un reboot sérieux ? Un reboot commandé sur papier carbone triple couche blanc/bleu/rose chez Microsoft ?
A ce que j'ai compris, c'est un reboot regulier qui a lieu une fois par semaine entre 8H30 et 9H00 et avec un ingenieur devant l'ecran pdt toute la procedure. Ca peut comprendre un update de patchs sur le systeme.
Ah oui, c'est vrai les reboots preventifs sous windows :-D
Stephane TOUGARD avait soumis l'idée :
Julien BLACHE wrote:
Et c'est quoi, un reboot sérieux ? Un reboot commandé sur papier
carbone triple couche blanc/bleu/rose chez Microsoft ?
A ce que j'ai compris, c'est un reboot regulier qui a lieu une fois par
semaine entre 8H30 et 9H00 et avec un ingenieur devant l'ecran pdt toute
la procedure. Ca peut comprendre un update de patchs sur le systeme.
Ah oui, c'est vrai les reboots preventifs sous windows :-D
Et c'est quoi, un reboot sérieux ? Un reboot commandé sur papier carbone triple couche blanc/bleu/rose chez Microsoft ?
A ce que j'ai compris, c'est un reboot regulier qui a lieu une fois par semaine entre 8H30 et 9H00 et avec un ingenieur devant l'ecran pdt toute la procedure. Ca peut comprendre un update de patchs sur le systeme.
Ah oui, c'est vrai les reboots preventifs sous windows :-D
Franck Yvonnet
Ainsi Parlait nicolas vigier
On 2004-11-29, Julien BLACHE wrote:
Va dire ça à un DBA Oracle, je pense que le pauvre va se pisser dessus de rire (ou de terreur à l'idée de devoir arrêter sa base).
On a dit un unix bien configure !
Justement, là on ne parle plus d'Unix (ou de Windows) mais d'Oracle qui
est un monde totalement à part. Et pour peu que ta base de données représente une certaine taille, tu ne va plus avoir un serveur mais toute une infrastructure de serveurs interdépendants. Je te conseille la lecture d'_Oracle Concepts_, pavé de 700 pages téléchargeable sur le site d'Oracle, pour te faire une idée de l'usine à gaz. Là-dessus tu rajoute la partie applicative, avec là aussi un certain niveau de complexité, et même un niveau de complexité certain, et tu as une bonne idée du bordel que peut représenter un réseau d'entreprise. Du coup il y a effectivement pas mal de boulot à faire avant de pouvoir lancer le shutdown final sans impacter toute la production. Je suppose que c'est ça que Stephane entendait par "reboot serieux".
-- Franck Yvonnet "Reality is that which, when you stop believing in it, doesn't go away." - Philip K. Dick
Ainsi Parlait nicolas vigier <boklm@mars-attacks.org>
On 2004-11-29, Julien BLACHE <jb@jblache.org> wrote:
Va dire ça à un DBA Oracle, je pense que le pauvre va se pisser dessus
de rire (ou de terreur à l'idée de devoir arrêter sa base).
On a dit un unix bien configure !
Justement, là on ne parle plus d'Unix (ou de Windows) mais d'Oracle qui
est un monde totalement à part. Et pour peu que ta base de données
représente une certaine taille, tu ne va plus avoir un serveur mais
toute une infrastructure de serveurs interdépendants. Je te conseille la
lecture d'_Oracle Concepts_, pavé de 700 pages téléchargeable sur le
site d'Oracle, pour te faire une idée de l'usine à gaz. Là-dessus tu
rajoute la partie applicative, avec là aussi un certain niveau de
complexité, et même un niveau de complexité certain, et tu as une bonne
idée du bordel que peut représenter un réseau d'entreprise. Du coup il y
a effectivement pas mal de boulot à faire avant de pouvoir lancer le
shutdown final sans impacter toute la production. Je suppose que c'est
ça que Stephane entendait par "reboot serieux".
--
Franck Yvonnet <fyvonnet@gmail.com>
"Reality is that which, when you stop believing in it, doesn't go away."
- Philip K. Dick
Va dire ça à un DBA Oracle, je pense que le pauvre va se pisser dessus de rire (ou de terreur à l'idée de devoir arrêter sa base).
On a dit un unix bien configure !
Justement, là on ne parle plus d'Unix (ou de Windows) mais d'Oracle qui
est un monde totalement à part. Et pour peu que ta base de données représente une certaine taille, tu ne va plus avoir un serveur mais toute une infrastructure de serveurs interdépendants. Je te conseille la lecture d'_Oracle Concepts_, pavé de 700 pages téléchargeable sur le site d'Oracle, pour te faire une idée de l'usine à gaz. Là-dessus tu rajoute la partie applicative, avec là aussi un certain niveau de complexité, et même un niveau de complexité certain, et tu as une bonne idée du bordel que peut représenter un réseau d'entreprise. Du coup il y a effectivement pas mal de boulot à faire avant de pouvoir lancer le shutdown final sans impacter toute la production. Je suppose que c'est ça que Stephane entendait par "reboot serieux".
-- Franck Yvonnet "Reality is that which, when you stop believing in it, doesn't go away." - Philip K. Dick
Franck Yvonnet
Ainsi Parlait Azathoth
Franck Yvonnet wrote in news::
Dans le monde réel tu as aussi des applicatifs et des bases de données qui tournent sur les serveurs, et qu'il faut arreter avant de pouvoir rebooter le système. C'est pas aussi trivial qu'un simple shutdown -r.
Le pire je crois que ce sont les arrets de serveurs pour maintenance electrique. Y a toujours au moins une bécane qui ne repart pas...
Non, le pire c'est les déménagements où tu as vraiment un concentré de problèmes qui te tombe dessus à l'arrivée entre les inévitables disques qui ont mal supporté le voyage, le réseau mal brassé, l'adressage IP à refaire, les applis qui ont du mal à repartir, etc...
-- Franck Yvonnet "Reality is that which, when you stop believing in it, doesn't go away." - Philip K. Dick
Ainsi Parlait Azathoth <azathoth@alussinan.org>
Franck Yvonnet <fyvonnet@gmail.com> wrote in
news:slrncqn1v3.p9d.fyvonnet@gwyneth.glou.net:
Dans le monde réel tu as aussi des applicatifs et des bases de données
qui tournent sur les serveurs, et qu'il faut arreter avant de pouvoir
rebooter le système. C'est pas aussi trivial qu'un simple shutdown -r.
Le pire je crois que ce sont les arrets de serveurs pour maintenance
electrique. Y a toujours au moins une bécane qui ne repart pas...
Non, le pire c'est les déménagements où tu as vraiment un concentré de
problèmes qui te tombe dessus à l'arrivée entre les inévitables disques
qui ont mal supporté le voyage, le réseau mal brassé, l'adressage IP à
refaire, les applis qui ont du mal à repartir, etc...
--
Franck Yvonnet <fyvonnet@gmail.com>
"Reality is that which, when you stop believing in it, doesn't go away."
- Philip K. Dick
Dans le monde réel tu as aussi des applicatifs et des bases de données qui tournent sur les serveurs, et qu'il faut arreter avant de pouvoir rebooter le système. C'est pas aussi trivial qu'un simple shutdown -r.
Le pire je crois que ce sont les arrets de serveurs pour maintenance electrique. Y a toujours au moins une bécane qui ne repart pas...
Non, le pire c'est les déménagements où tu as vraiment un concentré de problèmes qui te tombe dessus à l'arrivée entre les inévitables disques qui ont mal supporté le voyage, le réseau mal brassé, l'adressage IP à refaire, les applis qui ont du mal à repartir, etc...
-- Franck Yvonnet "Reality is that which, when you stop believing in it, doesn't go away." - Philip K. Dick
Nicolas Le Scouarnec
Euh, non, les ACL, ca n'est pas fait pour l'admin, c'est fait pour les utilisateurs. L'admin il a accès a tout, quelque soit l'OS (meme sous Windows normalement), alors il ne compte pas dans ma comparaison. Je ne suis pas d'accord, c'est meme un tres gros point faible d'Unix par
rapport a d'autres systemes. L'administrateur doit avoir acces au systeme, mais les donnees, elles, ne le regardent en aucune facon.
C'est vrai qu'elles ne le regardent pas, mais ca n'est pas un point faible d'Unix face a Windows en tout cas.
de tout le systeme sans avoir d'acces aux donnees elle memes. C'est possible avec Unix, mais force est de constater que c'est rarement pris en application.
Par curiosité, on fait comment sous Linux / FreeBSD ?
Sous Windows, je ne sais pas. Il me semble qu'on peut bloquer l'acces aux donnees, mais un specialiste pourra m'eclairer.
Sous Windows aussi, sauf que l'administrateur peux toujours installer une couche NFS, mapper les logins via NIS et ensuite sur la machine unix mettre son utilisateur avec l'UID de l'utilisateur qu'il veut lire. Effectivement, c'est tordu, mais c'est tout a fait réalisable, meme si l'utilisateur a enlevé les droits de lecture pour l'administrateur. Résultat, pas de sécurité supplémentaire (enfin, si, c'est un poil plus compliqué que de taper un simple "su").
L'administrateur peut aussi démarrer sur un disque ou une disquette de boot...
Résultat: pour vraiment interdire l'accès, il ne reste plus qu'a supprimer l'administrateur ou a crypter les données.
-- Nicolas Le Scouarnec
Euh, non, les ACL, ca n'est pas fait pour l'admin, c'est fait pour les
utilisateurs. L'admin il a accès a tout, quelque soit l'OS (meme sous
Windows normalement), alors il ne compte pas dans ma comparaison.
Je ne suis pas d'accord, c'est meme un tres gros point faible d'Unix par
rapport a d'autres systemes. L'administrateur doit avoir acces au
systeme, mais les donnees, elles, ne le regardent en aucune facon.
C'est vrai qu'elles ne le regardent pas, mais ca n'est pas un point
faible d'Unix face a Windows en tout cas.
de tout le systeme sans avoir d'acces aux donnees elle memes. C'est
possible avec Unix, mais force est de constater que c'est rarement pris
en application.
Par curiosité, on fait comment sous Linux / FreeBSD ?
Sous Windows, je ne sais pas. Il me semble qu'on peut bloquer l'acces
aux donnees, mais un specialiste pourra m'eclairer.
Sous Windows aussi, sauf que l'administrateur peux toujours installer
une couche NFS, mapper les logins via NIS et ensuite sur la machine
unix mettre son utilisateur avec l'UID de l'utilisateur qu'il veut
lire. Effectivement, c'est tordu, mais c'est tout a fait réalisable,
meme si l'utilisateur a enlevé les droits de lecture pour
l'administrateur. Résultat, pas de sécurité supplémentaire (enfin, si,
c'est un poil plus compliqué que de taper un simple "su").
L'administrateur peut aussi démarrer sur un disque ou une disquette de
boot...
Résultat: pour vraiment interdire l'accès, il ne reste plus qu'a
supprimer l'administrateur ou a crypter les données.
Euh, non, les ACL, ca n'est pas fait pour l'admin, c'est fait pour les utilisateurs. L'admin il a accès a tout, quelque soit l'OS (meme sous Windows normalement), alors il ne compte pas dans ma comparaison. Je ne suis pas d'accord, c'est meme un tres gros point faible d'Unix par
rapport a d'autres systemes. L'administrateur doit avoir acces au systeme, mais les donnees, elles, ne le regardent en aucune facon.
C'est vrai qu'elles ne le regardent pas, mais ca n'est pas un point faible d'Unix face a Windows en tout cas.
de tout le systeme sans avoir d'acces aux donnees elle memes. C'est possible avec Unix, mais force est de constater que c'est rarement pris en application.
Par curiosité, on fait comment sous Linux / FreeBSD ?
Sous Windows, je ne sais pas. Il me semble qu'on peut bloquer l'acces aux donnees, mais un specialiste pourra m'eclairer.
Sous Windows aussi, sauf que l'administrateur peux toujours installer une couche NFS, mapper les logins via NIS et ensuite sur la machine unix mettre son utilisateur avec l'UID de l'utilisateur qu'il veut lire. Effectivement, c'est tordu, mais c'est tout a fait réalisable, meme si l'utilisateur a enlevé les droits de lecture pour l'administrateur. Résultat, pas de sécurité supplémentaire (enfin, si, c'est un poil plus compliqué que de taper un simple "su").
L'administrateur peut aussi démarrer sur un disque ou une disquette de boot...
Résultat: pour vraiment interdire l'accès, il ne reste plus qu'a supprimer l'administrateur ou a crypter les données.
-- Nicolas Le Scouarnec
JKB
Le 30-11-2004, à propos de Re: Linux pour remplacer windows, Franck Yvonnet écrivait dans fr.comp.os.linux.debats :
Ainsi Parlait Azathoth
Franck Yvonnet wrote in news::
Dans le monde réel tu as aussi des applicatifs et des bases de données qui tournent sur les serveurs, et qu'il faut arreter avant de pouvoir rebooter le système. C'est pas aussi trivial qu'un simple shutdown -r.
Le pire je crois que ce sont les arrets de serveurs pour maintenance electrique. Y a toujours au moins une bécane qui ne repart pas...
Non, le pire c'est les déménagements où tu as vraiment un concentré de problèmes qui te tombe dessus à l'arrivée entre les inévitables disques qui ont mal supporté le voyage, le réseau mal brassé, l'adressage IP à refaire, les applis qui ont du mal à repartir, etc...
Meuh non... Ma hantise, c'est de rebooter un solaris qui vient juste d'être patché. La dernière fois, j'ai eu droit à un kernel panic. Comme cette U420R m'emm*rdait depuis longtemps (pas de gestion des users md5 malgré tous les patches possibles et immaginables, j'ai eu une bonne excuse pour mettre une debian dessus ;-) ).
JKB
Le 30-11-2004, à propos de
Re: Linux pour remplacer windows,
Franck Yvonnet écrivait dans fr.comp.os.linux.debats :
Ainsi Parlait Azathoth <azathoth@alussinan.org>
Franck Yvonnet <fyvonnet@gmail.com> wrote in
news:slrncqn1v3.p9d.fyvonnet@gwyneth.glou.net:
Dans le monde réel tu as aussi des applicatifs et des bases de données
qui tournent sur les serveurs, et qu'il faut arreter avant de pouvoir
rebooter le système. C'est pas aussi trivial qu'un simple shutdown -r.
Le pire je crois que ce sont les arrets de serveurs pour maintenance
electrique. Y a toujours au moins une bécane qui ne repart pas...
Non, le pire c'est les déménagements où tu as vraiment un concentré de
problèmes qui te tombe dessus à l'arrivée entre les inévitables disques
qui ont mal supporté le voyage, le réseau mal brassé, l'adressage IP à
refaire, les applis qui ont du mal à repartir, etc...
Meuh non... Ma hantise, c'est de rebooter un solaris qui vient juste
d'être patché. La dernière fois, j'ai eu droit à un kernel panic.
Comme cette U420R m'emm*rdait depuis longtemps (pas de gestion des
users md5 malgré tous les patches possibles et immaginables, j'ai eu
une bonne excuse pour mettre une debian dessus ;-) ).
Le 30-11-2004, à propos de Re: Linux pour remplacer windows, Franck Yvonnet écrivait dans fr.comp.os.linux.debats :
Ainsi Parlait Azathoth
Franck Yvonnet wrote in news::
Dans le monde réel tu as aussi des applicatifs et des bases de données qui tournent sur les serveurs, et qu'il faut arreter avant de pouvoir rebooter le système. C'est pas aussi trivial qu'un simple shutdown -r.
Le pire je crois que ce sont les arrets de serveurs pour maintenance electrique. Y a toujours au moins une bécane qui ne repart pas...
Non, le pire c'est les déménagements où tu as vraiment un concentré de problèmes qui te tombe dessus à l'arrivée entre les inévitables disques qui ont mal supporté le voyage, le réseau mal brassé, l'adressage IP à refaire, les applis qui ont du mal à repartir, etc...
Meuh non... Ma hantise, c'est de rebooter un solaris qui vient juste d'être patché. La dernière fois, j'ai eu droit à un kernel panic. Comme cette U420R m'emm*rdait depuis longtemps (pas de gestion des users md5 malgré tous les patches possibles et immaginables, j'ai eu une bonne excuse pour mettre une debian dessus ;-) ).
JKB
Nicolas George
Nicolas Le Scouarnec , dans le message , a écrit :
Résultat: pour vraiment interdire l'accès, il ne reste plus qu'a supprimer l'administrateur ou a crypter les données.
Même chiffrer les données apporte peu : les données, pour être utiles, doivent être déchiffrées à un moment ou à un autre, et l'administrateur de la machine où ce déchiffrement se produit peut toujours intercepter à ce moment-là. Donc le chiffrement ne va te faire gagner en sécurité que si tu utilises la machine uniquement pour stocker les données chiffrées, et que toute utilisation réelle se fait ailleurs.
Nicolas Le Scouarnec , dans le message
<slrncqoe8e.3aj.root@shiva.india.ath.cx>, a écrit :
Résultat: pour vraiment interdire l'accès, il ne reste plus qu'a
supprimer l'administrateur ou a crypter les données.
Même chiffrer les données apporte peu : les données, pour être utiles,
doivent être déchiffrées à un moment ou à un autre, et l'administrateur de
la machine où ce déchiffrement se produit peut toujours intercepter à ce
moment-là. Donc le chiffrement ne va te faire gagner en sécurité que si tu
utilises la machine uniquement pour stocker les données chiffrées, et que
toute utilisation réelle se fait ailleurs.
Nicolas Le Scouarnec , dans le message , a écrit :
Résultat: pour vraiment interdire l'accès, il ne reste plus qu'a supprimer l'administrateur ou a crypter les données.
Même chiffrer les données apporte peu : les données, pour être utiles, doivent être déchiffrées à un moment ou à un autre, et l'administrateur de la machine où ce déchiffrement se produit peut toujours intercepter à ce moment-là. Donc le chiffrement ne va te faire gagner en sécurité que si tu utilises la machine uniquement pour stocker les données chiffrées, et que toute utilisation réelle se fait ailleurs.
Stephane TOUGARD
Nicolas George wrote:
Quel que soit l'OS, il y a un certain nombre d'opérations qui donnent mécaniquement à celui qui peut les effectuer tout pouvoir sur la machine, c'est inévitable. La possibilité de charger un module/driver dans le noyau, par exemple. D'ailleurs, même simplement le pouvoir d'upgrader le shell utilisé par d'autres donne le pouvoir de contrôler leurs actions (à condition d'attendre qu'ils se loguent).
Je ne suis pas certain que ce que tu dis soit tout a fait exact sur un systeme A3 par exemple. Pour info, Unix est C1 par defaut, c'est a dire tres loin derriere.
Bref, il y a pas qu'Unix dans la vie (mais si c'est de tres loin le plus fun de tous).
-- http://www.unices.org
Nicolas George wrote:
Quel que soit l'OS, il y a un certain nombre d'opérations qui donnent
mécaniquement à celui qui peut les effectuer tout pouvoir sur la machine,
c'est inévitable. La possibilité de charger un module/driver dans le noyau,
par exemple. D'ailleurs, même simplement le pouvoir d'upgrader le shell
utilisé par d'autres donne le pouvoir de contrôler leurs actions (à
condition d'attendre qu'ils se loguent).
Je ne suis pas certain que ce que tu dis soit tout a fait exact sur un
systeme A3 par exemple. Pour info, Unix est C1 par defaut, c'est a dire
tres loin derriere.
Bref, il y a pas qu'Unix dans la vie (mais si c'est de tres loin le plus
fun de tous).
Quel que soit l'OS, il y a un certain nombre d'opérations qui donnent mécaniquement à celui qui peut les effectuer tout pouvoir sur la machine, c'est inévitable. La possibilité de charger un module/driver dans le noyau, par exemple. D'ailleurs, même simplement le pouvoir d'upgrader le shell utilisé par d'autres donne le pouvoir de contrôler leurs actions (à condition d'attendre qu'ils se loguent).
Je ne suis pas certain que ce que tu dis soit tout a fait exact sur un systeme A3 par exemple. Pour info, Unix est C1 par defaut, c'est a dire tres loin derriere.
Bref, il y a pas qu'Unix dans la vie (mais si c'est de tres loin le plus fun de tous).
