L'authentification htaccess








télécharger 132.71 Kb.
titreL'authentification htaccess
page3/4
date de publication05.12.2018
taille132.71 Kb.
typeDocumentos
p.21-bal.com > loi > Documentos
1   2   3   4

Les contrats de licence et la Sécurité Informatique



Introduction

Le but de ce papier est de démontrer en quoi les contrats de licence sur les logiciels informatiques influent sur la sécurité globale des systèmes. Aucun éditeur n'est particulièrement visé mais les logiciels les plus diffusés sont certainement les plus concernés par les remarques qui suivent.

Dans toute la suite le terme logiciel englobe les applications de toutes natures ainsi que les systèmes d'exploitation.

I - Limitations de garantie

Avez-vous déjà lu en entier un contrat de licence portant sur un logiciel ? Plus particulièrement les sections consacrées aux garanties ? Ces sections sont selon moi édifiantes car sans être juriste on y comprend aisément que les éditeurs limitent soigneusement leurs responsabilités. En effet, ils stipulent explicitement qu'ils ne peuvent être tenus pour responsables des dommages que pourrait causer l'utilisation de leurs produits.

De telles limitations de garanties peuvent-elles encore être considérées comme normales voire même morales à l'heure où de plus en plus d'éléments de notre vie sont contrôlés par des logiciels ? Des clauses du même genre feraient sourire ou frémir dans l'industrie automobile par exemple car si le système de freinage ne remplissait pas sa fonction une fois sur trois, il serait facile d'imaginer les conséquences pour le véhicule, son conducteur et aussi pour son constructeur.

II - Responsabilité et Qualité

L'une des conséquences majeures des limitations de responsabilité est selon moi une absence totale d'engagement sur la qualité des produits. En limitant sa responsabilité vis à vis du consommateur (utilisateur du logiciel) l'éditeur peut se contenter de standards de qualité très faibles puisque les défauts ou défaillances des produits ne peuvent pas lui être reprochés. En effet, l'objectif n'est plus alors de produire la meilleure qualité logicielle possible mais plutôt d'assurer le minimum ; ce minimum étant le plus bas niveau de qualité acceptable par le marché. Ainsi, le consommateur choisira non plus le meilleur produit mais le moins mauvais.

Dans le monde du logiciel on est très loin des plans d'assurance qualité et des processus de certification tellement répandus dans l'industrie. L'absence d'une démarche de qualité globale et la réduction des cycles de commercialisation (time to market) conduisent à une réduction sensible des campagnes de tests fonctionnels et à une absence quasi totale de tests de sécurité (*).

Dès lors, on ne peut s'attendre qu'à des produits peu fiables et dont la sécurité n'a pas été évaluée.

III - Qualité Fiabilité et Disponibilité

La richesse fonctionnelle et la complexité grandissante des logiciels rendent leur fiabilisation de plus en plus difficile. La fiabilité fait partie des propriétés que toute démarche qualité vise à améliorer. C'est pourquoi un engagement fort des éditeurs me semble nécessaire afin de mettre en oeuvre la rigueur et les processus qui permettront d'améliorer la fiabilité des systèmes.

La disponibilité des systèmes repose pour beaucoup sur la fiabilité des logiciels qui y sont installés ; on peut comprendre aisément en quoi la dégradation de la qualité de ces derniers peut poser des problèmes de disponibilité. Améliorer la fiabilité des logiciels revient à oeuvrer pour rendre les systèmes informatiques globalement plus disponibles.

Le problème se pose d'une façon encore plus cruciale en ce qui concerne les systèmes d'exploitation. En effet, il n'est pas possible d'espérer construire un ensemble fiable si le système d'exploitation sur lequel il repose n'offre aucune garantie de fiabilité.

IV - Interopérabilité

Actuellement, à ma connaissance aucun éditeur n'accepte dans ses contrats de licence de responsabilités quant à l'interopérabilité de ses produits avec ceux d'autres éditeurs. Pourtant, rares sont les logiciels pouvant remplir l'ensemble de leurs tâches de façon complètement indépendante sans s'appuyer sur les fonctionnalités d'autres briques logicielles. D'une façon générale, les systèmes informatiques sont des ensembles complexes formés de nombreux éléments (logiciels pour la plupart) interagissant de manière continue. Les éditeurs des différents éléments logiciels ne garantissent donc en aucune manière que leurs produits ont la capacité de s'intégrer sans problèmes au sein des systèmes existants ou de remplir une quelconque fonction dans un environnement réel.

Il est vrai que la diversité des environnements et la complexité grandissante des systèmes déjà en place rendent des tests d'intégration et d'interopérabilité exhaustifs difficilement envisageable mais l'absence d'obligations fourni aux éditeurs un parapluie au dessous duquel il est très aisé de s'abriter.

V - Confiance

Dès lors que l'on permet à un logiciel de s'exécuter sur une machine il faut savoir qu'on lui accorde le contrôle total de celle ci. Cela veut dire que l'on fait confiance au logiciel pour qu'il exécute la tâche pour laquelle il a été acheté et pas autre chose. On lui fait aussi confiance pour exécuter sa tâche sans mettre en danger le fonctionnement des autres programmes présents sur la machine. Les contrats de licence tels qu'ils sont formulés actuellement font de cette confiance un risque réel. L'utilisateur prend le risque de compromettre sa machine en en confiant le contrôle à un programme dont les auteurs ne garantissent pas le bon comportement. Malheureusement la seule référence de l'utilisateur est un discours commercial car il n'a ni la possibilité (sauf pour les logiciels open source) ni la capacité de vérifier par lui même si sa confiance est bien placée.

Une autre disposition intéressante des contrats de licence concerne le reverse engineering (ingénierie à rebours ;-)). Cette pratique qui pourrait sauver bien des situations est très souvent complètement proscrite par les éditeurs.

VI - Conclusion

Les termes des contrats de licence permettent aux éditeurs de produire des logiciels sans réel engagement de qualité, engagement pourtant nécessaire à la fourniture de produits fiables. La concurrence et le marché sont les seuls éléments qui poussent encore les éditeurs à améliorer leurs produits. Pourtant au delà de l'assurance qualité qui déjà fait défaut, un engagement sur la sécurité et une responsabilisation des éditeurs seraient les éléments clés qui pourraient rendre les logiciels plus surs.
(*) J'aborderai dans un autre article la difficulté et les spécificités des tests de sécurité

Le "Compartemented Mode Workstation"


Pour respecter les recommandations de la classe de fonctionnalité F-B1, il faut appliquer certains mécanismes comme ceux du CMW.


C.M.W. (Compartemented Mode Workstation)

Ce sigle fait référence à un mode de fonctionnement dans lequel toutes les informations sont labellisées par un niveau de sécurité (system_low, public, restreint, confidentiel, secret, top secret,mais en pratique, cela est paramétrable par l'utilisateur) et un ou plusieurs compartiments d'appartenance (projet A, dossiers X,..., on peut appartenir à plusieurs compartiments). Les spécifications CMW ont été faites en partie par la N.S.A. (National Security Agency) et Sun Microsystems. Ces documents sont difficiles à obtenir (pas de retour de requêtes effectuées chez SUN et la NSA). Toutefois, nous disposons de la documentation de Trusted Solaris qui est B1/CMW.

Dans un système CMW, toutes les informations sont labellisées. Tout objet portant des informations se retrouve donc "teinté" par ses informations et prend, à priori, le niveau de sécurité de celles-ci. Un objet peut créer des informations à son niveau et au-dessus, mais pas en dessous (problème de déclassification). Cette description de fonctionnement s'appelle un "modèle formel de politique de sécurité". Il en existe plusieurs, comme par exemple le modèle "Bell - La Padula"
En pratique, cela signifie que :


· Le système tourne à un certain niveau de sécurité. Ce niveau lui donne :
· Tout pouvoir pour manipuler les informations des utilisateurs, en pratique pour gérer le swap, permettre le scheduling, etc. Cela ne donne cependant pas accès aux informations des utilisateurs, simplement à leur manipulation.

· Une protection contre les modifications intempestives d'utilisateurs ou logiciel, que cela soit le fait de bugs ou de malversation. Exemple: tous les exécutables du système, ainsi que les fichiers de configuration, sont des fichiers SYSTEM_LOW, pour que personne ne puisse écrire dedans (les utilisateurs sont au minimum au niveau PUBLIC : Il ne peut pas "déclassifier" d'information au niveau SYSTEM_LOW). Par contre, les fichiers de logs sont au niveau SYSTEM_HIGH : tout le monde peut écrire dedans, et personne ne peut les lire (information confidentielle).


· Un utilisateur se connecte avec un certain nombre de privilèges. Il choisit à sa connexion :
· Le projet sur lequel il souhaite travailler,

· Son niveau de sécurité auquel il souhaite travailler, s'il dispose de plusieurs niveaux. Les niveaux sont peut-être fonction du projet choisi. Il peut peut-être choisir une fourchette de niveau,

· Aucun utilisateur n'a les pleins pouvoir sur un autre, à fortiori sur tous les autres. En conséquence : l'administrateur système doit gérer sa machine mais pas voir le contenu des fichiers utilisateurs (ou de la RAM qu'ils utilisent). L'officier de sécurité sert à gérer les droits. En pratique, l'administration de la sécurité s'effectue avec ses deux personnes qui disposent de droits spécifiques.


· Les utilisateurs peuvent posséder des droits particuliers nécessaires au fonctionnement correct du système. Ces droits leur permettent d'outrepasser certaines contraintes de la politique de sécurité. Ainsi, un officier de sécurité particulier peut se voir octroyer le droit de déclassifier des informations, c'est à dire passer une information de l'état CONFIDENTIEL à l'état PUBLIC par exemple. Ce genre d'action est bien évidemment audité. Un exécutable particulier peut avoir le droit d'outrepasser la politique de contrôle d'accès mandataire (les niveaux de sécurité) afin de pouvoir effectuer des sauvegardes des informations. Ces sauvegardes doivent contenir les informations de sécurité des fichiers, évidemment. Programmes tar, cpio, etc... à refaire. Certains droits ne doivent pas pouvoir être cumulés sur une seule personne. Exemple, la création et l'autorisation d'un compte utilisateur ne doivent pas pouvoir être donnés à un seul et même compte. L'administrateur créé le compte, met en place les quotas, l'environnement, et l'officier de sécurité lui donne ses droits.


· Il doit exister un chemin de confiance ("Trusted Path") entre l'utilisateur et la machine / le système d'exploitation. C'est une obligation du niveau B1. Ce TP permet à l'utilisateur de donner des informations relatives à la machine, en étant sur qu'il discute bien avec le système et pas avec un programme qui tenterait de se faire passer pour lui. L'accès au TP s'effectue généralement par une combinaison de touche (Ctrl-Alt-Del sous Windows NT par exemple) ou sur certaines zones de l'écran infalsifiables par les utilisateurs (zone de dessin/d'affichage inaccessible aux logiciels par exemple).


· En ce qui concerne les informations labellisées, il faut tenir compte de tout. Voici une liste, probablement non exhaustive :
· Chaque fichier sur le disque possède ses informations de sécurité (propriétaire, niveau, compartiments),

· Chaque espace mémoire possède ses informations (idem fichier, plus processus propriétaire),

· Tout échange d'information est forcément contrôlé par le noyau : sur disque via le système de fichier, en mémoire (partagée) également, et par des sémaphores et signaux : labels à mettre en place. Un processus ne peut signaler un autre qu'à la condition qu'ils respectent des règles de sécurité définies.


· Tout accès réseau implique deux choses :
· Soit la connexion provient d'une machine de confiance (dialogue sécurisé entre les deux) auquel cas on conserve les informations de sécurité ;

· Soit la machine est inconnue auquel cas on lui applique systématiquement un label de sécurité faible (NETWORK, juste au-dessus de SYSTEM_LOW par exemple). Se pose alors le problème du choix du compartiment auquel appartient le paquet. Il peut être décidé qu'un paquet "vierge" prend la teinte du premier processus qui le touche (a priori celui qui a reçu le paquet).


· Tout processus possède ses informations (idem fichier, plus niveau et compartiment courant suivant les fichiers accédés, plus droits d'origine et droits courant). Un logiciel peut se voir attribué par le système des droits particuliers lorsqu'il s'exécute (exemple : programme de sauvegarde qui outrepasse l'accès mandataire). Un tel programme doit provoquer ses droits.

Un point intéressant des systèmes CMW est justement le fonctionnement en compartiments. Un logiciel pour lequel on n'a aucune confiance peut être exécuté sans crainte dans un compartiment qui est propre. Si jamais le logiciel possède une faille, tout ce à quoi il aura accès (ou donnera accès) sera son propre compartiment qui, idéalement, ne contiendra que lui : pas de shell, pas de visibilité sur le système, etc., cela signifie également qu'un programme non prévu pour un système CMW doit, à priori, pouvoir tourner tel quel sur un tel système. Si le logiciel effectue des opérations particulières (écouter sur un port privilégié par exemple), alors il doit pouvoir être possible de lui donner les droits nécessaires à le faire.

Exemples de systèmes CMW :

Trusted Solaris
Sco Unix.


Le modèle "Bell La Padula"


Le modèle Bell La Padula définit l'état d'un système grâce à un "tuple" composé de 4 éléments : (b, M, F, H) (current access set, access permission matrix, level function and hierarchie).


- Current Access Set (b) :

C'est le mode d'accès de l'objet : execute, read, append, write.


- Hierarchy (H) :

Hiérarchie de l'objet dans un arbre de groupes, c'est à dire que l'on peut considérer l'ensemble des groupes comme une arborescence, chaque compartiment domine un ou plusieurs autres compartiments et est dominé par un compartiment. Cette organisation n'est pas obligatoire, chaque compartiment peut être totalement indépendant des autres, mais la propriété de dominant-dominé ne rend toutes ses qualités qu'utilisée dans ce contexte d'arborescence.


- Access Permission (M) :

Matrice associant les objets aux sujets en indiquant les droits qui s'y appliquent (b).


- Level Function (f) :

Niveau de sécurité de l'objet (Top Secret, Secret, Confidential, Unclassified).


On peut donc trouver un état comme celui-ci :

- Access set : Jean a le droit de lire le fichier du personnel.

- Access Permission : la matrice a comme entrée, l'objet fichier du personnel et comme sujet Jean avec le droit en lecture.

- Level Function :Au maximum, jean a (SECRET, {STAFF, FINANCE}), le fichier du personnel a comme classification (CONFIDENTIAL, {STAFF}). Donc, le niveau courant de Jean sera (CONFIDENTIAL, {STAFF}).

- Hierarchy : l'objet est isolé.


Pour ce qui est de la communication entre deux machines, on a donc des propriétés à respecter :

- Il faut que le compartiment de l'information reçue soit un sous-groupe ou le même que celui de l'utilisateur.

- Il faut que le niveau de sécurité de l'information reçue soit inférieur ou égal à celui de l'utilisateur.


En fait, ces deux propriétés définissent bien que pour qu'un utilisateur ait accès à une information, il faut qu'il domine cette information. Ce qui signifie que la couche réseau va effectuer en réception le travail du système pour ce qui est de l'accès aux informations



Les Classes de Fonctionnalité


Dans le but de normaliser les niveaux de sécurité auxquels peuvent prétendre les systèmes d'exploitations, la
1   2   3   4

similaire:

L\Arttrust, la solution de certification et d'authentification des œuvres d'Art








Tous droits réservés. Copyright © 2016
contacts
p.21-bal.com