Γιατί η μετακίνηση ενός πιστοποιητικού VPN σπάει την ετικέτα SELinux

Τα πιστοποιητικά μπορούν να βρίσκονται στον σωστό κατάλογο με αναγνώσιμη λειτουργία και ιδιοκτησία root, και η υπηρεσία να αναφέρει ακόμη ότι δεν μπορεί να ανοίξει το αρχείο. Σε σύστημα SELinux ο συνδυασμός αυτός δείχνει έναν συγκεκριμένο μηχανισμό και όχι τα δικαιώματα. Η ετικέτα ταξίδεψε μαζί με το αρχείο, γιατί η μετονομασία δεν δημιουργεί νέο αντικείμενο. Ο inode διατήρησε το περιβάλλον ασφαλείας που είχε στην παλιά διαδρομή, και η πολιτική για τη νέα διαδρομή δεν πήρε ποτέ την ευκαιρία να ορίσει το δικό της.

Τι κάνει πραγματικά μια μετονομασία σε μια ετικέτα

Ένα αρχείο φέρει το περιβάλλον SELinux του ως δεδομένα χαρακτηριστικών συνδεδεμένα με τον inode. Η μετονομασία μέσα σε ένα σύστημα αρχείων αλλάζει την καταχώριση καταλόγου και τίποτα άλλο, κάτι που είναι γρήγορο και ατομικό, και ο λόγος που το περιβάλλον επιβιώνει της μετακίνησης. Καμία πολιτική δεν ερωτάται, καμία προεπιλογή δεν εφαρμόζεται και καμία προειδοποίηση δεν εκτυπώνεται.

Η αντιγραφή συμπεριφέρεται διαφορετικά. Ένα αντίγραφο δημιουργεί νέο inode στον κατάλογο προορισμού, και η πολιτική ορίζει περιβάλλον από τον τύπο αυτού του καταλόγου, οπότε ένα αντιγραμμένο πιστοποιητικό συνήθως καταλήγει με σωστή ετικέτα, ενώ ένα μετακινημένο παραμένει λάθος. Αυτή η μία διαφορά εξηγεί το μεγαλύτερο μέρος της σύγχυσης σε αυτή την κατηγορία αιτημάτων.

Οι μετακινήσεις μεταξύ συστημάτων αρχείων πέφτουν πίσω στη σημασιολογία αντιγραφής, οπότε η ίδια εντολή μπορεί να συμπεριφέρεται διαφορετικά σε δύο μηχανήματα ανάλογα με το αν το /etc ζει σε δικό του τόμο. Ελέγξτε το πριν συμπεράνετε ότι το εργαλείο είναι αναξιόπιστο. Μια ματιά στον πίνακα προσαρτήσεων σάς λέει τι είδους μετακίνηση εκτελέσατε.

Διαβάστε την τρέχουσα ετικέτα απέναντι στην αναμενόμενη

Τρεις εντολές μόνο για ανάγνωση απαντούν στο ερώτημα χωρίς να αλλάξουν τίποτα. Η πρώτη δείχνει τι έχει τώρα το αρχείο, η δεύτερη αναφέρει τι περιμένει η πολιτική για αυτή την ακριβή διαδρομή, και η τρίτη απαριθμεί κάθε αρχείο κάτω από τον κατάλογο του οποίου η ετικέτα διαφέρει.

ls -lZ /etc/openvpn/client/office-ca.crt
matchpathcon /etc/openvpn/client/office-ca.crt
restorecon -Rn -v /etc/openvpn/client

Η δοκιμαστική εκτέλεση είναι αυτή που αξίζει εμπιστοσύνη, γιατί ονομάζει κάθε αρχείο του οποίου το περιβάλλον αποκλίνει από την πολιτική και αφήνει το σύστημα ανέπαφο. Αν το πιστοποιητικό εμφανιστεί σε αυτή τη λίστα, βρήκατε την ασυμφωνία ανάμεσα σε αυτό που σημαίνει η διαδρομή και σε αυτό που ισχυρίζεται το αρχείο. Αν δεν εμφανιστεί, η ετικέτα είναι ήδη αυτό που θέλει η πολιτική και ο χρόνος σας ανήκει αλλού.

Στη συνέχεια συσχετίστε τη διαφορά με μια πραγματική άρνηση. Η αναντιστοιχία είναι απόδειξη λανθασμένης ετικέτας, όχι απόδειξη ότι η υπηρεσία απέτυχε εξαιτίας της, και μια διόρθωση που εφαρμόζεται χωρίς αντίστοιχη άρνηση στο αρχείο καταγραφής είναι μια εικασία με επιπλέον βήματα.

Επαναφέρετε την αντιστοίχιση αντί να επινοήσετε μια εξαίρεση

Για τυπική τοποθεσία η πολιτική αντιστοιχίζει ήδη τη διαδρομή, οπότε το restorecon την εφαρμόζει και η δουλειά τελείωσε. Κρατήστε το εύρος στον κατάλογο που επισκευάζετε· η επανεπισήμανση ολόκληρου του συστήματος αρχείων είναι αργή, ανασταλτική και θάβει το αρχικό λάθος κάτω από μια πολύ μεγάλη αλλαγή.

Για προσαρμοσμένο κατάλογο η σειρά μετράει, και η αντιστροφή της παράγει μια εντολή που αναφέρει επιτυχία ενώ δεν αλλάζει τίποτα. Η αντιστοίχιση ανήκει στην πολιτική, η επανεπισήμανση ανήκει στο τέλος, και η δοκιμαστική εκτέλεση ανήκει πριν από τα δύο. Το να παραλείψετε αυτό το τελευταίο μέρος είναι ο τρόπος με τον οποίο μια διαδρομή που δεν ήταν ποτέ λάθος επανεπισημαίνεται παρόλα αυτά.

semanage fcontext -a -t openvpn_etc_t '/etc/openvpn/custom(/.*)?'
restorecon -Rv /etc/openvpn/custom

Το restorecon εφαρμόζει μια αντιστοίχιση· δεν μπορεί να επινοήσει μία. Αν κανένας κανόνας δεν περιγράφει τη διαδρομή, δεν υπάρχει τίποτα να επαναφερθεί, γι’ αυτό η μόνιμη αντιστοίχιση πρέπει να υπάρχει πριν από την επανεπισήμανση. Καταγράψτε ποια διαμόρφωση κατέχει αυτή την αντιστοίχιση, γιατί αλλιώς μια μεταγενέστερη μετακίνηση, μια ενημέρωση πακέτου ή μια επανεπισήμανση δημιουργεί ξανά το σφάλμα και το επόμενο άτομο ξεκινά από το μηδέν.

Γιατί το chcon δεν είναι η λύση

Το chcon γράφει ένα περιβάλλον απευθείας στο αρχείο. Έχει άμεσο αποτέλεσμα και είναι η λιγότερο ανθεκτική διαθέσιμη επιλογή, γιατί μια επανεπισήμανση του συστήματος αρχείων εφαρμόζει ξανά την πολιτική και πετάει τις χειροκίνητες αλλαγές χωρίς να ρωτήσει. Το αρχείο φαίνεται επισκευασμένο και η επισκευή έχει ημερομηνία λήξης που δεν έγραψε κανείς. Αυτό που θέλετε αντ’ αυτού είναι ένας κανόνας που περιγράφει τη διαδρομή, ώστε κάθε αρχείο που φτάνει εκεί να δέχεται αυτόματα την ίδια μεταχείριση.

Χειρότερα, διδάσκει το λάθος μάθημα: η υποκείμενη αντιστοίχιση λείπει ακόμη, οπότε η αποτυχία επιστρέφει εβδομάδες αργότερα χωρίς προφανές έναυσμα και χωρίς ανάμνηση της παράκαμψης. Χρησιμοποιήστε το chcon μόνο ως προσωρινό πείραμα για να επιβεβαιώσετε μια υπόθεση, μετά αντικαταστήστε το με μια αντιστοίχιση που επιβιώνει της επόμενης επανεπισήμανσης, και ελέγξτε ότι η αντικατάσταση βρίσκεται πράγματι στη θέση της.

Όταν η ετικέτα είναι σωστή και η πρόσβαση αποτυγχάνει ακόμη

Ξεκινήστε από τους γονικούς καταλόγους. Η άδεια διέλευσης ελέγχεται σε κάθε συστατικό της διαδρομής, οπότε ένα σωστά επισημασμένο πιστοποιητικό μέσα σε κατάλογο στον οποίο η υπηρεσία δεν μπορεί να μπει παραμένει μη αναγνώσιμο. Και το SELinux και η συνηθισμένη άδεια πρέπει να επιτρέπουν κάθε βήμα, και η διόρθωση του ενός δεν διορθώνει το άλλο.

Στη συνέχεια ελέγξτε την ταυτότητα της διεργασίας και το δικό της sandbox της υπηρεσίας. Μια μονάδα με περιοριστικό sandbox μπορεί να αρνηθεί πρόσβαση σε αρχείο που η πολιτική θα επέτρεπε ευχαρίστως, και από τη γραμμή του αρχείου καταγραφής οι δύο αιτίες φαίνονται ίδιες. Επιβεβαιώστε ποια διεργασία ρωτά πραγματικά, όχι ποια υποθέτετε ότι ρωτά.

Θυμηθείτε ότι οι κανόνες dontaudit μπορούν να καταστείλουν μηνύματα άρνησης, οπότε ένα κενό αρχείο ελέγχου είναι αδύναμη απόδειξη και όχι απόδειξη. Αν η πολιτική φαίνεται σωστή και η πρόσβαση αποτυγχάνει ακόμη, ερευνήστε πριν δημιουργήσετε μια ευρεία μονάδα επιτρεπόμενων, και μην απενεργοποιήσετε το SELinux για να εξαφανιστεί το σύμπτωμα. Και οι δύο συντομεύσεις δίνουν ένα σύστημα που φαίνεται να δουλεύει και μια στάση ασφαλείας που κανείς δεν μπορεί να περιγράψει. Μια σύντομη έρευνα είναι καλύτερη από οποιαδήποτε από τις δύο.