IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
logo

FAQ BSDConsultez toutes les FAQ

Nombre d'auteurs : 6, nombre de questions : 127, dernière mise à jour : 20 novembre 2007  Ajouter une question

 

Cette FAQ a été réalisée à partir des contributions des membres du forum Unix de developpez.com et de l'équipe de rédaction.

Organisation : cette FAQ se compose de deux grandes parties. Une première, Questions générales, qui regroupe toutes les questions qui trouvent une réponse, commune ou non, pour l'ensemble des systèmes BSD. La deuxième est découpée en autant de sous-parties qu'il y a de systèmes BSD soit parce que la question est spécialisée soit parce que la réponse est incomplète pour qu'elle concerne chacun de ces systèmes.

Participer : nous sommes perpétuellement à l'écoute de vos suggestions et corrections, aussi mineures soient-elles. N'hésitez pas à nous en faire part par l'intermédiaire de la discussion prévue à cet effet .

Note : l'exactitude des informations figurant dans la présente FAQ sont autant que possible vérifiée avant intégration. Cependant, nous ne pouvons garantir l'absence de toute erreur, c'est pourquoi les auteurs ne pourront en aucun cas être tenus pour responsables.

SommaireQuestions généralesSystèmeSécurité (3)
précédent sommaire suivant
 

La protection du mode mono-utilisateur consiste à demander le mot de passe de l'administrateur avant de lui donner accès aux shells avec tous ses droits (il n'est pas demandé par défaut) :

  • FreeBSD : éditez le fichier /etc/ttys puis remplacez la ligne suivante :

    Code : Sélectionner tout
    console none              unknown off secure
    Par :

    Code : Sélectionner tout
    console none              unknown off insecure
  • NetBSD : il faut désactiver le périphérique de la console et supprimer son caractère sécurisé afin qu'il demande le mot de passe pour la remplacer par la console virtuelle ttyE0. En clair, nous devons remplacer dans le fichier /etc/ttys, la partie :

    Code : Sélectionner tout
    1
    2
    console "/usr/libexec/getty Pc"         vt100   on secure 
    ttyE0   "/usr/libexec/getty Pc"         vt220   off secure
    Par :

    Code : Sélectionner tout
    1
    2
    console "/usr/libexec/getty Pc"         vt100   off 
    ttyE0   "/usr/libexec/getty Pc"         vt220   on secure
  • OpenBSD : il suffit de changer le niveau de sécurité de la console en éditant /etc/ttys en remplaçant :

    Code : Sélectionner tout
    #console "/usr/libexec/getty Pc"         vt220   off secure
    Par :

    Code : Sélectionner tout
    console "/usr/libexec/getty Pc"         vt220   off

Il convient dès lors de ne pas oublier le mot de passe associé au
compte de l'utilisateur root.

Mis à jour le 1er août 2007 julp

Cette valeur peut être modifiée manuellement à tout instant avec la commande sysctl. Toutefois rappelez-vous que vous ne pouvez qu'augmenter ce niveau :

Code linux : Sélectionner tout
sysctl -w kern.securelevel=<valeur numérique désirée>
Pour fixer ce niveau automatiquement au démarrage :

  • FreeBSD, modifiez /etc/rc.conf afin d'y faire figurer les variables suivantes :

    Code linux : Sélectionner tout
    1
    2
    3
    # Niveau de sécurité du noyau 
    kern_securelevel_enable="YES" 
    kern_securelevel="<valeur numérique désirée>"
  • NetBSD, une seule ligne dans /etc/rc.conf suffit :

    Code linux : Sélectionner tout
    securelevel="<valeur numérique désirée>"
  • OpenBSD : il est impossible d'agir sur le niveau par défaut (fixé à 1) sans modifier, supprimer ou renommer le fichier /etc/rc.securelevel qui contient cette valeur. Cela n'est pas vraiment gênant s'il s'agit d'élever le niveau par contre ne pouvant le réduire, vous serez dans l'obligation d'intervenir sur ce script système si une valeur plus faible est souhaitée.


Il peut éventuellement être spécifié via le fichier commun /etc/sysctl.conf de la manière suivante :

Code linux : Sélectionner tout
kern.securelevel=<valeur numérique désirée>

Mis à jour le 20 novembre 2007 julp

Le niveau de sécurité du noyau instaure des restrictions en fonction de sa valeur. Plus celle-ci est élevée, plus elle en implique. Cette valeur ne peut pas être diminuée sauf éventuellement par le processus init.

Cette fonctionnalité ne peut pas être utilisée dans tous les cas. Elle dépend de l'utilisation que vous faites au quotidien de votre système BSD du fait de certaines incompatibilités. Par exemple, le fonctionnement d'un environnement graphique est impossible avec un niveau de sécurité strictement supérieur à zéro (/dev/io et /dev/mem n'étant plus accessibles en écriture).

Par contre, ne faites pas l'erreur de vous croire à l'abri de toute malveillance même au niveau maximal de sécurité car n'étant appliqué et effectif que lors de la fin du processus de démarrage, vous êtes particulièrement vulnérables à ce moment.

Les différents niveaux existants ainsi que les contraintes qu'ils impliquent dépendent du système employé :

  • Niveau -1, mode insécurisé permanent :

    Instaure le niveau 0. Il s'agit, pour FreeBSD, du comportement par défaut du système et de manière plus générale à forcer init à ne pas passer en mode sécurisé lors de la phase dite multi-utilisateur du démarrage. Il n'implique aucune restriction particulière.
  • Niveau 0, mode insécurisé, généralement dédié au démarrage du système en mode mono-utilisateur :

    • les file chflags system immutable (schg) et system append only (sappend) peuvent être retirés
    • toutes les opérations de lecture/écriture sur tous les périphériques peuvent êtres effectuées avec comme seule restriction les droits instaurés (fstab, ...)
    • le niveau est élevé automatiquement à 1 lors du passage en mode multi-utilisateur

    Ce mode est appliqué par défaut sur NetBSD et OpenBSD. Pour
    modifier ce comportement pour celui de FreeBSD (niveau -1)
    vous devez recompiler le noyau en y ajoutant l'option
    INSECURE.
  • Niveau 1, mode sécurisé :

    • FreeBSD :

      • Les file chflags system immutable (schg) et system append only (sappend) ne peuvent plus être retirés
      • L'accès à /dev/io, /dev/mem et /dev/kmem est interdit en écriture
      • Il n'est plus possible de charger ou décharger un module noyau (commandes kldload et kldunload)
      • Les disques montés sont en lecture seule (les commandes newfs, growfs, etc échoueront)
    • NetBSD :

      • Les file chflags system immutable (schg) et system append only (sappend) ne peuvent plus être retirés
      • L'accès à /dev/mem et /dev/kmem est interdit en écriture
    • OpenBSD :

      • Les file chflags system immutable (schg) et system append only (sappend) ne peuvent plus être retirés
      • Il n'est plus possible de charger ou décharger un module noyau (commandes modload et modunload)
      • Les disques montés sont en lecture seule
      • L'accès à /dev/mem et /dev/kmem est interdit en écriture
      • Certaines variables de la MIB ne peuvent plus du tout être modifiées : fs.posix.setuid, net.inet.ip.sourceroute, machdep.kbdreset
      • D'autres en revanche ne peuvent pas être augmentées : ddb.console, ddb.panic, machdep.allowaperture


  • Niveau 2, mode hautement sécurisé :

    • FreeBSD :

      Restrictions identiques au niveau précédent à la différence près que toutes les opérations de type écriture concernant les disques eux-mêmes sont interdites, et ce, qu'ils soient montés ou non.
    • NetBSD :

      • Les disques sont toujours (montés ou non) en lecture seule
      • Les règles du pare-feu ne peuvent plus être modifiées
    • OpenBSD, s'ajoute aux effets du niveau 1 :

      • Les disques sont toujours (montés ou non) en lecture seule
      • La date système ne peut être modifiée pour revenir à un moment antérieur
      • Les règles du pare-feu ne peuvent plus être modifiées


  • Niveau 3, disponible uniquement sur FreeBSD, mode réseau sécurisé, s'ajoute aux règles du niveau 2 les restrictions suivantes :

    • toutes les opérations sur les disques sont interdites (tout ce qui figure dans la fstab est monté avant le changement du niveau de sécurité)
    • impossibilité de modifier les règles du pare-feu (elles seront chargées via les variables figurant dans /etc/rc.conf avant le changement du niveau de sécurité)


Mis à jour le 20 novembre 2007 julp

Proposer une nouvelle réponse sur la FAQ

Ce n'est pas l'endroit pour poser des questions, allez plutôt sur le forum de la rubrique pour ça


Réponse à la question

Liens sous la question
précédent sommaire suivant
 

Les sources présentées sur cette page sont libres de droits et vous pouvez les utiliser à votre convenance. Par contre, la page de présentation constitue une œuvre intellectuelle protégée par les droits d'auteur. Copyright © 2022 Developpez Developpez LLC. Tous droits réservés Developpez LLC. Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents et images sans l'autorisation expresse de Developpez LLC. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.