HackTricks
Επισκόπηση Προστασίας κοντέινερ
Tip
Μάθετε & εξασκηθείτε στο AWS Hacking:
HackTricks Training AWS Red Team Expert (ARTE)
Μάθετε & εξασκηθείτε στο GCP Hacking:HackTricks Training GCP Red Team Expert (GRTE)
HackTricks Training Azure Red Team Expert (AzRTE)
Υποστηρίξτε το HackTricks
- Ελέγξτε τα σχέδια συνδρομής!
- Εγγραφείτε στην 💬 ομάδα Discord ή στην ομάδα telegram ή ακολουθήστε μας στο Twitter 🐦 @hacktricks_live.
- Μοιραστείτε κόλπα hacking υποβάλλοντας PRs στα HackTricks και HackTricks Cloud github repos.
Η πιο σημαντική ιδέα στη σκληροποίηση κοντέινερ είναι ότι δεν υπάρχει ένας μοναδικός έλεγχος που να ονομάζεται «ασφάλεια κοντέινερ». Αυτό που πολλοί αποκαλούν container isolation είναι στην πραγματικότητα το αποτέλεσμα της συνεργασίας πολλών μηχανισμών ασφάλειας και διαχείρισης πόρων του Linux. Εάν η τεκμηρίωση περιγράφει μόνο έναν από αυτούς, οι αναγνώστες τείνουν να υπερεκτιμούν τη δύναμή του. Εάν η τεκμηρίωση απαριθμεί όλους χωρίς να εξηγεί πώς αλληλεπιδρούν, οι αναγνώστες αποκτούν έναν κατάλογο ονομάτων αλλά όχι ένα πραγματικό μοντέλο. Αυτή η ενότητα προσπαθεί να αποφύγει και τα δύο λάθη.
Στο κέντρο του μοντέλου βρίσκονται οι namespaces, που απομονώνουν όσα μπορεί να δει το workload. Δίνουν στη διεργασία μια ιδιωτική ή μερικώς ιδιωτική όψη των filesystem mounts, των PIDs, του networking, των IPC objects, των hostnames, των user/group mappings, των cgroup paths, και ορισμένων clocks. Αλλά τα namespaces από μόνα τους δεν αποφασίζουν τι δικαιούται να κάνει μια διεργασία. Εκεί μπαίνουν οι επόμενες στρώσεις.
Οι cgroups διαχειρίζονται τη χρήση πόρων. Δεν είναι κυρίως ένα όριο απομόνωσης με την ίδια έννοια όπως τα mount ή τα PID namespaces, αλλά είναι κρίσιμα λειτουργικά επειδή περιορίζουν μνήμη, CPU, PIDs, I/O, και πρόσβαση σε συσκευές. Έχουν επίσης σημασία για την ασφάλεια επειδή ιστορικές τεχνικές breakout αλλοίωσαν δυνατότητες εγγραφής σε cgroup, ειδικά σε περιβάλλοντα cgroup v1.
Οι Capabilities διασπούν το παλιό, πανίσχυρο μοντέλο root σε μικρότερες μονάδες προνομίων. Αυτό είναι θεμελιώδες για κοντέινερ επειδή πολλά workloads εξακολουθούν να τρέχουν ως UID 0 μέσα στο container. Το ερώτημα λοιπόν δεν είναι απλώς «είναι η διεργασία root;», αλλά «ποιες capabilities επιβίωσαν, μέσα σε ποιες namespaces, κάτω από ποιους seccomp και MAC περιορισμούς;» Γι’ αυτό μια root διεργασία σε ένα container μπορεί να είναι σχετικά περιορισμένη ενώ μια root διεργασία σε άλλο container μπορεί στην πράξη να είναι σχεδόν αδιάκριτη από το host root.
Το seccomp φιλτράρει syscalls και μειώνει την επιφάνεια επίθεσης του κεντρικού πυρήνα που εκτίθεται στο workload. Συχνά είναι ο μηχανισμός που μπλοκάρει εμφανώς επικίνδυνες κλήσεις όπως unshare, mount, keyctl, ή άλλες syscalls που χρησιμοποιούνται σε breakout chains. Ακόμη κι αν μια διεργασία έχει μια capability που διαφορετικά θα επέτρεπε μια ενέργεια, το seccomp μπορεί να μπλοκάρει την πορεία του syscall πριν ο kernel το επεξεργαστεί πλήρως.
Το AppArmor και το SELinux προσθέτουν Mandatory Access Control πάνω από τους κανονικούς ελέγχους filesystem και προνομίων. Είναι ιδιαίτερα σημαντικά γιατί συνεχίζουν να έχουν σημασία ακόμη και όταν ένα container διαθέτει περισσότερες capabilities από όσες θα έπρεπε. Ένα workload μπορεί θεωρητικά να έχει το προνόμιο να επιχειρήσει μια ενέργεια αλλά να του απαγορεύεται η εκτέλεση επειδή το label ή το profile του απαγορεύει πρόσβαση στο σχετικό path, αντικείμενο ή λειτουργία.
Τέλος, υπάρχουν πρόσθετες στρώσεις σκληροποίησης που λαμβάνουν λιγότερη προσοχή αλλά παίζουν συχνά ρόλο σε πραγματικές επιθέσεις: no_new_privs, masked procfs paths, read-only system paths, read-only root filesystems, και προσεκτικά runtime defaults. Αυτοί οι μηχανισμοί συχνά σταματούν το «τελευταίο μίλι» μιας παραβίασης, ειδικά όταν ένας επιτιθέμενος προσπαθεί να μετατρέψει εκτέλεση κώδικα σε ευρύτερη αύξηση προνομίων.
Το υπόλοιπο αυτού του φακέλου εξηγεί καθέναν από αυτούς τους μηχανισμούς με περισσότερες λεπτομέρειες, συμπεριλαμβανομένου τι κάνει πραγματικά το kernel primitive, πώς να το παρατηρήσετε τοπικά, πώς τα κοινά runtimes το χρησιμοποιούν, και πώς οι χειριστές κατά λάθος το αποδυναμώνουν.
Διαβάστε στη συνέχεια
Πολλές πραγματικές διαφυγές επίσης εξαρτώνται από το ποιο περιεχόμενο του host έχει γίνει mount μέσα στο workload, οπότε μετά την ανάγνωση των βασικών προστασιών είναι χρήσιμο να συνεχίσετε με:
Tip
Μάθετε & εξασκηθείτε στο AWS Hacking:
Μάθετε & εξασκηθείτε στο GCP Hacking:Υποστηρίξτε το HackTricks
- Ελέγξτε τα σχέδια συνδρομής!
- Εγγραφείτε στην 💬 ομάδα Discord ή στην ομάδα telegram ή ακολουθήστε μας στο Twitter 🐦 @hacktricks_live.
- Μοιραστείτε κόλπα hacking υποβάλλοντας PRs στα HackTricks και HackTricks Cloud github repos.