Julien Thomas - Site de thèse : 2007 à 2011 - TELECOM Bretagne
french english

Analyse du projet de déploiement de règles ECA rules sous Oracle

Structure générale

Comme indiqué dans le mémoire, le déploiement des règles repose sur le formalisme XML et les technologies et langages associés (XSD, XSLT, ...). Le projet est composé d'un ensemble de fichier shells (sh), XML Schema Definition (XSD) et XML Schema Language (XSL). Le tableau ci-dessous illustre l'arborescence du projet. 

+ check_interactive.sh
+ xmls /
+ templates 
-----+ basic.xsl 
-----+ ecarules.xsl 
-----+ oracle.xsl  
-----+ triggerPatterns.xsl 
-----+ varDisplay.xsl 
-----+ varTransitivity.xsl 
+ ECA_simple 
-----+ ECA_activeXQuery.xsd 
-----+ ECA_activeXQueryDisplay.xsl  
-----+ ECA_activeXQueryTriggersOracle.xsl 
+ ECA_confid 
-----+ ECA_activeXQuery2Confid.xsl 
-----+ ECA_activeXQueryConfid.xsd 
-----+ ECA_activeXQueryConfidDisplay.xsl 
-----+ ECA_activeXQueryConfidTriggersVPD.xsl 
+ ECA_integrity 
-----+ ECA_activeXQueryConfid2Integrity.xsl 
-----+ ECA_activeXQueryIntegrity.xsd 
-----+ ECA_activeXQueryIntegrityDisplay.xsl 
-----+ ECA_activeXQueryIntegrityTriggersVPD.xsl

Pour rappel, les déploiements sous Oracle reposent également sur le mécanisme de Virtual Private Databases (VPD) défini dans Oracle 8i.

Génération des règles au format ECA rules ou Oracle

Le but du projet étant de générer des règles à partir d'une spécification XML, un ensemble de commandes permet de contrôler les informations produites. Cette génération repose sur le fichier shell check_interactive.sh et les paramètres suivants :

Pour générer l'ensemble des fichiers associés à tests.xml, il faut donc générer la commande ./check_interactive.sh test 22. Cette génération repose également sur des outils opensources. Les fichiers sont ainsi analysés avec xmllint et transformés avec xsltproc. Par exemple, les étapes 00, 01 et 02 sont contrôlées comme suit : 

echo "- Check initial XML file validity wrt to xsd file" 
xmllint -noout -schema ECA_simple/ECA_activeXQuery.xsd \ 
    $1.xml
if(test $2 -eq "0" ) then echo "end at step 0" & exit 0; fi 

echo "- Process Initial Display " 
xsltproc --output $1-display.html \ 
    ECA_simple/ECA_activeXQueryDisplay.xsl \ 
    $1.xml 
if(test $2 -eq "01" ) then echo "end at step 01" & exit 0; fi 

echo "- Process Initial triggers for Oracle" 
xsltproc --output $1.html \ 
        ECA_simple/ECA_activeXQueryTriggersOracle.xsl \ 
        $1.xml
if(test $2 -eq "02" ) then echo "end at step 02" & exit 0; fi

Les fichiers de définitions (formalisme XML)

Afin de valider les règles rédigées au format XML et les transformations associées, plusieurs fichiers ont été définis. Premièrement, le fichier ECA_activeXQueryConfid.xsd contient l'ensemble des définitions nécessaires pour formuler en XML les règles ECA rules. On pourra noter les types particuliers arithmeticCondition et simpleCondition : l'attribut freevariable permet de différencier les conditions des règles d'instanciations, ce qui est nécessaire en raison du changement de formalisme entre les spécifications logiques (du type prolog), XML et par la suite les règles Oracle.

<xs:element name="arithmeticCondition">
<xs:complexType>
    <xs:sequence>
        <xs:element name="predicate" type="xs:string"/> 
        <xs:element name="input" type="xs:string" minOccurs="1" maxOccurs="unbounded"/> 
        <xs:element name="output" type="xs:string" /> 
    </xs:sequence>
    <xs:attribute name="negate" type="xs:boolean"  default="false"/> 
    <xs:attribute name="freevariable" type="xs:boolean"  default="false" /> 
</xs:complexType>
</xs:element>

<xs:element name="simpleCondition">
<xs:complexType>
    <xs:sequence>
        <xs:element name="predicate" type="xs:string"/> 
    </xs:sequence>
    <xs:attribute name="negate" type="xs:boolean" default="false" /> 
    <xs:attribute name="freevariable" type="xs:string"  /> 
</xs:complexType>

Le deuxième fichier, ECA_activeXQueryConfid.xsd, étend le premier en considérant des conditions de confidentialité et des niveaux de confidentialité pour les actions, les évènements et les règles :

Enfin, le fichier ECA_activeXQueryIntegrity.xsd étend ECA_activeXQueryConfid.xsd et considère des conditions de intégrité et des niveaux d'intégrité pour les actions, les évènements et les règles :

Les fichiers templates

Les « templates » ont été définies afin de regrouper les méthodes essentielles et génériques. Pour la génération des ECA rules, on dispose ainsi des méthodes suivantes du fichier ecarules.xsl :

Le fichier basic.xsl contient quand à lui des règles template pour gérer des opérations sur les chaines de caractères et aussi les nom des tables de la base de données.

Le fichier oracle.xsl fourni des méthodes pour gérer la génération des triggers, d'une manière similaire à ecarules.xsl :

Enfin, le fichier varTransitivity.xsl permet de contrôler les changements de nom de variables lors des appels action --> événement, événement --> règle, règle --> action.

Les règles de transformation

Les transformations s'effectuent de manière successive et progressive.

Premièrement, le fichier ECA_activeXQuery2Confid.xsl récupère les règles au format XML sans notion de sécurité et intègre les informations de confidentialité. Ce sont les règles ActionsUpdate, EventsUpdate et RulesUpdate. La règle ActionsDuplicate permet le passage entre actions sans notion de sécurité et action avec notion de confidentialité. Associée à ActionsDuplicate, la règle EPrules considère toutes les actions possibles et génère les évènements et les règles sans notion de sécurité, afin d'appeler par la suite les actions avec notion de sécurité et donc un niveau hiérarchique à 0.

Deuxièmement, le fichier ECA_activeXQueryConfid2Integrity.xsl récupère les règles au format XML avec confidentialité et intègre les informations d'intégrité. Le principe est similaire à celui de ECA_activeXQuery2Confid.xsl.

Les règles de génération des ECA rules

La génération des ECA rules est assez simple étant donné que les fichiers XML se basent sur une version « formalisée » de celles-ci. Les fichiers permettant l'affichage sont ECA_activeXQuery-IntegrityDisplay.xsl, ECA_activeXQueryConfidDisplay.xsl et ECA_activeXQueryDisplay.xsl.

Principe général

L'affichage des actions, des évènements et des règles repose sur l'utilisation de la boucle for-each, appliquée successivement à action, event et rule. La template associée (telle actionDesc) est appelée pour chaque occurrence trouvée.

<xsl:for-each select="action">
    <xsl:call-template name="actionDesc"></xsl:call-template>
    <xsl:if test="position()!=last()"><br/></xsl:if>
</xsl:for-each>

Ces templates affichent par la suite l'entête de l'élément et reposent sur le fichier eacrules.xsl pour afficher les conditions :

<xsl:template name="actionDesc">
    do(<xsl:value-of select="actionHeader/user"/>,  <xsl:value-of select="actionHeader/right" />, 
            <xsl:value-of select="actionHeader/object" />) 
    causes  <xsl:value-of select="effect/right" />(<xsl:call-template name="clearObject">
            <xsl:with-param name="text" select="effect/object" /> </xsl:call-template>) 

    <xsl:if test="conditions">
        if <ul>
        <xsl:for-each select="conditions" > <xsl:for-each select="child::*">
            <xsl:if test="name()='simpleCondition'"><xsl:call-template name="displaySimpleCondition" /></xsl:if>
            <xsl:if test="name()='arithmeticCondition'"><xsl:call-template name="displayArithmeticCondition" /></xsl:if>
        </xsl:for-each> </xsl:for-each>
        </ul>
    </xsl:if>
</xsl:template>
...
<xsl:include href="../templates/ecarules.xsl" />

Cas particuliers, extensions

Bien que les différentes règles d'affichages reposent sur une structure similaire, elles sont progressivement raffinées pour exprimer l'ensemble des besoins. En effet, les entêtes sont étendues ainsi que les tests au niveaux des conditions, en fonction des nouveaux éléments à considérer. Les conditions sont testées dans le raffinement final comme suit : 

<xsl:if test="name()='simpleCondition'"><xsl:call-template name="displaySimpleCondition" /></xsl:if>
<xsl:if test="name()='confidCondition'"><xsl:call-template name="displayConfidCondition" /></xsl:if>
<xsl:if test="name()='confidPolicyCondition'"><xsl:call-template name="displayConfidPolicyCondition" /></xsl:if>
<xsl:if test="name()='confidGetCondition'"><xsl:call-template name="displayConfidGetCondition" /></xsl:if>
<xsl:if test="name()='arithmeticCondition'"><xsl:call-template name="displayArithmeticCondition" /></xsl:if>
<xsl:if test="name()='integrityCondition'"><xsl:call-templatename="displayIntegrityCondition" /></xsl:if>
<xsl:if test="name()='integrityPolicyCondition'"><xsl:call-template name="displayIntegrityPolicyCondition" /></xsl:if>
<xsl:if test="name()='integrityGetCondition'"><xsl:call-template name="displayIntegrityGetCondition" /></xsl:if>

Les règles de génération des triggers

Fichier de base

Les fichiers haut-niveaux associés à la génération de triggers sont ceux directement appelés par le script de génération : ECA_activeXQueryTriggersOracle.xsl, ECA_activeXQueryConfidTriggers-VPD.xsl et ECA_activeXQueryIntegrityTriggersVPD.xsl. Ils récupèrent en entrée des fichiers XML valides et conformes aux besoins et génèrent par la suite des triggers compatibles Oracle en respectant le procédé suivant :

Conditions de sécurité

Afin de gérer les conditions de sécurité, plusieurs types ont été définis et leurs affichages diffèrent. Dans la suite de ce paragraphe, Type fait référence soit à integrity, soit à confid et Module fait référence au module associé. L'affichage des conditions repose sur le fichier oracle.xsl :

«Design-by-assumption works as long as assumptions hold. Assumptions are shortcuts to useful efficiencies, provided they are not violated. »
David S. Isenberg

«If the kernel is not evaluated to an MLS-capable protection profile, MLS features cannot be trusted regardless of how impressive the demonstration looks.»
J. Davidson

DGA CNRS

Valid XHTML 1.0 Strict Valid XHTML 1.0 Strict

http://www.julienthomas.eu/