internship-slides-vlc/slides.md

% Renforcement de la sécurité d’un lecteur vidéo multiplate-forme par séparation des privilèges % Alexandre Janniaux % 19 septembre 2018

VideoLabs, VLC

Présentation de l'entreprise

• Créée en 2012
• Sponsorise le développement de VLC
• Propose des prestations en :
  • systèmes embarqués
  • pipeline vidéo
  • multimédia en général
• Composée d'une quinzaine d'employés

Présentation du stage

• Principalement de la recherche (4 mois)
• Utilisation d'une API d'encodage matériel
• Optimisation d'un moteur de rendu pour la VR
• Réalisation d'un prototype VLC multiprocessus

Sandboxing

• Besoin d'isolation mémoire
• Besoin de règles par processus
• Besoin de définir les possibilités pour chaque bout de l'application

Conteneurs

Fined Grained sandboxing

Objectifs de la sandbox

• être désactivable au démarrage
• définir des zones de privilège et d'accès
• ne pas réécrire les modules

Mécanismes de sandboxing sous Linux

• Linux capabilites
• Seccomp
• Linux namespaces
• cgroups

Mécanismes de sandboxing sous Windows

• Integrity level
• AppContainer
• DACL

Conception de la sandbox

• Réalisation d'un prototype indépendant
• Intégration dans VLC
• Choix du modèle

Modèles de sandbox : orchestrateur

+ Socket dédié pour chaque lien entre zone + Jetons d'accès + Moins d'appel système Mais + Croissance potentiellement quadratique du nombre de socket + Difficile à manipuler + Difficile à déboguer Exemple avec strace

Modèles de sandbox : broker

+ droits d'accès plus fin, centralisés et personnalisables + point de contrôle pour les logs et le debogage mais + logique de contrôle et de routage + plus d'étape de changement de contexte

Premier prototype

• Créer les processus
• Établir la communication entre eux
• Modèle orchestrateur

Manipulation de l'interface SCM et de la mémoire partagée

Modification des variables

• Répartition de l'arbre de variables sur plusieurs processus
• Très bon test pour la communication interprocessus
• Devenu gênant dans la suite

Deadlock version 1

Intégration d'une boucle événementielle

Deadlock version 2

+ impossible à régler sans concepts comme des futures et promesses + vivre avec, éviter de faire des IPC dans des handlers d'IPC

##

+ Ressemble beaucoup au XKCD

Objets proxy

• un identifiant
• proxy_SendMsgReply(proxy, msg, &cookie)

- nouvel objet proxy par downcasting et aggrégation

Description de l'API

/* Début du processus */
sandbox = vlc_sandbox_Init(&(const struct vlc_sandbox_cfg) {
    /* parameters and policy */
});

vlc_sandbox_Start(sandbox);

Démarrage des processus

/* vlc_sandbox_Init */
const char psz_zygote[] = "--sandbox-zygote=";
const char psz_worker[] = "--sandbox-worker=";
for(int i=0; i< cfg->argc; ++i)
{
    if(!strncmp(cfg->argv[i], psz_zygote, strlen(psz_zygote)))
    {
        // it's a zygote
    }
    else if(!strncmp( cfg->argv[i], psz_worker, strlen(psz_worker)))
    {
        // it's a worker
    }
}

Architecture du projet

- On a fait la partie correspondant à la mise en place du cadre de sandboxing - Il faut revenir à VLC

Méthode avec les modules de VLC

• Pattern proxy
• Générer de faux modules se comportant comme les vrais à IPC près

Méthode avec les objets de libvlccore

• Pattern strategy sur l'architecture de VLC
• Implémenter le pattern proxy

Protocole de communication

------------------------------------------------------------
| ID d'étage | ID de requête | ID de RPC | Paramètres  RPC |
------------------------------------------------------------

• À qui envoyer ?
• Comment répondre ?
• Que faire ?

Passage de ressources entre processus

block_t *block = block_Alloc(size);

• Très peu flexible
• Devrait être amené à changer pour Windows

Passage de ressources entre processus

Buffer multiplexé pour l'écriture de blocs

Passage de ressources sous Linux

• On utilise memfd_create dans block_Alloc
• Utilisation totalement transparente

Mais plus coûteux que le modèle précédent

Limitations du travail actuel sous Windows

Gestion des ressources sous Windows

BOOL WINAPI DuplicateHandle(
  _In_  HANDLE   hSourceProcessHandle,
  _In_  HANDLE   hSourceHandle,
  _In_  HANDLE   hTargetProcessHandle,
  _Out_ LPHANDLE lpTargetHandle,
  _In_  DWORD    dwDesiredAccess,
  _In_  BOOL     bInheritHandle,
  _In_  DWORD    dwOptions
);

SourceProcess et TargetProcess doivent avoir PROCESS_DUP_HANDLE

Gestion des droits sous Windows : Jobs

• Gestion des limitations de ressources dans les processus
• JOB_OBJECT_ULIMIT_HANDLES
• UserHandleGrantAccess

Malheureusement...

Gestion des droits sous Windows : Jobs

• Un user handle est un objet de l'interface, pas un objet système
• Les jobs ne sont pas une fonctionnalité de sécurité

On peut faire le parallèle entre les Jobs et cgroups, avec un esprit Windows (i.e. GUI)

Gestion des droits sous Windows : ACL

• PACL, DACL, ACE, SecurityDescriptor, Tokens...

##

Conclusion

• pattern reproductible
• difficultés à déboguer
• différences de paradigmes

Questions