<commit_before>\documentclass[10pt,a4paper]{article}
\usepackage[utf8]{inputenc}
\usepackage[francais]{babel}
\usepackage[T1]{fontenc}
\author{Anthony \textsc{Caccia} \and Romain \textsc{Fontaine} \and Nikita \textsc{Marchant} }
\date{}
\title{\textsc{INFO-F-309 : Administration Système} Projet : Rapport d'analyse}

\setlength{\parindent}{1.5em}
\setlength{\parskip}{1em}
% \renewcommand{\baselinestretch}{1.5}

\begin{document}
\maketitle

\section{Contexte}

Une jeune start-up, HubDoc.be, développe un site-web permettant à des étudiants d'uploader des fichiers pdf de syllabus et d'anciens d'examens.
La valeur ajoutée de cette start-up (en plus d'héberger ces fichiers) est de proposer un aperçu en ligne de ces fichiers pour les lire rapidement sans les télécharger.

HubDoc.be aimerait proposer aux étudiants utilisant leur plate-forme de pouvoir uploader leurs résumés écrits en \LaTeX et HubDoc.be se charge de compiler ces différents documents a partir des sources.

HubDoc.be est une jeune entreprise de 3 employés.
Leur produit est développé en Python avec le framework Django.
Actuellement elle dispose de deux serveurs GNU/Linux (un serveur de production et un serveur de réserve en cas de panne) dont l'utilisation est relativement élevée.
HubDoc.be s'attend à une croissance assez importante dans les prochains mois;
elle s'attend donc à devoir faire fonctionner son application sur plusieurs machines pour supporter la charge.


\section{Introduction}

Nos utilisateurs aimeraient pouvoir uploader des archives (.zip, .tar, ..) contenant des sources \LaTeX via notre interface web et que notre service puisse les compiler en .pdf à la vollée.
Cependant, la compilation de fichiers \LaTeX comporte des risques de sécurtié si l'auteur de ces fichiers n'est pas digne de confiance.
En effet, il existe une commande \LaTeX qui permet d'exécuter des commandes shell.
Cette vulnérabilité pourrait permettre à un utilisateur malicieux de prendre le contrôle de nos serveurs ou d'exposer publiquer les données des autres utilisateurs.

\section{Descriptif}

La compilation de fichiers \LaTeX n'étant pas sûre\footnote{Même en désacivant la commande permettant d'exécuter un shell, il existe d'autres moyens d'exécuter du code arbitraire depuis la compilation d'un fichier. https://0day.work/hacking-with-LaTeX/ en est un example.}, nous isolerons chaque compilation dans une BSDjail séparée.

Le service de compilation \LaTeX sera hébergé sur des machines séparées du serveur web et de conversion pdf vers image pour des raisons de sécurité, d'isolation et parce que les machines assurant ces services sont déjà suffisamment utilisées.

Pour assurer la communication entre les serveurs web qui reçoivent les archives .zip contenant le \LaTeX et les serveurs de compilation nous utiliserons un système déjà utilisé ailleurs dans l'application :
Celery\footnote{http://www.celeryproject.org/}.

Il s'agit d'une file de tâches distribuée qui permet à des scripts qui tournent pendant très peu de temps (le temps d'une requête web) d'emmetre l'ordre d'effectuer une tache longue et complexe hors du cycle requête-réponse d'HTTP.
Celery sera donc responsable de démarrer la compilation des sources \LaTeX dans un environnement sur et isolé.


\section{Comparaison des alternatives}
Pour isoler l'exécution du compilateur du reste du système ainsi que des autres compilations, nous avons le choix entre deux grandes techniques : la vistualisation ou la conteneurisation.

\subsection{Virtualisation}

Le marché de la virtualisation est fort développé et propose donc beaucoup d'alternatives. Nous en avons considéré plusieurs :

\begin{itemize}
    \item{KVM}
    \item{Qemu}
    \item{Xen}
    \item{Hyper-V}
\end{itemize}

Nous n'en avons cependant retenu aucune. En effet, toutes ces solutions partagent un désavantage commun : une machine virtuelle est fort lourde.

Nous pourrions potentiellement compiler des dizaines de documents en parrallèle et l'emprinte mémoire ainsi que le ``relativement long'' temps de démarrage d'une machine virtuelle risquerait de poser problème.

De plus, le niveau d'isolation que garantissent les machines virtuelle est trop important pour l'application que nous en ferions.

\subsection{Conteneurs}
Le domaine des conteneurs est plus récent que celui de la virtualisation et donc moins développé (quoiqu'en pleine expansion).

Le conteneurs partagent eux aussi une caractéristique commune : ils ont été créés pour être légers et offir un niveau d'isolation moindre\footnote{Par exemple, la plus part partagent leur noyeau avec le système hote. (Ce qui ne nous pose pas problème ici)}.

Voici les différentes alternatives que nous avons sélectionnées :

\begin{itemize}
    \item{Docker}
    \item{Chroot linux}
    \item{OpenVZ}
\end{itemize}

Nous n'avons pas retenu Docker car c'est une solution assez jeune et qu'il n'est pas certain qu'un Docker soit suffisement sur : la documentation officielle recommande de ne pas faire tourner de processus dans on a pas confiance en root.

LXC et OpenVZ sont quant à eux surs. Cependant, leur défaut par rapport aux BSDJails et au Chroot Linux est que le conteneur comporte un système complet, ce qui utilise plus de ressources que nécéssaire.

\subsection{Chroot et BSD Jails}

Il nous reste donc à analyser les Chroot sous GNU/Linux et les Jail BSD. Les deux systèmes semblent être les plus légers qu'il existe sur le marché pour isoler des processus.


Les Chroot Linux (comme Docker) ne sont cependant pas suffisement surs pour l'utilisations que nous voulons en faire\footnote{Il est possible pour un processus root dans un Chroot d'en sortir et d'atteindre l'hote.}

Les Jails BSD sont donc notre seule option dont le niveau d'isolation est suffisant pour nos besoins et dont la consommation en ressources est suffisement faible.

Ce choix d'utiliser des BSDjails nous imposant dès lors une distribution BSD, nous avons décider de nous diriger vers celles orientées serveurs les plus connues,
c'est à dire FreeBSD, OpenBSD, NetBSD, DragonFlyBSD.
Notre choix s'est porté immédiatement sur OpenBSD, une distribution dont tous les réglages par défaut sont orientés vers une sécurité maximale pour un serveur.
Tous les autres systèmes peuvent être également utilisés de façon aussi sûre, mais ils ne sont pas conçus pour cela par défaut:
\begin{itemize}
    \item FreeBSD est un système d'exploitation multi-usage pour tout types d'utilisation, nous aurions dès lors pu l'utiliser aussi pour notre serveur, mais il nous aurait fallut plus de temps afin de la configurer pour avoir autant de sécurité que sur OpenBSD;
    \item NetBSD a été conçu afin de tourner sur n'importe quel système, du pc de bureau à la console de jeu en passant par le grille-pain. À nouveau, il nous aurait été possible de l'utiliser mais nous aurions également dû passer du temps à le configurer. Nous ne voulons pas non plus utiliser de grille-pain.
    \item DragonFlyBSD est une modification de FreeBSD orientée vers une utilisation en cluster, ce qui n'est pas utile dans notre cas, n'ayant pas les moyens financiers d'en monter un.
\end{itemize}

Pour la distribution \LaTeX, l'utilisation d'une BSD nous laisse peu de choix: il n'existe pratiquement que la distribution Tex Live, que nous utiliserons donc, duh! %TODO

Enfin, le logiciel antivirus choisi sera Clam AntiVirus.
En effet, il est l'un des seuls à être à la fois gratuit et libre, ce qui suit la philosophie de notre start-up.
Il est de plus très largement utilisé, ce qui renforce notre confiance en son développement et ses corrections rapides lors de rares failles de sécurité détectées.
Sa forte utilisation nous permettra également des recherches aisées d'aides sur l'Internet en cas de soucis.

\section{Mise en oeuvre}

Les workers Celery créeront une BSDjail par tache de compilation puis y copieront les sources \LaTeX avant de la démarrer et d'y exécuter le compilateur \LaTeX.
Une fois que le compilateur aura fini de s'éxecuter la jail s'arrêtera et la tache Celery extraiera le fichier compilé de l'arborescence de la jail.

[serveur supplémentaire avec openbsd, une distribution \LaTeX (texlive?) et un logiciel antivirus (clamav?)]
Il faudra investir dans un nouveau serveur, sur lequel nous installerons (*bsd).
Ceci fait, nous installerons une distribution \LaTeX et le logiciel antivirus.
Nous configurerons par la suite notre Celery et implémenterons nos scripts.

\end{document}
<commit_msg>On a pas le choix de BSD<commit_after>\documentclass[10pt,a4paper]{article}
\usepackage[utf8]{inputenc}
\usepackage[francais]{babel}
\usepackage[T1]{fontenc}
\author{Anthony \textsc{Caccia} \and Romain \textsc{Fontaine} \and Nikita \textsc{Marchant} }
\date{}
\title{\textsc{INFO-F-309 : Administration Système} Projet : Rapport d'analyse}

\setlength{\parindent}{1.5em}
\setlength{\parskip}{1em}
% \renewcommand{\baselinestretch}{1.5}

\begin{document}
\maketitle

\section{Contexte}

Une jeune start-up, HubDoc.be, développe un site-web permettant à des étudiants d'uploader des fichiers pdf de syllabus et d'anciens d'examens.
La valeur ajoutée de cette start-up (en plus d'héberger ces fichiers) est de proposer un aperçu en ligne de ces fichiers pour les lire rapidement sans les télécharger.

HubDoc.be aimerait proposer aux étudiants utilisant leur plate-forme de pouvoir uploader leurs résumés écrits en \LaTeX et HubDoc.be se charge de compiler ces différents documents a partir des sources.

HubDoc.be est une jeune entreprise de 3 employés.
Leur produit est développé en Python avec le framework Django.
Actuellement elle dispose de deux serveurs GNU/Linux (un serveur de production et un serveur de réserve en cas de panne) dont l'utilisation est relativement élevée.
HubDoc.be s'attend à une croissance assez importante dans les prochains mois;
elle s'attend donc à devoir faire fonctionner son application sur plusieurs machines pour supporter la charge.


\section{Introduction}

Nos utilisateurs aimeraient pouvoir uploader des archives (.zip, .tar, ..) contenant des sources \LaTeX via notre interface web et que notre service puisse les compiler en .pdf à la vollée.
Cependant, la compilation de fichiers \LaTeX comporte des risques de sécurtié si l'auteur de ces fichiers n'est pas digne de confiance.
En effet, il existe une commande \LaTeX qui permet d'exécuter des commandes shell.
Cette vulnérabilité pourrait permettre à un utilisateur malicieux de prendre le contrôle de nos serveurs ou d'exposer publiquer les données des autres utilisateurs.

\section{Descriptif}

La compilation de fichiers \LaTeX n'étant pas sûre\footnote{Même en désacivant la commande permettant d'exécuter un shell, il existe d'autres moyens d'exécuter du code arbitraire depuis la compilation d'un fichier. https://0day.work/hacking-with-LaTeX/ en est un example.}, nous isolerons chaque compilation dans une BSDjail séparée.

Le service de compilation \LaTeX sera hébergé sur des machines séparées du serveur web et de conversion pdf vers image pour des raisons de sécurité, d'isolation et parce que les machines assurant ces services sont déjà suffisamment utilisées.

Pour assurer la communication entre les serveurs web qui reçoivent les archives .zip contenant le \LaTeX et les serveurs de compilation nous utiliserons un système déjà utilisé ailleurs dans l'application :
Celery\footnote{http://www.celeryproject.org/}.

Il s'agit d'une file de tâches distribuée qui permet à des scripts qui tournent pendant très peu de temps (le temps d'une requête web) d'emmetre l'ordre d'effectuer une tache longue et complexe hors du cycle requête-réponse d'HTTP.
Celery sera donc responsable de démarrer la compilation des sources \LaTeX dans un environnement sur et isolé.


\section{Comparaison des alternatives}
Pour isoler l'exécution du compilateur du reste du système ainsi que des autres compilations, nous avons le choix entre deux grandes techniques : la vistualisation ou la conteneurisation.

\subsection{Virtualisation}

Le marché de la virtualisation est fort développé et propose donc beaucoup d'alternatives. Nous en avons considéré plusieurs :

\begin{itemize}
    \item{KVM}
    \item{Qemu}
    \item{Xen}
    \item{Hyper-V}
\end{itemize}

Nous n'en avons cependant retenu aucune. En effet, toutes ces solutions partagent un désavantage commun : une machine virtuelle est fort lourde.

Nous pourrions potentiellement compiler des dizaines de documents en parrallèle et l'emprinte mémoire ainsi que le ``relativement long'' temps de démarrage d'une machine virtuelle risquerait de poser problème.

De plus, le niveau d'isolation que garantissent les machines virtuelle est trop important pour l'application que nous en ferions.

\subsection{Conteneurs}
Le domaine des conteneurs est plus récent que celui de la virtualisation et donc moins développé (quoiqu'en pleine expansion).

Le conteneurs partagent eux aussi une caractéristique commune : ils ont été créés pour être légers et offir un niveau d'isolation moindre\footnote{Par exemple, la plus part partagent leur noyeau avec le système hote. (Ce qui ne nous pose pas problème ici)}.

Voici les différentes alternatives que nous avons sélectionnées :

\begin{itemize}
    \item{Docker}
    \item{Chroot linux}
    \item{OpenVZ}
\end{itemize}

Nous n'avons pas retenu Docker car c'est une solution assez jeune et qu'il n'est pas certain qu'un Docker soit suffisement sur : la documentation officielle recommande de ne pas faire tourner de processus dans on a pas confiance en root.

LXC et OpenVZ sont quant à eux surs. Cependant, leur défaut par rapport aux BSDJails et au Chroot Linux est que le conteneur comporte un système complet, ce qui utilise plus de ressources que nécéssaire.

\subsection{Chroot et BSD Jails}

Il nous reste donc à analyser les Chroot sous GNU/Linux et les Jail BSD. Les deux systèmes semblent être les plus légers qu'il existe sur le marché pour isoler des processus.


Les Chroot Linux (comme Docker) ne sont cependant pas suffisement surs pour l'utilisations que nous voulons en faire\footnote{Il est possible pour un processus root dans un Chroot d'en sortir et d'atteindre l'hote.}

Les Jails BSD sont donc notre seule option dont le niveau d'isolation est suffisant pour nos besoins et dont la consommation en ressources est suffisement faible.


Pour la distribution \LaTeX, l'utilisation d'une BSD nous laisse peu de choix: il n'existe pratiquement que la distribution Tex Live, que nous utiliserons donc, duh! %TODO

Enfin, le logiciel antivirus choisi sera Clam AntiVirus.
En effet, il est l'un des seuls à être à la fois gratuit et libre, ce qui suit la philosophie de notre start-up.
Il est de plus très largement utilisé, ce qui renforce notre confiance en son développement et ses corrections rapides lors de rares failles de sécurité détectées.
Sa forte utilisation nous permettra également des recherches aisées d'aides sur l'Internet en cas de soucis.

\section{Mise en oeuvre}

Les workers Celery créeront une BSDjail par tache de compilation puis y copieront les sources \LaTeX avant de la démarrer et d'y exécuter le compilateur \LaTeX.
Une fois que le compilateur aura fini de s'éxecuter la jail s'arrêtera et la tache Celery extraiera le fichier compilé de l'arborescence de la jail.

[serveur supplémentaire avec openbsd, une distribution \LaTeX (texlive?) et un logiciel antivirus (clamav?)]
Il faudra investir dans un nouveau serveur, sur lequel nous installerons (*bsd).
Ceci fait, nous installerons une distribution \LaTeX et le logiciel antivirus.
Nous configurerons par la suite notre Celery et implémenterons nos scripts.

\end{document}

{'fraction_non_alphanumeric': 0.048827374086889655, 'fraction_numerical': 0.0019223375624759708, 'mean_word_length': 4.884992458521871, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 2, 'lorem ipsum': 0, 'www.': 2, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '4967845', 'n_tokens_mistral': 4775, 'n_tokens_neox': 4737, 'n_words': 2191}