Last time I said it works? I was kidding. Try this.
This commit is contained in:
@@ -230,6 +230,12 @@
|
|||||||
howpublished="\url{https://www.ibm.com/downloads/cas/VG8KRPRM}"
|
howpublished="\url{https://www.ibm.com/downloads/cas/VG8KRPRM}"
|
||||||
}
|
}
|
||||||
|
|
||||||
|
@misc{ibmContainerVsVm,
|
||||||
|
title={Containers vs. Virtual Machines (VMs): What’s the Difference?},
|
||||||
|
author={IBM},
|
||||||
|
howpublished="\url{https://www.ibm.com/blog/containers-vs-vms/}"
|
||||||
|
}
|
||||||
|
|
||||||
@misc{ciaTriad,
|
@misc{ciaTriad,
|
||||||
title={What is the CIA triad (confidentiality, integrity and availability)?},
|
title={What is the CIA triad (confidentiality, integrity and availability)?},
|
||||||
author={Wesley Chai},
|
author={Wesley Chai},
|
||||||
@@ -242,6 +248,27 @@
|
|||||||
howpublished="\url{https://www.redhat.com/en/topics/virtualization}"
|
howpublished="\url{https://www.redhat.com/en/topics/virtualization}"
|
||||||
}
|
}
|
||||||
|
|
||||||
|
@misc{redhatContainerVsVm,
|
||||||
|
title={Containers vs VMs},
|
||||||
|
author={Red Hat},
|
||||||
|
year={2020},
|
||||||
|
howpublished="\url{https://www.redhat.com/en/topics/containers/containers-vs-vms}"
|
||||||
|
}
|
||||||
|
|
||||||
|
@misc{dockerAlternatives,
|
||||||
|
title={What Are The Best Docker Alternatives in 2022?},
|
||||||
|
author={Cody Slingerland},
|
||||||
|
year={2022},
|
||||||
|
howpublished="\url{https://www.cloudzero.com/blog/docker-alternatives/}"
|
||||||
|
}
|
||||||
|
|
||||||
|
@article{yasrab2018mitigating,
|
||||||
|
title={Mitigating docker security issues},
|
||||||
|
author={Yasrab, Robail},
|
||||||
|
journal={arXiv preprint arXiv:1804.05039},
|
||||||
|
year={2018}
|
||||||
|
}
|
||||||
|
|
||||||
@misc{ansible,
|
@misc{ansible,
|
||||||
title={Ansible},
|
title={Ansible},
|
||||||
author={Red Hat},
|
author={Red Hat},
|
||||||
|
|||||||
@@ -903,9 +903,207 @@ scripting, SQL injection}, χειραγώγηση \textlatin{cookies} ή εκμ
|
|||||||
|
|
||||||
\subsection{\textlatin{Application containerization}} \label{applicationContainerization}
|
\subsection{\textlatin{Application containerization}} \label{applicationContainerization}
|
||||||
|
|
||||||
|
Τα δοχεία ενθυλακώνουν μια εφαρμογή ως ένα αυτόνομο πακέτο που περιέχει τον
|
||||||
|
κώδικα, τις βιβλιοθήκες και τις εξαρτήσεις που χρειάζεται για να εκτελεστεί. Οι
|
||||||
|
εφαρμογές σε δοχεία θεωρούνται απομονωμένες με την έννοια ότι δεν έχουν ανάγκη
|
||||||
|
ένα αντίγραφο του λειτουργικού συστήματος αλλά αντ'' αυτού ένα
|
||||||
|
\textlatin{runtime engine} στο κύριο μηχάνημα που λειτουργεί ως διαμεσολαβητής
|
||||||
|
των δοχείων για να μοιράζονται το λειτουργικό σύστημα μεταξύ τους. Κοινές
|
||||||
|
βιβλιοθήκες ή εκτελέσιμα αρχεία μπορούν επίσης να μοιραστούν μεταξύ πολλών
|
||||||
|
δοχείων, συμβάλλοντας έτσι στην εξάλειψη περιττής υπολογιστικής ισχύος
|
||||||
|
καθιστώντας τα δοχεία μικρά στον χώρο που καταλαμβάνουν, γρήγορα στην εκκίνηση
|
||||||
|
και ικανά να εκτελεστούν σε οποιαδήποτε πλατφόρμα ή περιβάλλον νέφους.
|
||||||
|
|
||||||
|
\pagebreak
|
||||||
|
|
||||||
\section{\textlatin{Docker Attack Vector Mitigation}} \label{dockerAttackVectorMitigation}
|
\subsection{Πλεονεκτήματα \textlatin{containerization}} \label{containerizationAdvantages}
|
||||||
|
|
||||||
|
Τα δοχεία προσφέρουν μια σειρά από πλεονεκτήματα σε σχέση με τις παραδοσιακές
|
||||||
|
εικονικές μηχανές. Αυτά είναι μεταξύ άλλων τα εξής:
|
||||||
|
|
||||||
|
\begin{itemize}
|
||||||
|
|
||||||
|
\item \textbf{Φορητότητα}:
|
||||||
|
|
||||||
|
Τα δοχεία είναι ανεξάρτητα από το λειτουργικό σύστημα και το περιβάλλον
|
||||||
|
εκτέλεσης τους και ως εκ τούτου μπορούν να εκτελεστούν σε οποιαδήποτε
|
||||||
|
πλατφόρμα ή περιβάλλον νέφους ομοιόμορφα και με συνέπεια. Το γεγονός
|
||||||
|
ότι τα κομμάτια ενός προγράμματος μπορούν να ορισθούν σε ένα μονάχα
|
||||||
|
αρχείο κειμένου και να κατασκευαστούν με αυτοματοποιημένο τρόπο
|
||||||
|
οπουδήποτε τους δίνει πολύ μεγαλύτερο προβάδισμα στον τομέα της
|
||||||
|
φορητότητας σε σχέση με τις εικονικές μηχανές.
|
||||||
|
|
||||||
|
\item \textbf{\textlatin{Agility}}:
|
||||||
|
|
||||||
|
Το \textlatin{Docker Engine} ξεκίνησε το βιομηχανικό πρότυπο για τη
|
||||||
|
χρήση δοχείων προσφέροντας απλά εργαλεία ανάπτυξης και μια καθολική
|
||||||
|
προσέγγιση πακεταρίσματος που λειτουργεί εξίσου καλά σε όλες τις
|
||||||
|
πλατφόρμες. Το οικοσύστημα των δοχείων έχει μετατοπιστεί σε μηχανές που
|
||||||
|
διαχειρίζεται η \textlatin{Open Container Initiative (OCI)} και οι
|
||||||
|
προγραμματιστές μπορούν εύκολα και γρήγορα να πακετάρουν τις εφαρμογές
|
||||||
|
τους ως δοχεία τα οποία μπορούν να προσφέρουν χωρίς την έγνοια
|
||||||
|
υποστήριξης πολλών διαφορετικών πλατφορμών.
|
||||||
|
|
||||||
|
\item \textbf{Ταχύτητα}:
|
||||||
|
|
||||||
|
Τα δοχεία είναι ελαφρύτερα από τις παραδοσιακές εικονικές μηχανές λόγω
|
||||||
|
του διαμοιρασμού του πυρήνα και γι'' αυτό έχουν μικρότερο χρόνο
|
||||||
|
εκκίνησης. Αυτό τα καθιστά ιδανικά για την ανάπτυξη και την εκτέλεση
|
||||||
|
εφαρμογών σε περιβάλλοντα νέφους όπου η αποδοτικότητα αξιοποίησης των
|
||||||
|
υπολογιστικών πόρων αντανακλάται σε άμεση εξοικονόμηση κόστους.
|
||||||
|
|
||||||
|
\item \textbf{Απομόνωση σφαλμάτων}:
|
||||||
|
|
||||||
|
Εφόσον κάθε δοχείο είναι απομονωμένο και λειτουργεί ανεξάρτητα από τα
|
||||||
|
υπόλοιπα, η αποτυχία του ενός δε θα επηρεάσει τη συνεχή λειτουργία των
|
||||||
|
υπολοίπων. Οι ομάδες ανάπτυξης μπορούν να εντοπίζουν και να διορθώνουν
|
||||||
|
τυχόν τεχνικά προβλήματα χωρίς να υπάρχει διακοπή λειτουργίας σε άλλα
|
||||||
|
δοχεία.
|
||||||
|
|
||||||
|
\item \textbf{Αποδοτικότητα}:
|
||||||
|
|
||||||
|
Το γεγονός ότι τα δοχεία μοιράζονται τον ίδιο πυρήνα και κοινά κομμάτια
|
||||||
|
άλλων δοχείων του συστήματος τα καθιστά αρκετά μικρά σε μέγεθος ώστε να
|
||||||
|
είναι δυνατόν να εκτελεστούν πολλά περισσότερα δοχεία απ'' ότι θα
|
||||||
|
μπορούσαν εικονικές μηχανές. Επομένως, αξιοποιούνται καλύτερα οι πόροι
|
||||||
|
του συστήματος.
|
||||||
|
|
||||||
|
\pagebreak
|
||||||
|
|
||||||
|
\item \textbf{Ευκολία διαχείρισης}:
|
||||||
|
|
||||||
|
Τα δοχεία σε ένα σύστημα είναι εύκολα διαχειρίσιμα με απλές εντολές. Η
|
||||||
|
διαδικασία ενημέρωσης, εκκίνησης και τερματισμού τους μεταξύ άλλων
|
||||||
|
είναι γρήγορη και απλή. Ακόμα και για μια επιχείρηση με πολλούς
|
||||||
|
διακομιστές που θα έπρεπε να τα κάνει αυτά χειροκίνητα, υπάρχουν
|
||||||
|
πλατφόρμες ενορχήστρωσης δοχείων που πέραν αυτών των λειτουργιών
|
||||||
|
βοηθάνε και στην κλιμάκωση και διαχείριση του φόρτου εργασίας μεταξύ
|
||||||
|
δοχείων.
|
||||||
|
|
||||||
|
\item \textbf{Ασφάλεια}:
|
||||||
|
|
||||||
|
Η απομόνωση των εφαρμογών ως δοχεία εγγενώς αποτρέπει την εισβολή
|
||||||
|
κακόβουλου λογισμικού από το να επηρεάσει τα υπόλοιπα δοχεία ή το
|
||||||
|
σύστημα στο οποίο εκτελούνται. Επιπροσθέτως, άδειες ασφαλείας μπορούν
|
||||||
|
να ορισθούν με σκοπό τον αυτόματο αποκλεισμό ανεπιθύμητων στοιχείων από
|
||||||
|
τα δοχεία και τον περιορισμό επικοινωνίας μεταξύ δοχείων ή κομματιών
|
||||||
|
του συστήματος.
|
||||||
|
|
||||||
|
\end{itemize}
|
||||||
|
|
||||||
|
\subsection{Τύποι \textlatin{containerization}} \label{containerizationTypes}
|
||||||
|
|
||||||
|
Στην παράγραφο \ref{containerizationDefinition} αναφέραμε την έννοια
|
||||||
|
\textlatin{containerization}. Η ραγδαία αύξηση του ενδιαφέροντος και της χρήσης
|
||||||
|
δοχείων οδήγησε στην ανάγκη για πρότυπα γύρω από την τεχνολογία αυτή. Η
|
||||||
|
\textlatin{Open Container Initiative (OCI)} η οποία ιδρύθηκε τον Ιούνιο του
|
||||||
|
2015 από την \textlatin{Docker} και άλλους ηγέτες του κλάδου, προωθεί κοινά,
|
||||||
|
ανοικτά πρότυπα και προδιαγραφές γύρω από την τεχνολογία δοχείων. Εξαιτίας
|
||||||
|
αυτού, η \textlatin{OCI} συμβάλλει στη διεύρυνση των επιλογών για μηχανές
|
||||||
|
ανοιχτού κώδικα. Οι χρήστες δε θα είναι εγκλωβισμένοι στην τεχνολογία ενός
|
||||||
|
συγκεκριμένου προμηθευτή, αλλά θα μπορούν να επωφεληθούν από τις πιστοποιημένες
|
||||||
|
από την \textlatin{OCI} τεχνολογίες που θα τους επιτρέπουν να δημιουργούν
|
||||||
|
εφαρμογές σε δοχεία χρησιμοποιώντας ένα ευρύ σύνολο εργαλείων
|
||||||
|
\textlatin{DevOps} και να τις εκτελούν με τον ίδιο τρόπο σε οποιεσδήποτε
|
||||||
|
υποδομές της επιλογής τους.
|
||||||
|
|
||||||
|
Σήμερα αν και το \textlatin{Docker} αποτελεί μία από τις πιο γνωστές και ευρέως
|
||||||
|
χρησιμοποιούμενες μηχανές δοχείων, υπάρχουν πολλές άλλες υλοποιήσεις.
|
||||||
|
Εναλλακτικές όπως το \textlatin{podman, LXC} και το \textlatin{containerd} που
|
||||||
|
ήταν για καιρό η προεπιλογή του \textlatin{Docker} για \textlatin{container
|
||||||
|
runtime} προτού υιοθετήσει το \textlatin{runC} μπορεί να έχουν διαφορετικά
|
||||||
|
χαρακτηριστικά και προεπιλογές αλλά η υιοθέτηση και η αξιοποίηση των
|
||||||
|
προδιαγραφών της \textlatin{OCI} καθώς αυτές εξελίσσονται θα διασφαλίσει ότι οι
|
||||||
|
εναλλακτικές αυτές παραμένουν ανεξάρτητες από τους προμηθευτές, πιστοποιημένες
|
||||||
|
για να τρέχουν σε πολλαπλά λειτουργικά συστήματα και χρησιμοποιήσιμες σε
|
||||||
|
πολλαπλά περιβάλλοντα.
|
||||||
|
|
||||||
|
\subsection{Μερικές διαφορές σε υλοποιήσεις \textlatin{containerization}} \label{containerizationDifferences}
|
||||||
|
|
||||||
|
Παρότι οι προδιαγραφές της \textlatin{OCI} έχουν ως στόχο να διασφαλίσουν την
|
||||||
|
ομοιόμορφη λειτουργία της τεχνολογίας αυτής, υπάρχουν αρκετές διαφορές στην
|
||||||
|
υλοποίηση. Παραδείγματος χάριν, το \textlatin{podman} ενώ όπως το
|
||||||
|
\textlatin{Docker} συμμορφώνεται στις προδιαγραφές της \textlatin{OCI} δουλεύει
|
||||||
|
χωρίς δαίμονα από πίσω, πράγμα που επιδιώκει να κατευνάσει τις ανησυχίες γύρω
|
||||||
|
από τον τρόπο λειτουργίας του \textlatin{Docker}. Εξαιτίας του τρόπου
|
||||||
|
λειτουργίας του αν και από το 2021 χάρη στη δουλειά του \textlatin{Akihiro
|
||||||
|
Suda} \cite{AkihiroSuda} δεν ισχύει μόνο για αυτό πλεόν, το \textlatin{podman}
|
||||||
|
δύναται να εκτελεστεί από έναν χρήστη πέραν του \textlatin{root}.
|
||||||
|
|
||||||
|
Ένα ακόμα εργαλείο που έχει παρόμοια αρχιτεκτονική με το \textlatin{podman}
|
||||||
|
είναι το \textlatin{rkt} το οποίο προσπαθούσε να κρατήσει μια προσέγγιση
|
||||||
|
ασφαλούς σχεδιασμού εξαρχής (\textlatin{Secure-by-design}). Μπορούσε να
|
||||||
|
ενσωματώσει χαρακτηριστικά ασφαλείας όπως υποστήριξη \textlatin{SELinux, TMP
|
||||||
|
measurement} και εκτέλεση δοχείων σε απομονωμένες από το υλικό εικονικές
|
||||||
|
μηχανές. Παρ'' όλα αυτά, σύμφωνα με το \cite{dockerAlternatives} έπαψε να έχει
|
||||||
|
ενεργή ανάπτυξη και επομένως δεν θα συνεχίζει να ανταγωνίζεται παρόμοια
|
||||||
|
εργαλεία στον κλάδο των δοχείων.
|
||||||
|
|
||||||
|
\subsection{Δοχεία έναντι εικονικών μηχανών} \label{containersVsVms}
|
||||||
|
|
||||||
|
Παρότι πολλές φορές τα δοχεία συγχέονται με τις εικονικές μηχανές, οι δύο αυτές
|
||||||
|
έννοιες έχουν αρκετές διαφορές στην αρχιτεκτονική τους. Στην παραδοσιακή
|
||||||
|
εικονικοποίηση είτε αυτή γίνεται στις υπάρχουσες υποδομές μια επιχείρησης είτε
|
||||||
|
σε ένα περιβάλλον νέφους, ένας \textlatin{hypervisor} πρέπει να χρησιμοποιηθεί
|
||||||
|
για να εικονικοποιήσει φυσικό υλικό. Κάθε μια εικονική μηχανή έχει ένα
|
||||||
|
λειτουργικό σύστημα και ένα εικονικό αντίγραφο του υλικού που απαιτεί για να
|
||||||
|
εκτελεστεί μαζί με μια εφαρμογή και τις βιβλιοθήκες και εξαρτήσεις της. Από την
|
||||||
|
άλλη, ένα δοχείο αντί να εικονικοποιήσει το υλικό, εικονικοποιεί το λειτουργικό
|
||||||
|
σύστημα ούτως ώστε κάθε δοχείο να περιέχει μόνο την εφαρμογή, τις βιβλιοθήκες
|
||||||
|
και τις εξαρτήσεις της.
|
||||||
|
|
||||||
|
Η εικόνα \ref{fig:containerVsVm} παρουσιάζει τη διαφορά των δύο αρχιτεκτονικών
|
||||||
|
|
||||||
|
\begin{center}
|
||||||
|
\includegraphics[width = .8\textwidth]{Figures/RedHat_Virtualization/virtualization-vs-containers_transparent.png}
|
||||||
|
\captionof{figure}{\textlatin{Virtualization Vs Containers}}
|
||||||
|
\label{fig:containerVsVm}
|
||||||
|
\end{center}
|
||||||
|
|
||||||
|
Η απουσία του εικονικού λειτουργικού υλικού είναι που τα καθιστά γρήγορα,
|
||||||
|
φορητά και μικρότερα σε μέγεθος. Για να γίνει πιο εμφανής η διαφορά, σύμφωνα με
|
||||||
|
τη \textlatin{Red Hat} \cite{redhatContainerVsVm}, το μέγεθος των εικονικών
|
||||||
|
μηχανών μετράται της τάξεως των \textlatin{gigabyte} ενώ των δοχείων μένουν στα
|
||||||
|
\textlatin{megabyte}. Πολλές φορές όπως αναφέρεται και στο
|
||||||
|
\cite{ibmContainerVsVm}, τα δοχεία χρησιμοποιούνται για εφαρμογές
|
||||||
|
αρχιτεκτονικής \textlatin{microservices} όπου κάθε ξεχωριστό κομμάτι
|
||||||
|
αντιπροσωπεύει μια λειτουργία της εφαρμογής και είναι ευκολότερη η κλιμάκωση
|
||||||
|
μιας υπηρεσίας απ'' ότι θα ήταν με μια \textlatin{monolithic} αρχιτεκτονική.
|
||||||
|
Εκεί λόγω μεγέθους και πλήθους τους συνήθως απαιτείται η χρήση πλατφόρμας
|
||||||
|
ενορχήστρωσης δοχείων όπως το \textlatin{Kubernetes}, το \textlatin{Docker
|
||||||
|
Swarm} ή άλλα για αποδοτικότερη διαχείριση.
|
||||||
|
|
||||||
|
Το μόνο μειονέκτημα τους, το οποίο δεν επηρεάζει κατά πολύ τη χρήση τους, είναι
|
||||||
|
το γεγονός ότι δοχεία που δημιουργήθηκαν για να εκτελούν προγράμματα που
|
||||||
|
απαιτούν την ύπαρξη του λειτουργικού συστήματος \textlatin{Windows} δε μπορούν
|
||||||
|
να εκτελεστούν σε ένα περιβάλλον με τον πυρήνα του \textlatin{Linux}.
|
||||||
|
|
||||||
|
\subsection{Ασφάλεια στο \textlatin{Docker}} \label{dockerSecurityMore}
|
||||||
|
|
||||||
|
Οι εφαρμογές σε δοχεία έχουν ένα εγγενές επίπεδο ασφαλείας αφού μπορούν να
|
||||||
|
εκτελούνται ως απομονωμένες διεργασίες και να λειτουργούν ανεξάρτητα από τα
|
||||||
|
υπόλοιπα δοχεία. Με πλήρη απομόνωση θα μπορούσε να αποτραπεί στην περίπτωση
|
||||||
|
μόλυνσης από κακόβουλο λογισμικό, ο κίνδυνος να επηρεαστούν άλλα δοχεία ή το
|
||||||
|
ίδιο το σύστημα. Ωστόσο, η απομόνωση αυτή δεν είναι πλήρης. Ο διαμοιρασμός
|
||||||
|
κομματιών μιας εφαρμογής σε δοχείο βοηθάει στην αποδοτικότητα του συστήματος
|
||||||
|
αλλά ανοίγει και ένα παράθυρο ευκαιρίας για επιθέσεις. Το γεγονός επίσης πως
|
||||||
|
μοιράζονται τον ίδιο πυρήνα σημαίνει πως μια επίθεση με στόχο αυτόν, μπορεί
|
||||||
|
δυνητικά να επηρεάσει όλα τα δοχεία.
|
||||||
|
|
||||||
|
Σχετικά με τις εικόνες δοχείων, τα κομμάτια δηλαδή από τα οποία μια εφαρμογή σε
|
||||||
|
μορφή δοχείου αποτελείται, η ασφάλεια δεν είναι πάντα εγγυημένη. Πρέπει να
|
||||||
|
ληφθούν μέτρα προστασίας όπως η χρήση εικόνων προερχόμενες μόνο από
|
||||||
|
εγκεκριμένες πηγές, κάτι που εισάγει ένα μοντέλο εμπιστοσύνης αυτή τη φορά
|
||||||
|
ανάμεσα στον προμηθευτή της και τον τελικό χρήστη. Οι πάροχοι τεχνολογίας
|
||||||
|
δοχείων έχουν αποκτήσει μια προσέγγιση ασφαλούς σχεδιασμού ώστε πολλά από τα
|
||||||
|
απαραίτητα μέτρα να είναι ενεργοποιημένα χωρίς την απαίτηση επιπρόσθετης
|
||||||
|
αλληλεπίδρασης από τον χρήστη. Πλέον η μηχανή δοχείων υποστηρίζει όλες τις
|
||||||
|
ιδιότητες απομόνωσης που υποστηρίζει και το λειτουργικό σύστημα στο οποίο
|
||||||
|
εκτελείται και άδειες ασφαλείας μπορούν να δοθούν με σκοπό τον επιπρόσθετο
|
||||||
|
περιορισμό χρήσης πόρων και το εύρος του συστήματος στο οποίο έχει πρόσβαση η
|
||||||
|
μηχανή δοχείων.
|
||||||
|
|
||||||
|
\subsubsection{\textlatin{Docker Attack Vector Mitigation}} \label{dockerAttackVectorMitigation}
|
||||||
|
|
||||||
Με βάση το μοντέλο που περιγράφει το \cite{reshetova2014security} όπως
|
Με βάση το μοντέλο που περιγράφει το \cite{reshetova2014security} όπως
|
||||||
αναφέρεται στο \cite{bui2015analysis} όπου έχουμε ένα μηχάνημα στο οποίο
|
αναφέρεται στο \cite{bui2015analysis} όπου έχουμε ένα μηχάνημα στο οποίο
|
||||||
@@ -915,39 +1113,75 @@ scripting, SQL injection}, χειραγώγηση \textlatin{cookies} ή εκμ
|
|||||||
διεργασιών, αρχείων, της συσκευής, του \textlatin{IPC}, δικτύου και τέλος, των
|
διεργασιών, αρχείων, της συσκευής, του \textlatin{IPC}, δικτύου και τέλος, των
|
||||||
πόρων.
|
πόρων.
|
||||||
|
|
||||||
Αυτά επιτυγχάνονται κατά σειρά με την χρήση \textlatin{namespaces} όπου
|
Αυτά επιτυγχάνονται κατά σειρά με τη χρήση
|
||||||
οριοθετείται η ορατότητα των διεργασιών ανάμεσα στα δοχεία και το σύστημα όπως
|
|
||||||
επίσης, τα δικαιώματά τους. Χρήση \textlatin{mount namespaces}, με τα οποία οι
|
\begin{itemize}
|
||||||
διεργασίες κάθε δοχείου βλέπουν διαφορετικά το αρχείο του συστήματος. Όλες οι
|
|
||||||
δράσεις \textlatin{mount}, που γίνονται στο εκάστοτε δοχείο, περιορίζονται σε
|
\item \textbf{\textlatin{namespaces}} όπου οριοθετείται η ορατότητα των
|
||||||
αυτό όπως επίσης, οριοθετούνται τα δικαιώματα των αρχείων του πυρήνα σε μονάχα
|
διεργασιών ανάμεσα στα δοχεία και το σύστημα όπως επίσης, τα δικαιώματά
|
||||||
ανάγνωσης και αποτρέπονται περαιτέρω \textlatin{remountings}. Ο περιορισμός
|
τους.
|
||||||
συσκευών επιτυγχάνεται με το χαρακτηριστικό \textlatin{Device Whitelist
|
|
||||||
Controller} των \textlatin{cgroups} που αναφέρεται στο
|
\item \textbf{\textlatin{mount namespaces}}, με τα οποία οι διεργασίες κάθε
|
||||||
\cite{deviceWhitelistController} με την βοήθεια του οποίου περιορίζεται το
|
δοχείου βλέπουν διαφορετικά τη διάταξη των αρχείων του συστήματος. Όλες
|
||||||
σύνολο τον συσκευών στις οποίες έχει πρόσβαση ένα δοχείο και αποτρέπει αυτό από
|
οι δράσεις \textlatin{mount}, που γίνονται στο εκάστοτε δοχείο,
|
||||||
το να δημιουργήσει καινούριες αναπαραστάσεις συσκευών. Επιπροσθέτως επειδή τα
|
περιορίζονται σε αυτό όπως επίσης, οριοθετούνται τα δικαιώματα των
|
||||||
\textlatin{mount} γίνονται με την χρήση του \textlatin{nodev}, στην περίπτωση
|
αρχείων του πυρήνα σε μονάχα ανάγνωσης και αποτρέπονται περαιτέρω
|
||||||
που μια αναπαράσταση συσκευής είχε δημιουργηθεί σε προηγούμενο χρόνο στο
|
\textlatin{remountings}.
|
||||||
στιγμιότυπου που χρησιμοποιήθηκε για να κατασκευαστεί το δοχείο, οι διεργασίες
|
|
||||||
του δεν δύνανται να την χρησιμοποιήσουν για να επικοινωνήσουν με τον πυρήνα.
|
\item \textbf{\textlatin{Device Whitelist Controller}}, ενός
|
||||||
Επιπλέον επειδή η προεπιλεγμένη συνθήκη είναι να μην δίνονται εκτεταμένα
|
χαρακτηριστικού των \textlatin{cgroups} για περιοσιμό συσκευών, που
|
||||||
προνόμια σε ένα δοχείο, δεν υπάρχει πρόσβαση σε καμία συσκευή παρά μόνο εάν
|
αναφέρεται στο \cite{deviceWhitelistController} με τη βοήθεια του
|
||||||
γίνει εκτέλεση δοχείου ως χρήστης με ανώτατα δικαιώματα όπου υπάρχει πρόσβαση
|
οποίου περιορίζεται το σύνολο τον συσκευών στις οποίες έχει πρόσβαση
|
||||||
σε όλες. Ο περιορισμός \textlatin{IPC}, δηλαδή της επικοινωνίας των διεργασιών
|
ένα δοχείο και αποτρέπει αυτό από το να δημιουργήσει καινούριες
|
||||||
μεταξύ τους, επιτυγχάνεται με την χρήση \textlatin{IPC namespaces} που
|
αναπαραστάσεις συσκευών. Επιπροσθέτως επειδή τα \textlatin{mount}
|
||||||
καθιστούν δυνατή την δημιουργία ξεχωριστών συνόλων αυτών, οι διεργασίες των
|
γίνονται με τη χρήση του \textlatin{nodev}, στην περίπτωση που μια
|
||||||
οποίων επικοινωνούν μόνο μεταξύ τους. Μία από τις σημαντικότερες απομονώσεις
|
αναπαράσταση συσκευής είχε δημιουργηθεί σε προηγούμενο χρόνο στο
|
||||||
είναι αυτή του δικτύου. Χωρίς δικτυακή απομόνωση υπάρχει κίνδυνος επιθέσεων
|
στιγμιότυπου που χρησιμοποιήθηκε για να κατασκευαστεί το δοχείο, οι
|
||||||
όπως \textlatin{Man in the middle}, \textlatin{ARP, DNS spoofing} και άλλες.
|
διεργασίες του δε δύνανται να τη χρησιμοποιήσουν για να επικοινωνήσουν
|
||||||
Για να απομονωθεί η κίνηση δικτύου που λαμβάνει μέρος σε ένα δοχείο από αυτήν
|
με τον πυρήνα. Επιπλέον, επειδή η προεπιλεγμένη συνθήκη είναι να μη
|
||||||
των υπολοίπων και του συστήματος πρέπει να γίνει χρήση των \textlatin{network
|
δίνονται εκτεταμένα προνόμια σε ένα δοχείο, δεν υπάρχει πρόσβαση σε
|
||||||
namespaces}. Κάθε δοχείο θα έχει δικές του διευθύνσεις \textlatin{IP}, συσκευές
|
καμία συσκευή παρά μόνο εάν γίνει εκτέλεση δοχείου ως χρήστης με
|
||||||
και ό,τι χρειάζεται, προκειμένου να γίνεται αλληλεπίδραση μεταξύ των δοχείων
|
ανώτατα δικαιώματα όπου υπάρχει πρόσβαση σε όλες.
|
||||||
μέσω την διεπαφή δικτύου του καθενός σαν να είναι εξωτερικές οντότητες. Τέλος,
|
|
||||||
επιβάλλεται η οριοθέτηση των υπολογιστικών πόρων προκειμένου να αποφευχθεί μια
|
\item \textbf{\textlatin{IPC namespaces}} για περιορισμό \textlatin{IPC},
|
||||||
επίθεση τύπου άρνησης υπηρεσίας όπου μια διεργασία ή ένα σύνολο αυτών προσπαθεί
|
δηλαδή της επικοινωνίας των διεργασιών μεταξύ τους. Τα \textlatin{IPC
|
||||||
να καταναλώσει όλους τους πόρους του συστήματος. Με την βοήθεια των
|
namespaces} καθιστούν δυνατή τη δημιουργία ξεχωριστών συνόλων των
|
||||||
|
διεργασιών, που επικοινωνούν μεταξύ τους αλλά όχι με άλλες διεργασίες
|
||||||
|
πέραν του υποσυνόλου.
|
||||||
|
|
||||||
|
\item \textbf{\textlatin{network namespaces}}. Μία από τις σημαντικότερες
|
||||||
|
απομονώσεις είναι αυτή του δικτύου. Χωρίς δικτυακή απομόνωση υπάρχει
|
||||||
|
κίνδυνος επιθέσεων όπως \textlatin{Man in the middle}, \textlatin{ARP,
|
||||||
|
DNS spoofing} και άλλες. Για να απομονωθεί η κίνηση δικτύου που
|
||||||
|
λαμβάνει μέρος σε ένα δοχείο από αυτήν των υπολοίπων και του συστήματος
|
||||||
|
πρέπει να γίνει χρήση των \textlatin{network namespaces}. Κάθε δοχείο
|
||||||
|
θα έχει δικές του διευθύνσεις \textlatin{IP}, συσκευές και ό,τι
|
||||||
|
χρειάζεται, προκειμένου να γίνεται αλληλεπίδραση μεταξύ των δοχείων
|
||||||
|
μέσω της διεπαφής δικτύου του καθενός σαν να είναι εξωτερικές
|
||||||
|
οντότητες.
|
||||||
|
|
||||||
|
\item \textbf{\textlatin{cgroup}}. Έπιβάλλεται η οριοθέτηση των
|
||||||
|
υπολογιστικών πόρων προκειμένου να αποφευχθεί μια επίθεση τύπου άρνησης
|
||||||
|
υπηρεσίας όπου μια διεργασία ή ένα σύνολο αυτών προσπαθεί να
|
||||||
|
καταναλώσει όλους τους πόρους του συστήματος. Με τη βοήθεια των
|
||||||
\textlatin{cgroup}, επιτυγχάνεται ο έλεγχος του ποσοστού πόρων όπως
|
\textlatin{cgroup}, επιτυγχάνεται ο έλεγχος του ποσοστού πόρων όπως
|
||||||
\textlatin{CPU}, μνήμη, και χωρητικότητα που μπορεί να έχει κάθε δοχείο στην
|
\textlatin{CPU}, μνήμη, και χωρητικότητα που μπορεί να έχει κάθε δοχείο
|
||||||
διάθεση του.
|
στη διάθεση του.
|
||||||
|
|
||||||
|
\end{itemize}
|
||||||
|
|
||||||
|
Αυτές οι δυνατότητες υποστηρίζονται από το \textlatin{Docker} και μπορεί κανείς
|
||||||
|
να τις εκμεταλλευτεί για να προστατεύσει το περιβάλλον του από επιθέσεις.
|
||||||
|
Επιπλέον, υπάρχει και η δυνατότητα υποστήριξης των \textlatin{SELinux,
|
||||||
|
Apparmor, Seccomp} (στην περίπτωση χρήσης \textlatin{LXC}) όπως επίσης και
|
||||||
|
συμβατότητα με \textlatin{Linux capabilities} που θα μπορούσαν να εισάγουν ένα
|
||||||
|
ακόμα επίπεδο ασφαλείας αν χρησιμοποιηθούν σωστά, περιορίζοντας τα δικαιώματα
|
||||||
|
των διεργασιών των δοχείων σε μονάχα όσα χρειάζονται. Το \textlatin{Docker}
|
||||||
|
παρέχει αρκετά υπάρχοντα μέσα άμυνας προκειμένου να προστατευτεί από επιθέσεις
|
||||||
|
ακόμα και χωρίς επιπρόσθετες ρυθμίσεις. Παρ'' όλα αυτά οι αρχικές ρυθμίσεις
|
||||||
|
ασφαλείας είναι πιο ελαστικές απ'' όσο χρειάζεται προκειμένου να συνεχίζει να
|
||||||
|
λειτουργεί κανονικά για όλους τους χρήστες, αφήνοντας έτσι τους διαχειριστές
|
||||||
|
ασφαλείας υπεύθυνους να χρησιμοποιήσουν όσες δυνατότητες είναι απαραίτητες
|
||||||
|
προκειμένου να ανταπεξέλθουν σε κάθε επίθεση ανάλογα το περιβάλλον και τις
|
||||||
|
ανάγκες τους.
|
||||||
|
|
||||||
|
|||||||
Binary file not shown.
|
After Width: | Height: | Size: 9.3 KiB |
Reference in New Issue
Block a user