Ο έλεγχος ταυτότητας μέσω PAM μπορεί να πετύχει όταν εκτελείτε τον πελάτη με το χέρι και να αποτύχει με AUTH_FAILED μόλις το systemd ξεκινήσει το ίδιο προφίλ. Ο κωδικός πρόσβασης δεν αλλάζει μεταξύ αυτών των εκτελέσεων· αυτό που αλλάζει είναι το σύνολο περιορισμών γύρω από τη διεργασία που θέτει την ερώτηση στο PAM. Το PAM απαντά μέσω ενός βοηθού του οποίου η ικανότητα να αλλάζει τα δικά του διαπιστευτήρια είναι ακριβώς αυτό που αφαιρεί μια σκληρυμένη μονάδα. Βρείτε αυτόν τον βοηθό και το όριο που χρειάζεται πριν αγγίξετε μια λίστα δυνατοτήτων.

Το unix_chkpwd είναι το δυαδικό αρχείο που απαντά στην ερώτηση του PAM

Με τοπικό έλεγχο ταυτότητας κωδικού πρόσβασης, το pam_unix σπάνια διαβάζει το ίδιο το αρχείο κατακερματισμού. Εκτελεί το unix_chkpwd, το οποίο οι διανομές εγκαθιστούν ως setuid root ή setgid shadow ώστε ένας κωδικός να μπορεί να ελεγχθεί για λογαριασμό μιας διεργασίας που δεν έχει καμία δουλειά να διαβάσει το /etc/shadow. Αφαιρέστε τη δυνατότητα απόκτησης αυτής της ταυτότητας και ο βοηθός δεν μπορεί να ολοκληρώσει τον έλεγχο, οπότε η μονάδα επιστρέφει μια απλή αποτυχία ελέγχου ταυτότητας.

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

Διαβάστε τη μονάδα πριν διαβάσετε το αρχείο καταγραφής κωδικών

Μια συσκευασμένη μονάδα μπορεί να φέρει ένα drop-in που δεν γράψατε, και η πραγματική διαμόρφωση είναι το συγχωνευμένο αποτέλεσμα. Εκτυπώστε τη μονάδα όπως τη βλέπει το systemd, μαζί με τις ρυθμίσεις sandbox που καθορίζουν αν ο βοηθός μπορεί να ανυψωθεί. Η επιθεώρηση μόνο για ανάγνωση αρκεί σε αυτό το στάδιο.

systemctl cat [email protected]
systemctl show [email protected] -p User -p Group -p CapabilityBoundingSet -p AmbientCapabilities -p NoNewPrivileges
journalctl -u [email protected] -b

Η πρώτη εντολή δείχνει από πού προέρχονται η μονάδα και τα drop-in της, κάτι που έχει σημασία γιατί μια παράκαμψη που προστέθηκε πριν από μήνες ζει περισσότερο από τη μνήμη του γιατί υπάρχει. Η δεύτερη εκτυπώνει τις τιμές sandbox από τις οποίες εξαρτώνται οι επόμενες δύο ενότητες.

Συγκρίνετε αυτό που βλέπετε με έναν λειτουργικό κεντρικό υπολογιστή της ίδιας διανομής και έκδοσης. Μια διαφορά στο User, στο CapabilityBoundingSet ή στο NoNewPrivileges είναι συγκεκριμένο στοιχείο· μια διαφορά σε σχόλια πεζού λόγου δεν είναι. Γράψτε τις τιμές πριν αλλάξετε οτιδήποτε, γιατί μια μεταγενέστερη σύγκριση με κινούμενο στόχο δεν αποδεικνύει τίποτα. Αν η υπηρεσία εκτελείται ως λογαριασμός χωρίς προνόμια με κενό σύνολο bounding, ο βοηθός δεν έχει σχεδόν τίποτα για να δουλέψει.

Μετασχηματισμός διαπιστευτηρίων, πρόσβαση αρχείων και πολιτική είναι τρία όρια

Ξεκινήστε με το τι συμβαίνει κατά το exec. Ένα δυαδικό setuid ή ένα αρχείο που φέρει δυνατότητες αρχείου προκαλεί μετασχηματισμό διαπιστευτηρίων, οπότε η ταυτότητα που προκύπτει δεν είναι συνέχεια του καλούντος. Το σύνολο bounding περιορίζει τι μπορεί να αποκτήσει ένα τέτοιο δυαδικό, και το NoNewPrivileges μπλοκάρει εντελώς την απόκτηση setuid, setgid και δυνατοτήτων αρχείου. Οποιοδήποτε από τα τρία μπορεί να σταματήσει τον βοηθό αφήνοντας κάθε άλλη λειτουργία της υπηρεσίας άθικτη.

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

Τέλος, ρωτήστε αν η υποχρεωτική πολιτική επιτρέπει καθόλου την ενέργεια. Μια δυνατότητα Linux δεν υπερισχύει του SELinux, και το να κατέχεις μία δεν αποδεικνύει τίποτα για έναν κανόνα type enforcement. Αντιμετωπίστε μια άρνηση πρόσβασης αρχείου και μια άρνηση δυνατότητας ως διαφορετικά στοιχεία, γιατί ονομάζουν διαφορετικές διορθώσεις και συχνά διαφορετικούς ιδιοκτήτες. Διαβάστε κάθε πεδίο της εγγραφής αντί για τη μόνη λέξη denied. Ποιο εκτελέσιμο έκανε την ενέργεια, σε ποιον τομέα έτρεξε, τι τύπου στόχο άγγιξε, ποια κλάση αντικειμένου ενεπλάκη και ποια άδεια αρνήθηκε η πολιτική — το καθένα στενεύει την απάντηση με διαφορετικό τρόπο.

Βγάλτε την άρνηση από το αρχείο ελέγχου

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

ausearch -m AVC,USER_AVC -ts recent

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

Οι οδηγίες αντιμετώπισης προβλημάτων SELinux της Red Hat βάζουν τους ελέγχους ετικετών και διαμόρφωσης πριν από τη δημιουργία κανόνων allow, που είναι η σωστή σειρά και για αυτό το πρόβλημα. Ένα λανθασμένα επισημασμένο βοηθητικό δυαδικό και ένα κενό στην πολιτική παράγουν παρόμοιες αρνήσεις αλλά χρειάζονται διαφορετικές επισκευές. Η δημιουργία κανόνα allow για λάθος επισήμανσης κρύβει το σφάλμα και αφήνει την επόμενη ενημέρωση πακέτου να το επαναφέρει. Επιβεβαιώστε την ετικέτα στον εγκατεστημένο βοηθό πριν γράψετε οποιαδήποτε πολιτική.

Αποδείξτε την αλλαγή με μία αποδεκτή και μία απορριφθείσα σύνδεση

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

Κάντε μια πραγματική προσπάθεια σύνδεσης και διαβάστε το ημερολόγιο αμέσως μετά. Η γραμμή που αποδεικνύει τη διόρθωση είναι η καταχώριση pam_unix(openvpn:auth) για αυτή την προσπάθεια: πρέπει να αναφέρει επιτυχή έλεγχο ταυτότητας, και καμία εγγραφή AVC δεν πρέπει να φέρει το ίδιο δευτερόλεπτο.

journalctl -u [email protected] -n 30 --no-pager
ss -tnp | grep openvpn

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

Σχετικά άρθρα