Je trouve finalement étonnant que tout le monde s'accomode ici sans
râler d'insuffisances franchement désolantes de certaines applis livrées
avec Mac OS X, et je me dis que si on n'en parle pas sur les groupes, ça
va finir par laisser penser à Apple qu'il n'y a rien d'urgent à faire
dans ce domaine !
Parce que, de vous à moi :
- Avec toutes les qualités que je veux bien lui reconnaître, ne
trouvez-vous pas qu'AppleWorks commence à sentir un peu le moisi, ne
serait-ce qu'au niveau de l'apparence ?
- L'impossibilité dans ce logiciel comme dans Carnet d'adresse de
pouvoir imprimer des étiquettes à l'unité en partant d'une planche déjà
entammée (à l'étiquette "x") comme savait déjà le faire JoliPhone/Carnet
il y a plus de dix ans, ça ne vous semble pas du gâchis ?
- L'impossibilité de choisir les polices de caractère (et surtout leur
taille) dans iCal, que ce soit à l'écran ou à l'impression (et surtout
indépendamment l'une de l'autre) ne vous semble-t-elle pas gavante et
sérieusement limitante ?
- L'impossibilité d'utiliser le "fabuleux" AirTunes avec autre chose que
iTunes, et en particulier sa non-intégration dans le système pour
diffuser simplement le son d'une séquence QuickTime, en principe
pourtant intégré très "bas" dans le système... c'est pas un peu la haine
et prendre les gens pour des khons ?
- L'impossibilité pour Apple Remote Desktop d'accéder à une session
ouverte en arrière-plan et son incapacité à gérer autre chose que ce qui
est affiché à l'écran du poste distant ne constitue-t-elle pas une
limitation très dommageable de ce logiciel ? (par rapport au
fonctionnement multi-utilisateur de Mac OS X par ailleurs !).
- et finalement est-il si normal que cela que le mode "Target" de boot
en disque cible donne accès à l'ensemble du disque interne sans tenir
aucun compte des autorisations de ses dossiers ?
Je tiens pour possible d'avoir éventuellement faux sur un point ou un
autre, et serais heureux qu'on me sorte alors de l'erreur ! Sinon il y a
du boulot à abattre pour Tiger !
À (at) Sun, 14 Nov 2004 10:33:20 +0100, Patrick Stadelmann écrivait (wrote):
Oui, j'ai bien compris. Mais je répète que l'accès aux données (après changement du mot de passe) n'est pas le problème : c'est le but même du mot de passe principal ! Par contre, puisque : 1) on peut monter l'image avec le mot de passe du compte, et 2) le mot de passe principal est tout ce qui est nécessaire pour accéder au compte, ça signifie que le mot de passe principal permet à l'OS d'extraire le mot de passe utilisateur. Si ce moyen existe pour l'OS, il existe pour un administrateur bidouilleur.
Par rapport à la situation où FileVault n'est pas utilisé, on peut donc considérer que le mot de passe de l'utilisateur est moins bien protégé ce qui ne devrait pas être le cas.
Ce n'est pas nécessairement le cas. On peut imaginer qu'une image FileVault est crypté avec un clef choisie au hasard et que c'est uniquement cette clé qui est cryptée deux fois avec le mot de passe utilisateur et le mot de passe principal. En tous cas, cela correspondrai mieux aux critères habituels de sécurité.
Mais le fait que l'on puisse monter l'image directement dans le Finder en donnant le mot de passe de l'utilisateur semble indiquer que ce n'est pas comme cela que c'est implémenté.
A moins que DiskImageMounter sache reconnaître une image FileVault et localiser sa clé aléatoire, même quand le disque est monté en mode Target...
Patrick -- Patrick Stadelmann
In article <r7brdygpud.fsf@pasteur.enstimac.fr>,
Paul Gaborit <Paul.Gaborit@invalid.invalid> wrote:
À (at) Sun, 14 Nov 2004 10:33:20 +0100,
Patrick Stadelmann <Patrick.Stadelmann@unine.ch> écrivait (wrote):
Oui, j'ai bien compris. Mais je répète que l'accès aux données (après
changement du mot de passe) n'est pas le problème : c'est le but même du
mot de passe principal ! Par contre, puisque : 1) on peut monter l'image
avec le mot de passe du compte, et 2) le mot de passe principal est tout
ce qui est nécessaire pour accéder au compte, ça signifie que le mot de
passe principal permet à l'OS d'extraire le mot de passe utilisateur. Si
ce moyen existe pour l'OS, il existe pour un administrateur bidouilleur.
Par rapport à la situation où FileVault n'est pas utilisé, on peut donc
considérer que le mot de passe de l'utilisateur est moins bien protégé
ce qui ne devrait pas être le cas.
Ce n'est pas nécessairement le cas. On peut imaginer qu'une image FileVault
est crypté avec un clef choisie au hasard et que c'est uniquement cette clé
qui est cryptée deux fois avec le mot de passe utilisateur et le mot de passe
principal. En tous cas, cela correspondrai mieux aux critères habituels de
sécurité.
Mais le fait que l'on puisse monter l'image directement dans le Finder
en donnant le mot de passe de l'utilisateur semble indiquer que ce n'est
pas comme cela que c'est implémenté.
A moins que DiskImageMounter sache reconnaître une image FileVault et
localiser sa clé aléatoire, même quand le disque est monté en mode
Target...
Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>
À (at) Sun, 14 Nov 2004 10:33:20 +0100, Patrick Stadelmann écrivait (wrote):
Oui, j'ai bien compris. Mais je répète que l'accès aux données (après changement du mot de passe) n'est pas le problème : c'est le but même du mot de passe principal ! Par contre, puisque : 1) on peut monter l'image avec le mot de passe du compte, et 2) le mot de passe principal est tout ce qui est nécessaire pour accéder au compte, ça signifie que le mot de passe principal permet à l'OS d'extraire le mot de passe utilisateur. Si ce moyen existe pour l'OS, il existe pour un administrateur bidouilleur.
Par rapport à la situation où FileVault n'est pas utilisé, on peut donc considérer que le mot de passe de l'utilisateur est moins bien protégé ce qui ne devrait pas être le cas.
Ce n'est pas nécessairement le cas. On peut imaginer qu'une image FileVault est crypté avec un clef choisie au hasard et que c'est uniquement cette clé qui est cryptée deux fois avec le mot de passe utilisateur et le mot de passe principal. En tous cas, cela correspondrai mieux aux critères habituels de sécurité.
Mais le fait que l'on puisse monter l'image directement dans le Finder en donnant le mot de passe de l'utilisateur semble indiquer que ce n'est pas comme cela que c'est implémenté.
A moins que DiskImageMounter sache reconnaître une image FileVault et localiser sa clé aléatoire, même quand le disque est monté en mode Target...
Patrick -- Patrick Stadelmann
Paul Gaborit
À (at) Tue, 16 Nov 2004 09:43:01 +0100, Patrick Stadelmann écrivait (wrote):
Mais le fait que l'on puisse monter l'image directement dans le Finder en donnant le mot de passe de l'utilisateur semble indiquer que ce n'est pas comme cela que c'est implémenté.
Heu... Pourquoi ?
A moins que DiskImageMounter sache reconnaître une image FileVault et localiser sa clé aléatoire, même quand le disque est monté en mode Target...
Donc c'est plausible... et plus plaisant que d'imaginer que les mots de passe des utilisateurs sont stockés quelque part sur le disque (même chiffré par le fameux mot de passe principal).
-- Paul Gaborit - <http://www.enstimac.fr/~gaborit/>
À (at) Tue, 16 Nov 2004 09:43:01 +0100,
Patrick Stadelmann <Patrick.Stadelmann@unine.ch> écrivait (wrote):
Mais le fait que l'on puisse monter l'image directement dans le Finder
en donnant le mot de passe de l'utilisateur semble indiquer que ce n'est
pas comme cela que c'est implémenté.
Heu... Pourquoi ?
A moins que DiskImageMounter sache reconnaître une image FileVault et
localiser sa clé aléatoire, même quand le disque est monté en mode
Target...
Donc c'est plausible... et plus plaisant que d'imaginer que les mots de passe
des utilisateurs sont stockés quelque part sur le disque (même chiffré par le
fameux mot de passe principal).
--
Paul Gaborit - <http://www.enstimac.fr/~gaborit/>
À (at) Tue, 16 Nov 2004 09:43:01 +0100, Patrick Stadelmann écrivait (wrote):
Mais le fait que l'on puisse monter l'image directement dans le Finder en donnant le mot de passe de l'utilisateur semble indiquer que ce n'est pas comme cela que c'est implémenté.
Heu... Pourquoi ?
A moins que DiskImageMounter sache reconnaître une image FileVault et localiser sa clé aléatoire, même quand le disque est monté en mode Target...
Donc c'est plausible... et plus plaisant que d'imaginer que les mots de passe des utilisateurs sont stockés quelque part sur le disque (même chiffré par le fameux mot de passe principal).
-- Paul Gaborit - <http://www.enstimac.fr/~gaborit/>
Patrick Stadelmann
In article , Paul Gaborit wrote:
À (at) Tue, 16 Nov 2004 09:43:01 +0100, Patrick Stadelmann écrivait (wrote):
Mais le fait que l'on puisse monter l'image directement dans le Finder en donnant le mot de passe de l'utilisateur semble indiquer que ce n'est pas comme cela que c'est implémenté.
Heu... Pourquoi ?
Ca suppose que DiskImageMounter sache tout d'abord identifier que l'image en question est un modèle FileVault. Ensuite, il faut qu'il trouve le fichier contenant la clé de décryptage. Si le disque contient plusieurs comptes FileVault, il faut aussi qu'il sache de quelle clé de décryptage il a besoin (donc qu'il puisse déterminer à quel compte l'image est associée). Ca me semble un peut compliqué...
A moins que DiskImageMounter sache reconnaître une image FileVault et localiser sa clé aléatoire, même quand le disque est monté en mode Target...
Donc c'est plausible... et plus plaisant que d'imaginer que les mots de passe des utilisateurs sont stockés quelque part sur le disque (même chiffré par le fameux mot de passe principal).
Je pense aussi que ce serait une meilleure approche.
Patrick -- Patrick Stadelmann
In article <r7u0rpg6jz.fsf@pasteur.enstimac.fr>,
Paul Gaborit <Paul.Gaborit@invalid.invalid> wrote:
À (at) Tue, 16 Nov 2004 09:43:01 +0100,
Patrick Stadelmann <Patrick.Stadelmann@unine.ch> écrivait (wrote):
Mais le fait que l'on puisse monter l'image directement dans le Finder
en donnant le mot de passe de l'utilisateur semble indiquer que ce n'est
pas comme cela que c'est implémenté.
Heu... Pourquoi ?
Ca suppose que DiskImageMounter sache tout d'abord identifier que
l'image en question est un modèle FileVault. Ensuite, il faut qu'il
trouve le fichier contenant la clé de décryptage. Si le disque contient
plusieurs comptes FileVault, il faut aussi qu'il sache de quelle clé de
décryptage il a besoin (donc qu'il puisse déterminer à quel compte
l'image est associée). Ca me semble un peut compliqué...
A moins que DiskImageMounter sache reconnaître une image FileVault et
localiser sa clé aléatoire, même quand le disque est monté en mode
Target...
Donc c'est plausible... et plus plaisant que d'imaginer que les mots de passe
des utilisateurs sont stockés quelque part sur le disque (même chiffré par le
fameux mot de passe principal).
Je pense aussi que ce serait une meilleure approche.
Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>
À (at) Tue, 16 Nov 2004 09:43:01 +0100, Patrick Stadelmann écrivait (wrote):
Mais le fait que l'on puisse monter l'image directement dans le Finder en donnant le mot de passe de l'utilisateur semble indiquer que ce n'est pas comme cela que c'est implémenté.
Heu... Pourquoi ?
Ca suppose que DiskImageMounter sache tout d'abord identifier que l'image en question est un modèle FileVault. Ensuite, il faut qu'il trouve le fichier contenant la clé de décryptage. Si le disque contient plusieurs comptes FileVault, il faut aussi qu'il sache de quelle clé de décryptage il a besoin (donc qu'il puisse déterminer à quel compte l'image est associée). Ca me semble un peut compliqué...
A moins que DiskImageMounter sache reconnaître une image FileVault et localiser sa clé aléatoire, même quand le disque est monté en mode Target...
Donc c'est plausible... et plus plaisant que d'imaginer que les mots de passe des utilisateurs sont stockés quelque part sur le disque (même chiffré par le fameux mot de passe principal).
Je pense aussi que ce serait une meilleure approche.
Patrick -- Patrick Stadelmann
Paul Gaborit
À (at) Tue, 16 Nov 2004 17:23:54 +0100, Patrick Stadelmann écrivait (wrote):
Ca suppose que DiskImageMounter sache tout d'abord identifier que l'image en question est un modèle FileVault. Ensuite, il faut qu'il trouve le fichier contenant la clé de décryptage. Si le disque contient plusieurs comptes FileVault, il faut aussi qu'il sache de quelle clé de décryptage il a besoin (donc qu'il puisse déterminer à quel compte l'image est associée). Ca me semble un peut compliqué...
À mon avis, je dirais que la clé est stockée deux fois directement dans l'image FileVault : une fois chiffrée par le mot de passe utilisateur et une fois chiffrée par le mot de passe principal (et effectivement DiskImageMounter doit savoir reconnaître que c'est une image FileVault).
-- Paul Gaborit - <http://www.enstimac.fr/~gaborit/>
À (at) Tue, 16 Nov 2004 17:23:54 +0100,
Patrick Stadelmann <Patrick.Stadelmann@unine.ch> écrivait (wrote):
Ca suppose que DiskImageMounter sache tout d'abord identifier que
l'image en question est un modèle FileVault. Ensuite, il faut qu'il
trouve le fichier contenant la clé de décryptage. Si le disque contient
plusieurs comptes FileVault, il faut aussi qu'il sache de quelle clé de
décryptage il a besoin (donc qu'il puisse déterminer à quel compte
l'image est associée). Ca me semble un peut compliqué...
À mon avis, je dirais que la clé est stockée deux fois directement dans
l'image FileVault : une fois chiffrée par le mot de passe utilisateur et une
fois chiffrée par le mot de passe principal (et effectivement DiskImageMounter
doit savoir reconnaître que c'est une image FileVault).
--
Paul Gaborit - <http://www.enstimac.fr/~gaborit/>
À (at) Tue, 16 Nov 2004 17:23:54 +0100, Patrick Stadelmann écrivait (wrote):
Ca suppose que DiskImageMounter sache tout d'abord identifier que l'image en question est un modèle FileVault. Ensuite, il faut qu'il trouve le fichier contenant la clé de décryptage. Si le disque contient plusieurs comptes FileVault, il faut aussi qu'il sache de quelle clé de décryptage il a besoin (donc qu'il puisse déterminer à quel compte l'image est associée). Ca me semble un peut compliqué...
À mon avis, je dirais que la clé est stockée deux fois directement dans l'image FileVault : une fois chiffrée par le mot de passe utilisateur et une fois chiffrée par le mot de passe principal (et effectivement DiskImageMounter doit savoir reconnaître que c'est une image FileVault).
-- Paul Gaborit - <http://www.enstimac.fr/~gaborit/>
Patrick Stadelmann
In article , Paul Gaborit wrote:
À mon avis, je dirais que la clé est stockée deux fois directement dans l'image FileVault : une fois chiffrée par le mot de passe utilisateur
Je n'y avais pas pensé... C'est très probable en effet. La rapidité avec laquelle se passe la mise à jour en cas de changement du mot de passe utilisateur semble exclure que le mot de passe soit directement utilisé pour chiffrer l'image.
et une fois chiffrée par le mot de passe principal
Elle est probablement stockée dans FileVaultMaster.keychain : ça permet de changer le mot de passe principal sans devoir modifier toutes les images, et ça explique que si l'on détruit ce fichier on ne puisse plus utiliser le mot de passe principal.
Patrick -- Patrick Stadelmann
In article <r7actgfk09.fsf@pasteur.enstimac.fr>,
Paul Gaborit <Paul.Gaborit@invalid.invalid> wrote:
À mon avis, je dirais que la clé est stockée deux fois directement dans
l'image FileVault : une fois chiffrée par le mot de passe utilisateur
Je n'y avais pas pensé... C'est très probable en effet. La rapidité avec
laquelle se passe la mise à jour en cas de changement du mot de passe
utilisateur semble exclure que le mot de passe soit directement utilisé
pour chiffrer l'image.
et une
fois chiffrée par le mot de passe principal
Elle est probablement stockée dans FileVaultMaster.keychain : ça permet
de changer le mot de passe principal sans devoir modifier toutes les
images, et ça explique que si l'on détruit ce fichier on ne puisse plus
utiliser le mot de passe principal.
Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>
À mon avis, je dirais que la clé est stockée deux fois directement dans l'image FileVault : une fois chiffrée par le mot de passe utilisateur
Je n'y avais pas pensé... C'est très probable en effet. La rapidité avec laquelle se passe la mise à jour en cas de changement du mot de passe utilisateur semble exclure que le mot de passe soit directement utilisé pour chiffrer l'image.
et une fois chiffrée par le mot de passe principal
Elle est probablement stockée dans FileVaultMaster.keychain : ça permet de changer le mot de passe principal sans devoir modifier toutes les images, et ça explique que si l'on détruit ce fichier on ne puisse plus utiliser le mot de passe principal.
Patrick -- Patrick Stadelmann
laurent.pertois
Patrick Stadelmann wrote:
Elle est probablement stockée dans FileVaultMaster.keychain : ça permet de changer le mot de passe principal sans devoir modifier toutes les images, et ça explique que si l'on détruit ce fichier on ne puisse plus utiliser le mot de passe principal.
Et le FileVaultMaster.cer ne sous-entendrait-il pas que l'on ait un système de certificats ?
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Patrick Stadelmann <Patrick.Stadelmann@unine.ch> wrote:
Elle est probablement stockée dans FileVaultMaster.keychain : ça permet
de changer le mot de passe principal sans devoir modifier toutes les
images, et ça explique que si l'on détruit ce fichier on ne puisse plus
utiliser le mot de passe principal.
Et le FileVaultMaster.cer ne sous-entendrait-il pas que l'on ait un
système de certificats ?
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
Elle est probablement stockée dans FileVaultMaster.keychain : ça permet de changer le mot de passe principal sans devoir modifier toutes les images, et ça explique que si l'on détruit ce fichier on ne puisse plus utiliser le mot de passe principal.
Et le FileVaultMaster.cer ne sous-entendrait-il pas que l'on ait un système de certificats ?
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Frederic PONCET
- Avec toutes les qualités que je veux bien lui reconnaître, ne trouvez-vous pas qu'AppleWorks commence à sentir un peu le moisi, ne serait-ce qu'au niveau de l'apparence ?
Tout à fait d'accord. Sans parler des bugs.
Les autres insuffisances me semblent plus "pardonnables"
- et finalement est-il si normal que cela que le mode "Target" de boot en disque cible donne accès à l'ensemble du disque interne sans tenir aucun compte des autorisations de ses dossiers ?
Je ne vois pas comment il pourrait en être autrement. Je veux dire, quel compte utilisateur d'un Mac pourrait légitimement accéder aux données d'un autre Mac en disque cible si ce dernier gérait les autorisations?
Le mode "target" fait de l'ordinateur un vulgaire disque dur, et non un serveur. Toute personne qui a accès à ce disque peut voir son contenu.
La seule protection possible en l'occurrence, je pense, est d'activer le mot de passe de l'Open FirmWare. Je n'ai pas vérifié, mais je suppose que dans ce cas le démarrage en mode "target" est subordonné à la saisie du mot de passe.
Attention, avec l'Open FirmWare on est en clavier Qwerty. Ne pas oublier que le "M" est à la place du "?", entre autres différences. -- "Il faut être absolument moderne" (Arthur Rimbaud)
http://www.frederic-poncet.com/
- Avec toutes les qualités que je veux bien lui reconnaître, ne
trouvez-vous pas qu'AppleWorks commence à sentir un peu le moisi, ne
serait-ce qu'au niveau de l'apparence ?
Tout à fait d'accord. Sans parler des bugs.
Les autres insuffisances me semblent plus "pardonnables"
- et finalement est-il si normal que cela que le mode "Target" de boot
en disque cible donne accès à l'ensemble du disque interne sans tenir
aucun compte des autorisations de ses dossiers ?
Je ne vois pas comment il pourrait en être autrement. Je veux dire, quel
compte utilisateur d'un Mac pourrait légitimement accéder aux données
d'un autre Mac en disque cible si ce dernier gérait les autorisations?
Le mode "target" fait de l'ordinateur un vulgaire disque dur, et non un
serveur. Toute personne qui a accès à ce disque peut voir son contenu.
La seule protection possible en l'occurrence, je pense, est d'activer le
mot de passe de l'Open FirmWare. Je n'ai pas vérifié, mais je suppose
que dans ce cas le démarrage en mode "target" est subordonné à la saisie
du mot de passe.
Attention, avec l'Open FirmWare on est en clavier Qwerty. Ne pas oublier
que le "M" est à la place du "?", entre autres différences.
--
"Il faut être absolument moderne" (Arthur Rimbaud)
- Avec toutes les qualités que je veux bien lui reconnaître, ne trouvez-vous pas qu'AppleWorks commence à sentir un peu le moisi, ne serait-ce qu'au niveau de l'apparence ?
Tout à fait d'accord. Sans parler des bugs.
Les autres insuffisances me semblent plus "pardonnables"
- et finalement est-il si normal que cela que le mode "Target" de boot en disque cible donne accès à l'ensemble du disque interne sans tenir aucun compte des autorisations de ses dossiers ?
Je ne vois pas comment il pourrait en être autrement. Je veux dire, quel compte utilisateur d'un Mac pourrait légitimement accéder aux données d'un autre Mac en disque cible si ce dernier gérait les autorisations?
Le mode "target" fait de l'ordinateur un vulgaire disque dur, et non un serveur. Toute personne qui a accès à ce disque peut voir son contenu.
La seule protection possible en l'occurrence, je pense, est d'activer le mot de passe de l'Open FirmWare. Je n'ai pas vérifié, mais je suppose que dans ce cas le démarrage en mode "target" est subordonné à la saisie du mot de passe.
Attention, avec l'Open FirmWare on est en clavier Qwerty. Ne pas oublier que le "M" est à la place du "?", entre autres différences. -- "Il faut être absolument moderne" (Arthur Rimbaud)
http://www.frederic-poncet.com/
laurent.pertois
Frederic PONCET wrote:
La seule protection possible en l'occurrence, je pense, est d'activer le mot de passe de l'Open FirmWare. Je n'ai pas vérifié, mais je suppose que dans ce cas le démarrage en mode "target" est subordonné à la saisie du mot de passe.
Oui.
Attention, avec l'Open FirmWare on est en clavier Qwerty. Ne pas oublier que le "M" est à la place du "?", entre autres différences.
Il n'y a pas que ça qui change ;-)
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
La seule protection possible en l'occurrence, je pense, est d'activer le
mot de passe de l'Open FirmWare. Je n'ai pas vérifié, mais je suppose
que dans ce cas le démarrage en mode "target" est subordonné à la saisie
du mot de passe.
Oui.
Attention, avec l'Open FirmWare on est en clavier Qwerty. Ne pas oublier
que le "M" est à la place du "?", entre autres différences.
Il n'y a pas que ça qui change ;-)
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
La seule protection possible en l'occurrence, je pense, est d'activer le mot de passe de l'Open FirmWare. Je n'ai pas vérifié, mais je suppose que dans ce cas le démarrage en mode "target" est subordonné à la saisie du mot de passe.
Oui.
Attention, avec l'Open FirmWare on est en clavier Qwerty. Ne pas oublier que le "M" est à la place du "?", entre autres différences.
Il n'y a pas que ça qui change ;-)
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
manu
Frederic PONCET wrote:
La seule protection possible en l'occurrence, je pense, est d'activer le mot de passe de l'Open FirmWare. Je n'ai pas vérifié, mais je suppose que dans ce cas le démarrage en mode "target" est subordonné à la saisie du mot de passe.
Un mot de passe dans OF, ca resiste à un zappage de PRAM?
-- Emmanuel Dreyfus Le cahier de l'admin BSD 2eme ed. est dans toutes les bonnes librairies http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php
La seule protection possible en l'occurrence, je pense, est d'activer le
mot de passe de l'Open FirmWare. Je n'ai pas vérifié, mais je suppose
que dans ce cas le démarrage en mode "target" est subordonné à la saisie
du mot de passe.
Un mot de passe dans OF, ca resiste à un zappage de PRAM?
--
Emmanuel Dreyfus
Le cahier de l'admin BSD 2eme ed. est dans toutes les bonnes librairies
http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php
manu@netbsd.org
La seule protection possible en l'occurrence, je pense, est d'activer le mot de passe de l'Open FirmWare. Je n'ai pas vérifié, mais je suppose que dans ce cas le démarrage en mode "target" est subordonné à la saisie du mot de passe.
Un mot de passe dans OF, ca resiste à un zappage de PRAM?
-- Emmanuel Dreyfus Le cahier de l'admin BSD 2eme ed. est dans toutes les bonnes librairies http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php
laurent.pertois
Emmanuel Dreyfus wrote:
Un mot de passe dans OF, ca resiste à un zappage de PRAM?
Oui sauf si tu as d'abord changé la config mémoire de la machine.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Emmanuel Dreyfus <manu@netbsd.org> wrote:
Un mot de passe dans OF, ca resiste à un zappage de PRAM?
Oui sauf si tu as d'abord changé la config mémoire de la machine.
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
Un mot de passe dans OF, ca resiste à un zappage de PRAM?
Oui sauf si tu as d'abord changé la config mémoire de la machine.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
