FR3110726A1 - Procédé de sécurisation d’un appel système, procédé de mise en place d’une politique de sécurité associée et dispositifs mettant en œuvre ces procédés. - Google Patents

Procédé de sécurisation d’un appel système, procédé de mise en place d’une politique de sécurité associée et dispositifs mettant en œuvre ces procédés. Download PDF

Info

Publication number
FR3110726A1
FR3110726A1 FR2005153A FR2005153A FR3110726A1 FR 3110726 A1 FR3110726 A1 FR 3110726A1 FR 2005153 A FR2005153 A FR 2005153A FR 2005153 A FR2005153 A FR 2005153A FR 3110726 A1 FR3110726 A1 FR 3110726A1
Authority
FR
France
Prior art keywords
security
security policy
kernel
namespace
system call
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
FR2005153A
Other languages
English (en)
Inventor
Maxime BELAIR
Sylvie Laniepce
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
Orange SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Orange SA filed Critical Orange SA
Priority to FR2005153A priority Critical patent/FR3110726A1/fr
Priority to CN202180043947.9A priority patent/CN115917539A/zh
Priority to PCT/FR2021/050860 priority patent/WO2021234267A1/fr
Priority to EP21732967.1A priority patent/EP4154141A1/fr
Priority to US17/999,532 priority patent/US20230195884A1/en
Publication of FR3110726A1 publication Critical patent/FR3110726A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/52—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow
    • G06F21/53—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow by executing in a restricted environment, e.g. sandbox or secure virtual machine
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/55—Detecting local intrusion or implementing counter-measures
    • G06F21/554—Detecting local intrusion or implementing counter-measures involving event detection and direct action
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2113—Multi-level security, e.g. mandatory access control
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2141—Access rights, e.g. capability lists, access control lists, access tables, access matrices

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • General Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Databases & Information Systems (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Storage Device Security (AREA)

Abstract

Procédé de sécurisation d’un appel système, procédé de mise en place d’une politique de sécurité associée et dispositifs mettant en œuvre ces procédés. Le procédé de sécurisation sécurise au moins un appel système déclenché par un processus courant d’un espace utilisateur d’un système logiciel. Ce procédé est mis en œuvre par un noyau du système logiciel avant d’exécuter au moins une opération déclenchée par ledit au moins un appel système et comporte :- une étape (E30) d’obtention d’au moins un espace de nommage du noyau dédié à la gestion de sécurité associé au processus courant ;- une étape (E40) pour déterminer si ledit au moins un espace de nommage comporte une politique de sécurité associée à ladite opération et enregistrée dans une zone dudit noyau  ;- une étape (E50) d’exécution de ladite politique de sécurité ; et- une étape de traitement dudit appel système en fonction d’un résultat (RET) de ladite exécution. Fig. 4

Description

Procédé de sécurisation d’un appel système, procédé de mise en place d’une politique de sécurité associée et dispositifs mettant en œuvre ces procédés.
L’invention se rapporte au domaine général de la sécurisation des programmes informatiques et plus particulièrement à celui de la sécurisation des appels système d’un noyau par les processus d’une pile logicielle s’exécutant dans un espace utilisateur.
Dans ce document, la protection d’un appel système consiste plus particulièrement à protéger les accès (lecture/création/modification/suppression...) aux ressources sensibles du noyau (inodes, fichiers, ...) qui peuvent être déclenchés dans le code de l’appel système depuis l’espace utilisateur par exemple pour gérer les opérations sensibles d'ouverture d'un fichier, d'envoi d'un paquet, de création d'un « inode », ...
Plus précisément, cette protection consiste à vérifier, juste avant l’accès à ces ressources sensibles, si l’accès peut être validé.
L’invention trouve une application privilégiée mais non limitative dans les environnements de type Linux.
Dans l’état actuel de la technique, l’infrastructure LSM (Linux Security Module) est le moyen standard d’améliorer la sécurité d’une pile logicielle dans un environnement Linux, et en particulier l’accès aux ressources sensibles du noyau. Elle permet de mettre en place sous forme de modules de sécurité Linux des politiques de sécurité additionnelles au contrôle d’accès discrétionnaire (Discretionary Access Control - DAC) que sont en particulier :
- le contrôle d’accès obligatoire (Mandatory Access Control - MAC), notamment proposé par le module AppArmor ;
- le contrôle d’accès à base de rôle (Role-Based Access Control - RBAC), notamment proposé par le module SELinux ; et
- le contrôle d’intégrité, notamment proposé par le module IMA.
De façon connue de l’homme du métier, ces politiques sont appliquées au niveau noyau dans des « hooks » (primitives permettant aux modules LSM d’exécuter des « bouts de codes » arbitraires lors d’opérations sensibles (ouverture de fichier, réception de paquet réseau, ...)).
Il existe aujourd’hui des modules LSM qui permettent de définir et d’appliquer des politiques de sécurité différentiées pour différentes piles logicielles en espace utilisateur. Cependant, ces modules sont difficiles à maintenir car ils intègrent à la fois la politique de sécurité elle-même et sa mise en œuvre.
L’invention propose un mécanisme de sécurisation qui ne présente pas cet inconvénient.
Plus précisément, et selon un premier aspect, l’invention concerne un procédé de sécurisation d’au moins un appel système déclenché par un processus courant d’un espace utilisateur d’un système logiciel. Ce procédé est mis en œuvre par un noyau du système logiciel avant d’exécuter au moins une opération déclenchée par ledit au moins un appel système et comporte :
- une étape d’obtention d’au moins un espace de nommage du noyau dédié à la gestion de sécurité associé au processus courant;
- une étape pour déterminer si ledit au moins un espace de nommage comporte une politique de sécurité associée à ladite opération et enregistrée dans une zone du noyau ;
- une étape d’exécution de la politique de sécurité ; et
- une étape de traitement de l’appel système en fonction d’un résultat de cette exécution.
Ainsi, et d’une façon générale, l’invention propose un mécanisme permettant à un processus ou à un ensemble de processus de l’espace utilisateur de définir ses propres politiques de sécurité à mettre en œuvre par le noyau.
L’invention trouve une application privilégiée dans l’environnement Linux mais peut être appliquée à tout système d’exploitation offrant un mécanisme d’isolation des ressources par espace de nommage (en anglais « Namespace »). En effet, l’invention propose de définir un nouvel espace de nommage dédié à la gestion de sécurité et de définir les politiques de sécurité dans ces espaces de nommage.
Contrairement aux modules LSM de l’état de la technique, ce mécanisme de sécurisation propose d’associer les politiques de sécurité à un espace de nommage du noyau au lieu d’intégrer la politique au module LSM lui-même. Cette caractéristique permet fort avantageusement de bénéficier de tous les mécanismes de gestion des espaces de nommage du noyau.
Selon un deuxième aspect, l’invention concerne un procédé de mise en place d’une politique de sécurité, ce procédé étant mis en œuvre par une pile logicielle d’un espace utilisateur d’un système logiciel pour sécuriser au moins un appel système susceptible d’être déclenché par un processus de la pile logicielle. Ce procédé comporte une étape de chargement de la politique de sécurité dans une zone du noyau dudit système, ladite politique de sécurité étant associée à un espace de nommage dédié à la gestion de sécurité associé à à une opération susceptible d’être déclenchée par ledit au moins un appel système de ce processus.
Ainsi, et de façon très avantageuse, la politique de sécurité peut être chargée par la pile logicielle dans le noyau, y compris quand celle-ci ne bénéficie pas de droits privilégiés d’administration. Cette caractéristique est particulièrement avantageuse car les modules LSMs de l’état actuel de la technique imposent que les politiques soient mises en place par une entité de l’espace utilisateur ayant des droits d’administration.
L’invention vise aussi un dispositif comportant un espace utilisateur et un noyau, l’espace utilisateur comportant au moins un processus apte à déclencher au moins un appel système du noyau. Ce dispositif est caractérisé en ce que :
- le noyau comporte une infrastructure de contrôle de sécurité et un module de sécurité, cette infrastructure étant configurée pour exécuter le module de sécurité avant d’exécuter au moins une opération déclenchée par l’appel système;
- ledit module de sécurité étant configuré pour :
- obtenir au moins un espace de nommage du noyau dédié à la gestion de sécurité associé au processus;
- déterminer si ledit au moins un espace de nommage comporte une politique de sécurité associée à l’opération et enregistrée dans une zone dudit noyau ; et
- exécuter ladite au moins une politique de sécurité.
Dans un mode de réalisation, le procédé (ou le dispositif) de sécurisation d’au moins un appel système détermine si l’espace de nommage du processus courant comporte au moins un ancêtre. Si c’est le cas, le procédé (ou le dispositif) met en œuvre pour chacun de ces espaces de nommage ancêtre, un traitement identique à celui mis en œuvre pour l’espace de nommage associé au processus courant.
Plus précisément, dans ce mode de réalisation, le procédé comporte :
- une étape d’obtention du ou des espaces de nommage dédié(s) à la gestion de sécurité et ancêtre(s) de l’espace nommage du processus courant ;
- une étape pour déterminer si ce ou ces espace(s) de nommage comporte(nt) une politique de sécurité associée à l’opération et enregistrée dans une zone du noyau ;
- une étape d’exécution de cette politique de sécurité ; et
- une étape de traitement de l’appel système en fonction d’un résultat de cette exécution.
Dans un mode de réalisation du procédé de mise en place d’une politique de sécurité proposé, la pile logicielle est un conteneur et le chargement de la politique de sécurité est défini par une instruction d’un fichier de configuration du conteneur. Ce fichier de configuration peut par exemple être conforme à aux spécifications définies par l’OCI (Open Container Initiative) ou un fichier de type Dockerfile. On rappelle qu’un fichier de type Dockerfile est un fichier texte qui comporte les commandes nécessaires à la génération de l’image d’un conteneur.
De façon particulièrement avantageuse, les politiques de sécurité peuvent être chargées par la pile logicielle ou par le conteneur « à chaud », c’est-à-dire pendant l’exécution du conteneur.
Ainsi, l’opération déclenchée par un appel système du processus courant entraîne l’exécution de la ou les politique(s) de sécurité associée(s) à cette opération dans l’espace de nommage de ce processus, mais aussi dans les espaces de nommage ancêtres de l’espace de nommage de ce processus, s’ils existent.
Ainsi, et en particulier, les processus d’un conteneur héritent des politiques de sécurité définies dans les espaces de nommage ancêtres.
En ce sens, il peut être dit que le procédé proposé permet d’empiler des politiques de sécurité personnalisées pour les processus d’un espace de nommage.
Dans un mode de réalisation particulier, la pile logicielle ou le conteneur de l’espace utilisateur construit un code exécutable qui contient ses propres politiques de sécurité applicables à des opérations particulières (ouverture de fichier, réception de paquet réseau, ...). Ce code peut être chargé à l’exécution (c’est-à-dire dynamiquement) à travers une interface système vers le noyau. Il est alors exécuté par le noyau quand ces opérations (ou événements) se produisent pour un processus appartenant à ce conteneur. Puisque ce code n’est pas forcément exécuté par un processus de confiance (potentiellement malveillant), il ne doit pas être en mesure d’interférer avec le reste du système ou le noyau. Ainsi, les politiques de sécurité ne sont appliquées que si elles se réfèrent bien au conteneur à l’origine de la politique applicable à l’évènement.
De façon avantageuse, puisqu’il est possible qu’une pile logicielle soit compromise, une politique de sécurité ne peut pas être désactivée ou modifiée depuis l’espace utilisateur, en particulier par une pile logicielle ou un conteneur appartenant à un espace de nommage pour lequel cette politique a été définie.
Dans un mode de réalisation particulier, le procédé de sécurisation proposé comporte une étape de suppression d’au moins une politique de sécurité par le noyau si cette politique de sécurité n’est pas comprise dans un espace de nommage dédié à la sécurité associé à au moins un processus actif de l’espace utilisateur.
Dans un mode de réalisation particulier, le procédé de sécurisation proposé comporte une étape pour déterminer si l’appel système est associé à une opération sensible et le procédé de sécurisation n’est mis en œuvre que pour les opérations sensibles (ouverture de fichier, envoi de paquet, exécution d’une fonction, …). Cette détermination peut notamment être effectuée par le gestionnaire d’appels système du noyau.
Dans un mode de réalisation du procédé de sécurisation proposé, ladite étape de traitement consiste à exécuter l’opération si le résultat de l’exécution de ladite au moins une politique de sécurité ne détecte aucun problème de sécurité et à déclencher une action de sécurité si le résultat de l’exécution de ladite au moins une dite politique de sécurité détecte au moins un problème de sécurité.
Dans un mode de réalisation du procédé de sécurisation proposé, l’action de sécurité comporte la destruction du processus courant.
Dans un mode de réalisation de l’invention, une politique de sécurité est un fichier en langage binaire obtenu par compilation d’un programme en langage eBPF (pour « Extended Berkeley Packet Filter»).
De façon connue, ce langage est volontairement limité en termes de fonctionnalités (pas de boucle, pas d’arithmétique de pointeur, pas d’accès direct aux structures noyau, ...) mais possède de fortes propriétés de sécurité de sorte qu’il est inapte à attaquer le reste du système.
Cette caractéristique permet avantageusement d’empêcher les attaques critiques, par exemple pour récupérer des informations, modifier l’intégrité ou la disponibilité du reste du système.
La technique proposée permet ainsi à une pile logicielle de mettre en place des politiques de sécurité sans compromettre la sécurité du système. Elle permet en particulier l’application de politiques durcies après l’initialisation de la pile logicielle pour bloquer ultérieurement des comportements qui ne seraient acceptables qu’à l’initialisation.
Les possibilités offertes par le langage eBPF étant limitées, dans un mode de réalisation du procédé de mise en place d’une politique de sécurité proposé, au moins une politique de sécurité appelle au moins une fonction de support externe à cette politique et chargée dans une zone dédiée du noyau par une entité de l’espace utilisateur bénéficiant de droits d’administration.
Ces fonctions de support (en anglais « helpers ») peuvent être chargées « à chaud », c’est à dire pendant l’exécution du noyau. Elles peuvent être appelées par une politique de sécurité eBPF pour réaliser des traitements critiques comme les accès aux structures noyau pour le code eBPF. Ces fonctions support ne peuvent être écrites que par une entité bénéficiant de droits d’administration et ne sont pas soumises aux limitations liées au vérifieur eBPF.
Ce mode de réalisation particulier permet, en déportant les accès critiques et les traitements complexes vers les fonctions support, la mise en place par les conteneurs de politiques élaborées sans compromettre la sécurité du système et avec des surcoûts en performance faibles.
Dans un mode de réalisation particulier, au moins une fonction de support est une fonction dynamique exécutable indépendamment de sa position, cette fonction dynamique étant appelée par une fonction de support statique compilée avec le noyau et appelée par la politique de sécurité. Pour plus de renseignements sur la notion de code indépendant de sa position (en anglais « position independent code »), l’homme du métier peut se reporter au document disponible à l’adressehttps://fr.qwe.wiki/wiki/Position-independent_code.
Dans un mode de réalisation particulier, le procédé de mise en place d’une politique de sécurité proposé comporte une étape d’analyse d’un fichier journal (plus connu sous le terme logs) comportant au moins un résultat d’exécution d’une politique de sécurité exécutée par un procédé de sécurisation tel que mentionné ci-dessus.
Le procédé de sécurisation et le procédé de mise en place d’une politique de sécurité proposés sont mis en œuvre par des programmes d’ordinateur.
Par conséquent, l’invention vise également un programme d’ordinateur sur un support d’enregistrement, ce programme étant susceptible d’être mis en œuvre dans un dispositif ou plus généralement dans un ordinateur. Ce programme comporte des instructions permettant la mise en œuvre d’un procédé tel que décrit ci-dessus.
Ce programme peut utiliser n’importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n’importe quelle autre forme souhaitable.
L’invention vise aussi un support d'information ou un support d’enregistrement lisibles par un ordinateur, et comportant des instructions d’un programme d'ordinateur tel que mentionné ci-dessus.
Le support d'information ou d’enregistrement peut être n'importe quelle entité ou dispositif capable de stocker les programmes. Par exemple, les supports peuvent comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une disquette (floppy disc) ou un disque dur, ou une mémoire flash.
D'autre part, le support d'information ou d’enregistrement peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par lien radio, par lien optique sans fil ou par d'autres moyens.
Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet.
Alternativement, le support d'informations ou d’enregistrement peut être un circuit intégré dans lequel un programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution de l’un des procédés tels que décrits précédemment.
D’autres caractéristiques et avantages de la présente invention ressortiront de la description faite ci-dessous, en référence aux dessins annexés qui en illustrent un exemple de réalisation dépourvu de tout caractère limitatif. Sur les figures :
la figure 1 représente un dispositif conforme à un mode particulier de réalisation et les principales étapes d’un procédé de mise en place d’une politique de sécurité conforme à un mode particulier de réalisation ;
la figure 2 représente une table de processus pouvant être utilisée dans un mode particulier de réalisation ;
la figure 3 représente une table de contrôle pouvant être utilisée dans un mode particulier de réalisation ;
la figure 4 représente sous forme d’ordinogramme les principales étapes d’un procédé de sécurisation conforme à un mode particulier de réalisation.
Description détaillée de plusieurs modes de réalisation particuliers
La figure 1 représente un dispositif 100 conforme à l’invention. Dans l’exemple de réalisation décrit ici, ce dispositif 100 a l’architecture matérielle d’un ordinateur. Il comporte notamment un processeur 10, une mémoire vive de type RAM 11, une mémoire morte de type ROM 12, et des moyens de communication 13.
Ce dispositif comporte un système logiciel SYS, ce système comportant un noyau ou système d’exploitation KER, et un espace utilisateur USR. Dans le mode de réalisation décrit ici, le système d’exploitation KER est de type Linux (marque déposée).
Dans le mode de réalisation décrit ici, l’espace utilisateur USR comporte un processus p0(), deux piles logicielles de type conteneur C1, C2 et un outil d’administration ADM. Le processus p0() et les piles logicielles C1, C2 sont associées à des droits de niveau utilisateur et l’outil d’administration ADM à des droits de niveau administrateur.
Dans l’exemple de réalisation décrit ici, les piles logicielles C1, C2 de l’espace utilisateur USR sont des conteneurs, chacun comportant un ensemble de processus isolés du reste du système logiciel SYS.
Dans cet exemple, les conteneurs C1 et C2 sont créés par le processus p0().
On rappelle que les processus de l’espace utilisateur USR peuvent être isolés grâce au mécanisme connu d’espaces de nommage. De façon connue, le système d’exploitation Linux propose dans l’état actuel de la technique, plusieurs espaces de nommage (par exemple : Network, IPC, PID, User)… qui peuvent être utilisés pour isoler des processus dans un mécanisme dans lequel on définit des ensembles de processus, de sorte que les processus d’un ensemble donné ne puissent pas voir les ressources utilisées par un autre ensemble de processus.
Dans l’exemple de la figure 1:
- le processus p0 est associé respectivement à des espaces de nommage ENNETWORK0 (pour l’espace Network), ENIPC0 (pour IPC), ENPID0 (pour PID), ENUser0 (pour User) … ;
- les processus du conteneur C1, en l’occurrence le processus p1(), sont associés à des espaces de nommage différents ENNETWORK1, ENIPC1, ENIPD1, ENUser1; et
- les processus du conteneur C2, en l’occurrence le processus p2(), sont associés à des espaces de nommage différents ENNETWORK2, ENIPC2, ENIPD2, ENUser2.
Certains processus du système SYS peuvent faire appel à des fonctions système du noyau KER. Le noyau KER comporte un gestionnaire d’appel système GAS dans lequel sont implémentés ces appels système.
L’invention propose un mécanisme de gestion de sécurité pour sécuriser les appels système déclenchant des opérations sensibles au sens des Modules de Sécurité Linux (LSM).
Dans le mode de réalisation décrit ici, on considère que les opérations oper_open() d’ouverture de fichier, oper_send() d’envoi de paquets et oper_exec() d’exécution de fonction sont des opérations sensibles.
Dans l’exemple de la figure 1 le processus p1 du conteneur C1 et le processus p2 du conteneur C2 appellent :
- l’appel système open() d’ouverture de fichier qui génère lors de son exécution, l’opération sensible oper_open(); et
- l’appel système send() d’envoi de paquets qui génère lors de son exécution, l’opération sensible oper_send();.
Dans l’exemple de la figure 1, le processus p0 ne fait pas appel aux appels système open() send(), exec().
Dans le mode de réalisation décrit ici, l’invention propose d’utiliser un nouvel espace de nommage ENSECURE dédié à la gestion de la sécurité.
Par exemple, le processus p0 est associé à l’espace de nommage de gestion de la sécurité ENSECURE0, le conteneur C1 est associé à l’espace de nommage de gestion de la sécurité ENSECURE1 et le conteneur C2 est associé à l’espace de nommage ENSECURE2.
La figure 2 représente en détail une table TABPID des processus p0, p1 et p2 mémorisée dans le noyau KER. Dans le noyau KER, un processus est constitué d’une structure comportant plusieurs champs permettant de gérer le cycle de vie du processus comme son identifiant de processus PID, ses drapeaux (flags en anglais), sa pile …
Dans l’espace noyau, on peut récupérer la structure de données correspondant au processus courant à l’aide de l’instruction current (voir étape E30, figure 4).
Cette structure comporte également un champ nsproxy qui comporte des pointeurs vers les espaces de nommage. Conformément à ce mode de réalisation particulier, ce champ nsproxy comporte un pointeur ENSECURE vers l’espace de nommage dédié à la gestion de la sécurité associé au processus. Cet espace de nommage définit une structure de données qui comprend notamment la politique de sécurité définie en langage eBPF. Dans le mode de réalisation décrit ici, ces structures sont enregistrées dans une zone de politiques de sécurité ZPS du noyau KER.
L’espace de nommage ENSECURE d’un processus comporte un lien vers l’espace de nommage ENSECURE du parent de l’espace de nommage de ce processus. Dans l’exemple décrit ici, ENSECURE1 et ENSECURE2 associés respectivement aux conteneurs C1 et C2 pointent vers l’espace de nommage ENSECURE0 du processus p0.
Les espaces de nommage ENSECURE forment donc un arbre.
De façon connue de l’homme du métier un processus peut changer d’espace de nommage pour rejoindre l’espace de nommage d’un de ses processus fils, par exemple en utilisant la commande unshare().
Depuis l’espace utilisateur USR, il est possible d’accéder à l’identifiant d’un espace de nommage mais il n’est pas possible de modifier sa structure. Cette caractéristique permet avantageusement d’empêcher toute modification ou désactivation d’une politique de sécurité par un conteneur.
Dans l’exemple de réalisation décrit ici, on suppose que le processus p0() a défini une politique de sécurité PSOFp0 pour sécuriser les appels à l’opération sensible d’ouverture de fichier oper_open(). On suppose qu’il n’a pas défini de politique de sécurité pour sécuriser les appels à l’opération sensible d’envoi de paquet sur le réseau oper_send().
Dans le mode de réalisation décrit ici, les processus d’un conteneur héritent des politiques de sécurité définies par tous ses espaces de nommage ENSECURE ancêtres.
Dans l’exemple de réalisation décrit ici, on suppose que le conteneur C1 a défini sa propre politique de sécurité PSOFC1 pour sécuriser les appels par ses processus, en l’occurrence p1(), à l’opération sensible d’ouverture de fichier oper_open(), en complément de la politique PSOFp0 définie par le processus p0().
On suppose que le conteneur C1 a défini une politique de sécurité PSTPC1 pour sécuriser les appels par ses processus, en l’occurrence p1(), à l’opération sensible d’envoi de paquet oper_send().
On suppose que le conteneur C2 n’a défini aucune politique de sécurité propre. Le processus p2() de ce conteneur hérite de la politique de sécurité PSOFp0 définie par le processus p0() pour sécuriser ses appels à l’opération sensible d’ouverture de fichier. Mais il ne définit aucune fonction de sécurité pour vérifier l’opération sensible d’envoi de paquet.
Dans le mode de réalisation décrit ici, chacune des politiques de sécurité PSOFp0, PSOFC1, PSTPC1 est définie par une fonction logicielle en langage eBPF compilée en binaire. Ces politiques de sécurité sont enregistrées dans la mémoire morte 12 du dispositif 100 et destinées à être chargées dans la zone ZPS de politiques de sécurité du noyau KER.
Ce chargement (étape F10) peut se faire de différentes façons.
Dans le mode de réalisation décrit ici, la mémoire morte 12 comporte un fichier de configuration de type OCI (Open Container Initiative) pour chaque conteneur, à savoir un fichier de configuration FOCIC1 pour le conteneur C1 et un fichier de configuration FOCIC2 pour le conteneur C2.
De façon connue, la configuration OCI d’un conteneur est spécifiée sous le nom config.json et détaille les caractéristiques du conteneur à créer. Ce fichier de configuration précise notamment les fichiers que doit contenir le conteneur, ses interfaces système, ses espaces de nommage, …
Dans le mode de réalisation décrit ici, le fichier de configuration OCI d’un conteneur comporte des instructions pour que le conteneur charge ses politiques de sécurité dans la zone ZPS de politiques de sécurité du noyau KER.
Quand un conteneur est créé, par exemple C1, les politiques de sécurité PSOFC1 et PCTPC1 du conteneur C1 sont copiées de la mémoire morte 12 dans une mémoire M1 du conteneur C1. Une fois que le conteneur C1 est construit, il est exécuté et à l’exécution, les politiques de sécurité sont transférées de la mémoire M1, dans la zone ZPS du noyau.
L’écriture manuelle de fichier de configuration OCI peut néanmoins s’avérer complexe, et dans un autre mode de réalisation de l’invention, le chargement de la politique de sécurité d’un conteneur dans le noyau KER est définie par une instruction d’une méthode de construction de conteneur de plus haut niveau, par exemple de la méthode Dockerfile.
Par ailleurs, le chargement d’une politique de sécurité propre à un conteneur dans la mémoire du noyau peut être effectué à tout moment du cycle de vie du conteneur, pas seulement à son initialisation. Dans le mode de réalisation décrit ici, le code du conteneur C1 comporte également des instructions load_ps() permettant de charger une politique de sécurité sous forme d’un fichier eBPF compilé sous forme binaire dans la zone ZPS de politiques de sécurité du noyau KER. Ce mode de réalisation particulier permet en particulier de charger une nouvelle politique de sécurité qui va être appliquée après le démarrage du conteneur C1. Cette fonction load_ps() consiste à ouvrir le fichier eBPF compris dans la mémoire morte 12 et à le copier vers une interface avec le noyau KER.
Dans le mode de réalisation décrit ici, le noyau KER comporte une infrastructure de contrôle de sécurité ICS de gestion des Modules de sécurité Linux, un module de sécurité Linux LSM1 conforme à l’invention et éventuellement au moins un autre module de sécurité LSM2, par exemple, un module SELinux ou un module AppAmor tels que mentionnés précédemment.
Dans l’exemple de réalisation décrit ici, le noyau KER comporte une table de contrôle TABCTR qui définit, pour chaque opération sensible OPS (ouverture de fichier, envoi de paquet sur le réseau, …) si le module de sécurité LSM1 veut contrôler ou non ces opérations sensibles. Cette table TABCTR est représentée à la figure 3.
Dans l’exemple de vérification décrit ici, on suppose que le module de sécurité LSM1 ne souhaite vérifier que l’opération sensible d’ouverture de fichiers.
La figure 4 représente sous forme d’ordinogramme les principales étapes d’un procédé de sécurisation conforme à un mode particulier de réalisation. Dans le mode de réalisation décrit ici, ce procédé est mis en œuvre par le gestionnaire d’appel système GAS, l’infrastructure de contrôle de sécurité ICS (en anglais framework LSM) et par le module de sécurité LSM1.
Dans l’exemple de réalisation décrit ici, le gestionnaire d’appel système GAS détermine, au cours d’une étape E10, si un appel système déclenché par un processus de l’espace utilisateur doit réaliser une opération sensible. Si c’est le cas, il déclenche l’infrastructure de contrôle de sécurité ICS du noyau KER.
Si l’infrastructure ICS détermine que l’opération sensible OPS répertoriée dans la table TABCTR est supervisée par le module de sécurité LSM1, l’infrastructure ICS déclenche l’exécution du module de sécurité LSM1 au cours d’une étape E20.
Dans l’exemple de réalisation décrit ici, si un processus souhaite réaliser l’opération sensible envoyer un paquet (oper_send()) ou exécuter un nouveau processus en espace utilisateur (oper_exec()) par appel à la fonction exec(), comme ces opérations sensibles ne sont pas vérifiées par le module de sécurité LSM1, le résultat de l’étape de détermination est négatif. Ces opérations peuvent néanmoins être vérifiées par le module de sécurité LSM2, hors contexte de l’invention, par exemple SELinux et un module AppAmor.
Au cours d’une étape E30, le module de sécurité LSM1 détermine l’espace de nommage associé au processus courant à l’origine de cet appel. Il utilise pour cela le processus courant de la table des processus TABPID.
Le module de sécurité LSM1 exécute ensuite une boucle pour exécuter les politiques de l’espace de nommage du processus courant liées à cette opération sensible. Dans un mode de réalisation particulier, le module de sécurité LSM1 exécute ensuite une boucle pour exécuter les politiques de ses espaces de nommage ancêtres s’ils existent.
Au cours d’une étape E40 le module de sécurité LSM1 détermine si l’espace de nommage courant a défini une ou plusieurs politiques de sécurité pour vérifier la validité de l’opération sensible.
Si tel est le cas, le module de sécurité concerné LSM1 exécute au cours d’une étape E50 la ou les politiques de sécurité définies dans l’espace de nommage dédié à la gestion de sécurité ENSECURE du processus courant pour cette opération sensible.
En l’espèce, au cours de la première itération, la politique de sécurité PSOFC1 est exécutée. Cette politique de sécurité renvoie un résultat RET de cette exécution au module de sécurité LSM1.
Dans le mode de réalisation décrit ici, une politique de sécurité, et en particulier la politique de sécurité PSOFC1, renvoie un résultat RET négatif si elle détecte un problème de sécurité (traduisant par exemple un comportement malveillant ou anormal) et un résultat positif si elle ne détecte aucun problème de sécurité.
Si cette valeur RET est positive, le module de sécurité détermine, s’il existe, l’espace de nommage parent de l’espace de nommage du processus courant (étape E60) et la boucle se répète.
En l’espèce, au cours de la deuxième itération la politique de sécurité PSOFp0 de l’espace de nommage ENSECURE0 du processus p0 est exécutée.
Si une politique de sécurité renvoie un résultat RET négatif, le module de sécurité enregistre ce résultat dans un fichier de log FLOG du noyau KER au cours d’une étape E70 et envoie ce résultat négatif RET à l’infrastructure de sécurité ICS. Ce fichier de log FLOG peut être analysé (étape F30) par l’administrateur au moyen de l’outil d’administration ADM.
Lorsque toutes les politiques de sécurité de toute l’arborescence d’espaces de nommages ont été exécutées avec un résultat RET positif, le module de sécurité LSM1 envoie un résultat positif RET à l’infrastructure de sécurité ICS (test E90).
Dans le mode de réalisation décrit ici, si l’infrastructure de sécurité RET reçoit un résultat RET positif, elle ne déclenche pas d’action particulière et l’appel système est exécuté, sauf si une action est déclenchée par un autre module de sécurité LSM2, par exemple, un module SELinux et un module AppAmor.
Dans le mode de réalisation décrit ici, si l’infrastructure de sécurité RET reçoit un résultat RET négatif, l’infrastructure de contrôle ICS déclenche une action de sécurité AS au cours d’une étape E80. Cette action peut consister à détruire le processus à l’origine de l’appel et à lever une alerte dans le fichier de log FLOG.
Dans le mode de réalisation décrit ici, lorsqu’aucun processus ne reste dans un espace de nommage dédié à la gestion de sécurité, cet espace de nommage est détruit automatiquement par le noyau. Cette opération détruit les politiques de sécurité associées à ces espaces de nommage.
Par exemple, dans l’exemple de réalisation décrit ici, dès lors que le processus p1 meurt, il n’y a plus dans le système SYS de processus dont l’espace de nommage dédié à la gestion de sécurité est ENSECURE1 si bien que les politiques de sécurité PSOFC1 et PSTPC1 peuvent être détruites.
Dans le mode de réalisation décrit ici, si une politique de sécurité n’est pas comprise dans un espace de nommage dédié à la sécurité associé à au moins un processus actif de l’espace utilisateur, cette politique de sécurité est supprimée par le noyau.
Conformément à l’invention, les politiques de sécurité en langage eBPF compilé peuvent appeler des fonctions du noyau KER externes à ces politiques, pour mettre en œuvre des opérations critiques qui ne peuvent pas l’être directement par la politique de sécurité en langage eBPF elle-même. De telles fonctions sont connues de l’homme du métier sous le nom de fonctions de support eBPF (en anglais « Helper eBPF »).
Dans un mode particulier de mise en œuvre de l’invention, une telle fonction de support FSUP peut être écrite par un administrateur, par exemple en langage C, puis compilée comme un module noyau classique avec GCC (en anglais « GNU Compiler Collection »).
Dans le mode de réalisation décrit ici, ce code exécutable est transformé pour pouvoir être exécuté indépendamment de sa position selon le mécanisme PIC (Position Independent Code) connu de l’homme du métier.
Ces fonctions de support FSUP dynamiques peuvent être chargées (étape F20) dans une zone dédiée du noyau KER sans interrompre l’exécution du noyau.
Une fois chargées dans le noyau, ces fonctions de support dynamiques FSUP peuvent être appelées par le code eBPF d’une politique de sécurité à l’aide d’une unique fonction de support statique FSUPSTAT.

Claims (13)

  1. Procédé de sécurisation d’au moins un appel système déclenché par un processus courant (p1) d’un espace utilisateur (USR) d’un système logiciel (SYS), ledit procédé étant mis en œuvre par un noyau (KER) dudit système logiciel (SYS) avant d’exécuter au moins une opération déclenchée par ledit au moins un appel système, et comportant :
    - une étape (E30) d’obtention d’au moins un espace de nommage (ENSECURE1) du noyau (KER) dédié à la gestion de sécurité associé audit processus courant (p1) ;
    - une étape (E40) pour déterminer si ledit au moins un espace de nommage (ENSECURE1) comporte une politique de sécurité associée à ladite opération et enregistrée dans une zone (ZPS) dudit noyau (KER) ;
    - une étape (E50) d’exécution de ladite politique de sécurité ; et
    - une étape de traitement dudit appel système en fonction d’un résultat (RET) de ladite exécution.
  2. Procédé de sécurisation d’au moins un appel système selon la revendication 1, comportant en outre, lorsque ledit au moins un espace de nommage (ENSECURE1) dudit processus courant (p1) comporte au moins un ancêtre (ENSECURE0) :
    - une étape (E30) d’obtention dudit au moins un espace de nommage (ENSECURE0) dédié à la gestion de sécurité et ancêtre de l’espace nommage (ENSECURE1) dudit processus courant (p1) ;
    - une étape (E40) pour déterminer si cet espace de nommage (ENSECURE0) comporte une politique de sécurité associée à ladite opération et enregistrée dans une zone (ZPS) dudit noyau (KER) ;
    - une étape (E50) d’exécution de ladite politique de sécurité ; et
    - une étape de traitement dudit appel système en fonction d’un résultat (RET) de ladite exécution.
  3. Procédé de sécurisation d’au moins un appel système selon la revendication 1 ou 2, comportant une étape (E10) pour déterminer si ladite opération est une opération sensible.
  4. Procédé de sécurisation d’au moins un appel système selon l’une quelconque des revendications 1 à 3, dans lequel ladite étape de traitement consiste à exécuter ladite opération si le résultat de l’exécution de ladite au moins une politique de sécurité ne détecte aucun problème de sécurité et à déclencher (E80) une action de sécurité si le résultat de l’exécution d’au moins une dite politique de sécurité détecte un problème de sécurité.
  5. Procédé de sécurisation d’au moins un appel système selon la revendication 4, dans lequel ladite action de sécurité comporte la destruction dudit processus courant (p1).
  6. Procédé de sécurisation d’au moins un appel système selon l’une quelconque des revendications 1 à 5, comportant une étape de suppression d’au moins une dite politique de sécurité par ledit noyau (KER) si ladite politique de sécurité n’est pas comprise dans un espace de nommage dédié à la sécurité associé à au moins un processus actif dudit espace utilisateur (USR).
  7. Procédé de mise en place d’une politique de sécurité, ledit procédé étant mis en œuvre par une pile logicielle (C1) d’un espace utilisateur (USR) d’un système logiciel (SYS) pour sécuriser au moins un appel système susceptible d’être déclenché par un processus (p1) de ladite pile logicielle (C1), ledit procédé comportant une étape (F10) de chargement de ladite politique de sécurité dans une zone (ZPS) d’un noyau (KER) dudit système (SYS), ladite politique de sécurité étant associée à un espace de nommage (ENSECURE1) du noyau dédié à la gestion de sécurité associé à une opération susceptible d’être déclenchée par ledit au moins un appel système dudit processus (p1).
  8. Procédé de mise en place d’une politique de sécurité selon la revendication 7, dans lequel ladite pile logicielle (C1) est un conteneur, ledit chargement étant défini par une instruction d’un fichier de configuration dudit conteneur (C1), ledit fichier de configuration (FOCIC1) étant conforme aux spécifications définies par l’OCI (Open Container Initiative) ou un fichier de type Dockerfile.
  9. Procédé de mise en place d’une politique de sécurité selon la revendication 7 ou 8 dans lequel ladite au moins une politique de sécurité appelle au moins une fonction de support (FSUP) externe à ladite politique et chargée (F20) dans une zone dédiée du noyau (KER) par une entité dudit espace utilisateur (USR) bénéficiant de droits d’administration.
  10. Procédé de mise en place d’une politique de sécurité selon la revendication 9 dans lequel ladite au moins une fonction de support (FSUP) est une fonction dynamique exécutable indépendamment de sa position, cette fonction dynamique (FSUP) étant appelée par une fonction de support statique (FSUPSTAT) compilée avec ledit noyau (KER) et appelée par ladite politique de sécurité.
  11. Procédé de mise en place d’une politique de sécurité selon l’une quelconque des revendications 7 à 10, comportant une étape (F30) d’analyse d’un fichier journal (FLOG) comportant au moins un résultat (RET) d’exécution d’une politique de sécurité exécutée par un procédé de sécurisation selon l’une quelconque des revendications 1 à 5.
  12. Procédé selon l’une quelconque des revendications 1 à 11 dans lequel ladite au moins une politique de sécurité est un fichier en langage binaire obtenu par compilation d’un programme en langage eBPF.
  13. Dispositif (100) comportant un espace utilisateur (USR) et un noyau (KER), l’espace utilisateur (USR) comportant au moins un processus (p1) apte un déclencher au moins un appel système dudit noyau (KER), ledit dispositif (100) étant caractérisé en ce que :
    - ledit noyau (KER) comporte une infrastructure de contrôle de sécurité (ICS) et un module de sécurité (LSM1), ladite infrastructure (ISC) étant configurée pour exécuter ledit module de sécurité (LSM1) avant d’exécuter au moins une opération déclenchée par ledit au moins un appel système;
    - ledit module de sécurité (LSM1) étant configuré pour :
    - obtenir au moins un espace de nommage (ENSECURE1) du noyau (KER) dédié à la gestion de sécurité associé audit processus (p1) ;
    - déterminer si ledit au moins un espace de nommage (ENSECURE1) comporte une politique de sécurité associée à ladite opération et enregistrée dans une zone (ZPS) dudit noyau (KER) ; et
    - exécuter ladite au moins une politique de sécurité.
FR2005153A 2020-05-20 2020-05-20 Procédé de sécurisation d’un appel système, procédé de mise en place d’une politique de sécurité associée et dispositifs mettant en œuvre ces procédés. Withdrawn FR3110726A1 (fr)

Priority Applications (5)

Application Number Priority Date Filing Date Title
FR2005153A FR3110726A1 (fr) 2020-05-20 2020-05-20 Procédé de sécurisation d’un appel système, procédé de mise en place d’une politique de sécurité associée et dispositifs mettant en œuvre ces procédés.
CN202180043947.9A CN115917539A (zh) 2020-05-20 2021-05-18 确保系统调用的安全的方法、实施关联安全策略的方法、和执行这些方法的设备
PCT/FR2021/050860 WO2021234267A1 (fr) 2020-05-20 2021-05-18 Procede de securisation d'un appel systeme, procede de mise en place d'une politique de securite associee et dispositifs mettant en oeuvre ces procedes
EP21732967.1A EP4154141A1 (fr) 2020-05-20 2021-05-18 Procede de securisation d'un appel systeme, procede de mise en place d'une politique de securite associee et dispositifs mettant en oeuvre ces procedes
US17/999,532 US20230195884A1 (en) 2020-05-20 2021-05-18 Method for securing a system call, method for implementing an associated security policy and devices for carrying out such methods

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR2005153A FR3110726A1 (fr) 2020-05-20 2020-05-20 Procédé de sécurisation d’un appel système, procédé de mise en place d’une politique de sécurité associée et dispositifs mettant en œuvre ces procédés.
FR2005153 2020-05-20

Publications (1)

Publication Number Publication Date
FR3110726A1 true FR3110726A1 (fr) 2021-11-26

Family

ID=72644323

Family Applications (1)

Application Number Title Priority Date Filing Date
FR2005153A Withdrawn FR3110726A1 (fr) 2020-05-20 2020-05-20 Procédé de sécurisation d’un appel système, procédé de mise en place d’une politique de sécurité associée et dispositifs mettant en œuvre ces procédés.

Country Status (5)

Country Link
US (1) US20230195884A1 (fr)
EP (1) EP4154141A1 (fr)
CN (1) CN115917539A (fr)
FR (1) FR3110726A1 (fr)
WO (1) WO2021234267A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2023161105A1 (fr) * 2022-02-28 2023-08-31 Orange Procédé et module de détection de tentatives d'attaques informatiques dans un parc d'ordinateurs

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116991449B (zh) * 2023-09-28 2024-03-08 阿里云计算有限公司 内核子系统热升级方法、设备及存储介质

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170353499A1 (en) * 2016-06-06 2017-12-07 NeuVector, Inc. Methods and Systems for Applying Security Policies in a Virtualization Environment Using a Security Instance
US20180129666A1 (en) * 2016-11-04 2018-05-10 Microsoft Technology Licensing, Llc Multi-layer merge in a storage virtualization system
WO2019127399A1 (fr) * 2017-12-29 2019-07-04 浙江大学 Procédé d'exécution de politique de bac à sable à grains fins pour conteneur linux

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170353499A1 (en) * 2016-06-06 2017-12-07 NeuVector, Inc. Methods and Systems for Applying Security Policies in a Virtualization Environment Using a Security Instance
US20180129666A1 (en) * 2016-11-04 2018-05-10 Microsoft Technology Licensing, Llc Multi-layer merge in a storage virtualization system
WO2019127399A1 (fr) * 2017-12-29 2019-07-04 浙江大学 Procédé d'exécution de politique de bac à sable à grains fins pour conteneur linux

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
YUQIONG SUN SYMANTEC RESEARCH LABS DIMITRIOS PENDARAKIS IBM RESEARCH ZHONGSHU GU IBM RESEARCH DAVID SAFFORD GE GLOBAL RESEARCH MIM: "Security Namespace : Making Linux Security Frameworks Available to Containers", 14 August 2018 (2018-08-14), pages 1436 - 1452, XP061026245, Retrieved from the Internet <URL:https://www.usenix.org/sites/default/files/sec18_full_proceedings_interior.pdf> [retrieved on 20180814] *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2023161105A1 (fr) * 2022-02-28 2023-08-31 Orange Procédé et module de détection de tentatives d'attaques informatiques dans un parc d'ordinateurs
FR3133087A1 (fr) * 2022-02-28 2023-09-01 Orange Procédé et module de détection de tentatives d’attaques informatiques dans un parc d’ordinateurs.

Also Published As

Publication number Publication date
CN115917539A (zh) 2023-04-04
EP4154141A1 (fr) 2023-03-29
US20230195884A1 (en) 2023-06-22
WO2021234267A1 (fr) 2021-11-25

Similar Documents

Publication Publication Date Title
EP2764462B1 (fr) Procede de generation, a partir d&#39;un fichier initial de paquetage comportant une application a securiser et un fichier initial de configuration, d&#39;un fichier de paquetage pour la securisation de l&#39;application, produit programme d&#39;ordinateur et dispositif informatique associes
US20120090025A1 (en) Systems and methods for detection of malicious software packages
EP4154141A1 (fr) Procede de securisation d&#39;un appel systeme, procede de mise en place d&#39;une politique de securite associee et dispositifs mettant en oeuvre ces procedes
CN109255235B (zh) 基于用户态沙箱的移动应用第三方库隔离方法
WO2001037085A1 (fr) Procede de chargement d&#39;applications dans un systeme embarque multi-application muni de ressources de traitement de donnees, systeme, et procede d&#39;execution correspondants
EP1386230A2 (fr) Procede et systeme pour gerer des executables a bibliotheques partagees
US10171502B2 (en) Managed applications
EP3063693B1 (fr) Système de détection d&#39;intrusion dans un dispositif comprenant un premier système d&#39;exploitation et un deuxième système d&#39;exploitation
EP1649363B1 (fr) Procede de gestion des composants logiciels integres dans un systeme embarque
WO2007068706A1 (fr) Procede pour securiser l&#39;execution d&#39;un code logiciel en langage intermediaire dans un appareil portatif
WO2022184998A1 (fr) Procede et module d&#39;installation d&#39;un programme de mitigation dans le noyau d&#39;un equipement informatique
EP4123492A1 (fr) Mise en partage d&#39;une fonction d&#39;une application définie en langage orienté objet
EP1054332B1 (fr) Système et procédé de gestion d&#39;attributs dans un environnement orienté objet
WO2023161105A1 (fr) Procédé et module de détection de tentatives d&#39;attaques informatiques dans un parc d&#39;ordinateurs
WO2023222330A1 (fr) Procédé et module de détection de vulnérabilités informatiques dans un parc d&#39;ordinateurs
FR3067486A1 (fr) Procede de detection non intrusif des failles de securite d&#39;un programme informatique
FR2864658A1 (fr) Controle d&#39;acces aux donnees par verification dynamique des references licites
EP3411821B1 (fr) Procédé de stockage de contenus, procédé de consultation de contenus, procédé de gestion de contenus et lecteurs de contenus
FR2859548A1 (fr) Procede de surveillance de l&#39;execution de programmes sur un ordinateur
FR2911022A1 (fr) Procede permettant d&#39;imposer une politique de securite a une application telechargeable accedant a des ressources du reseau
EP4394631A1 (fr) Procédé de contrôle d&#39;un calculateur embarqué propre à contrôler un système critique, calculateur et véhicule associés
EP2579177A1 (fr) Terminal mobile apte à modifier dynamiquement son niveau de sécurité et procédé de sécurisation associé
WO2007135316A1 (fr) Determination de nombres d&#39;appels de methode critique dans une application en langage objet
FR2942053A1 (fr) Procede et systeme de validation d&#39;une commande de suspension d&#39;activite d&#39;au moins une ressource d&#39;un terminal
WO2008084155A2 (fr) Traitement de donnee relative a un reseau de donnees

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 2

PLSC Publication of the preliminary search report

Effective date: 20211126

ST Notification of lapse

Effective date: 20230105