% 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