SecureLevel

[tempus <crem_crem AT hotmail POINT com>]

Bonjour,

Voilà je dois rendre un mémoire sur l'implémentation d'un serveur sécurisé
sous OpenBSD 3.9.
J'ai donc entrepris de traduire la page du man concernant le secure level...

Je le poste donc ici, il me semble que ça pourra servir... Néanmoins mon
niveau en anglais étant assez bas est ma connaissance d'OpenBSD étant
limité, si certaines personne veulent bien me donner un coup de main... Tant
au niveau technique que linguistique. Merci d'avance.

Deux chose que je ne cerne pas :
A quoi correspondes les "raw disk device" ?
Et "append-only file flags" ?


------------------------------------------
NOM
	SecureLevel – Les securelevels et leurs effets.

SYNOPSIS
	Le noyau d'OpenBSD fournit 4 niveaux de sécurité système.

- 1 : Mode vulnérable permanent (Permanently insecure mode)
- init(8) n'essaiera pas d'augmenter le SecureLevel
- peut seulement être configurer avec sysctl lorsque le système est
vulnérable
- autrement, identique au mode 0

0 : Mode vulnérable (Insecure mode)
- utilisé lors de la phase de démarrage (bootstrapping) et lorsque le
système est en utilisateur unique
- tous les périphériques peuvent être lus ou écrit en fonction de leurs
permissions
- flags des systèmes de fichiers peuvat être effacé

1 : Mode sécurisé (Secure mode)
- mode de sécurité par défaut quand le système est en multi-utilisateur
- niveau de sécurité ne peut être d'avantage baissé excepté par init
- /dev/mem et /dev/kmem ne peuvent être modifié
- (raw disk device) périphériques de système de fichiers monté sont en
lecture seul 
- système immuable et flags des fichiers ne peuvent être effacés
- modules du noyau ne peuvent chargé ou décharger
- la variable fs.posix.setuid – sysctl (8) – ne peut être modifié
- la variable net.inet.ip.sourceroute – sysctl (8) – ne peut être modifié
- la variable machdep.kbdrest – sysctl (8) – ne peut être modifié

2 : Mode hautement sécurisé (Highly secure mode)
- effets du securelevel 1
- (raw disk device) périphérique sont toujours en lecture seul qu'il soit
monté ou non
- setimeofday (2) et clock settime (2) ne peuvent être modifier (on ne peut
retarder l'heure) ou être débordé
- règles de filtrage et de translation d'adresse ne peuvent être modifiés –
pfctl (8)
- les variables ddb.console et ddb.panic – sysctl (8) – ne peuvent être
augmenter

DESCRIPTION
Le SecureLevel fournis des moyens commode d'adapter la sécurité du système
en fonction de l'environnement. Il est normalement configurer au boot via le
script rc.securelevel (8), ou le super-utilisateur peut augmenter le
SecureLevel en tout temps en modifiant la variable kern.securelevel – sysctl
(8) –. Néanmoins, init (8) et le seul à pouvoir baisser le SecureLevel, la
variable étant bloquer une fois le démarrage établi. Un noyau construit avec
l'option INSECURE dans le fichier de configuration sera par défaut en mode
vulnérable permanent (Permanently insecure mode).

Le mode hautement sécurisé peut apparaître comme draconien, mais il est
considéré comme la dernière ligne de défense si le compte super-utilisateur
est compromis. Ses effets exclu l'utilisation inapproprié des flags de
fichier en modifiant directement un périphérique (raw disk device), ou en
effaçant un système de fichier au moyen de newfs (8). Autrement, il limite
les dommages potentiels d'un par-feu  compromis en interdisant les
modification des règles de packet filter. Il interdit également de rretarder
le système d'horloge, afin de préserver l'intégrité des logs. Timekepping
n'est pas affecter car l'horloge peut toutefois être ralentie (??).

Puisque le SecureLevel peut être modifié avec le debugger interne du noyau
ddb (4), des moyens commodes et gelant fortement différentes fonctions (??),
fournissent un système hautement sécurisé. Ceci est faisable en configurant
ddb.console et ddb.panic à 0 avec l'utilitaire sysctl(8).

FICHIERS
/etc/rc.securelevel : permet d'executer des commande au démarrage avant que
le niveau de sécurité ne change.

VOIR AUSSI
	chflags (2), settimeofday (2), mem (4), options (4), inti (8), rc (8),
sysctl (8)

HISTORY
	La première apparition de la page du manuel  'SecureLevel' était dans
OpenBSD 2.6.

BUGS
	La liste des effets des différents modes du SecureLevel n'est sûrement pas
complète.

OpenBSD 3.9			le 4 Janvier 2000

-------------------

Voilà, j'ai mis des ?? au endroits qui me paraissait louche

Merci et bonne ap 
+


-- 
View this message in context: http://www.nabble.com/SecureLevel-tf2201698.html#a6095960
Sent from the openbsd - France forum at Nabble.com.