Ελέγξτε τα labels πριν κατηγορήσετε το SELinux

Όταν μια εφαρμογή σπάει σε host με SELinux enforcing, το αντανακλαστικό σε πολλές ομάδες είναι να γυρίσουν το SELinux σε permissive και να προχωρήσουν. Εμείς το κρατάμε enforcing σε κάθε host που λειτουργούμε, και κατά την εμπειρία μας η αιτία είναι συνήθως πολύ μικρότερη απ' όσο υπονοεί το αντανακλαστικό: ένα αρχείο που φέρει λάθος label. Αυτό το άρθρο δείχνει πώς το βρίσκετε γρήγορα, πώς το διορθώνετε σωστά, και πώς αποφεύγετε να κλειδωθείτε απ' έξω όσο το κάνετε.

Τι είναι ένα label, και πώς πάει στραβά

Το SELinux παίρνει αποφάσεις με βάση labels. Κάθε αρχείο και κάθε διεργασία φέρει ένα security context, και η πολιτική λέει ποιοι τύποι διεργασιών μπορούν να κάνουν τι σε ποιους τύπους αρχείων. Η πολιτική λέει επίσης τι label πρέπει να έχει κάθε διαδρομή: το περιεχόμενο του /var/www πρέπει να είναι httpd_sys_content_t, ένα εκτελέσιμο κάτω από το /usr/bin πρέπει να είναι bin_t, και ούτω καθεξής. Αυτά τα αναμενόμενα labels είναι οι κανόνες file context.

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

• Η mv κρατά το αρχικό label, άρα ένα αρχείο που δημιουργήθηκε σε home directory και μεταφέρθηκε σε web root εξακολουθεί να λέει ότι ανήκει σε home directory.
• Αρχεία που αποσυμπιέστηκαν χωρίς SELinux attributes, ή επαναφέρθηκαν από backup που δεν τα κράτησε, παίρνουν ό,τι τους δώσει ο κατάλογος προορισμού.
• Περιεχόμενο τοποθετημένο σε custom θέση, όπως το /srv/app, παίρνει γενικό label γιατί η πολιτική δεν έχει ακόμα κανόνα για εκείνη τη διαδρομή.

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

Διαβάστε πρώτα την απόρριψη

Πριν αλλάξετε οτιδήποτε, διαβάστε τι ακριβώς αρνήθηκε το SELinux:

ausearch -m AVC -ts recent

Κάθε απόρριψη ονομάζει τον τύπο διεργασίας (scontext), τον τύπο στόχου (tcontext), την κλάση αντικειμένου και το δικαίωμα. Αν ο τύπος στόχου μοιάζει λάθος για εκείνο το αρχείο (ένας web server που αρνήθηκε να διαβάσει κάτι με label user_home_t, για παράδειγμα), σχεδόν σίγουρα κοιτάτε πρόβλημα labels, όχι κενό στην πολιτική.

Συγκρίνετε αυτό που υπάρχει με αυτό που θα έπρεπε να υπάρχει

Τρεις εντολές απαντούν άμεσα στην ερώτηση:

ls -Z /path/to/file            # the label it has
matchpathcon /path/to/file     # the label the policy expects
restorecon -nv /path/to/file   # dry run: what restorecon would change

Το restorecon -n δεν αλλάζει τίποτα. Αναφέρει μόνο τη διαφορά ανάμεσα στο τρέχον label και στο αναμενόμενο, πράγμα που το κάνει τέλειο εργαλείο ελέγχου. Τρέξτε το σε ολόκληρο δέντρο μετά από εγκατάσταση, επαναφορά ή μεταφορά:

restorecon -Rnv /etc /usr /var /srv 2>/dev/null

Κενό αποτέλεσμα σημαίνει ότι κάθε αρχείο κάτω από αυτές τις διαδρομές φέρει το label που περιμένει η πολιτική. Κάθε γραμμή στην έξοδο είναι ένα αρχείο που δεν το φέρει, και αυτή η λίστα είναι συνήθως σύντομη και πολύ αποκαλυπτική. Τρέχουμε αυτού του είδους τον έλεγχο σε νέα builds ως ρουτίνα, και τα πρότυπα εγκατάστασής μας ξαναβάζουν label σε κρίσιμες διαδρομές στο βήμα post-install, ώστε ένας νέος host να ξεκινά τη ζωή του με σωστά labels πριν συνδεθεί κανείς.

Διορθώστε το με τον σωστό τρόπο

Για ένα αρχείο που απλώς έχει λάθος label, ξαναβάλτε του το label που περιμένει η πολιτική:

restorecon -Rv /path

Για μια custom θέση που η πολιτική δεν γνωρίζει, διδάξτε πρώτα στην πολιτική τον κανόνα και μετά ξαναβάλτε labels, ώστε η διόρθωση να επιβιώσει στο επόμενο πλήρες relabel:

semanage fcontext -a -t httpd_sys_content_t "/srv/app(/.*)?"
restorecon -Rv /srv/app

Το chcon αλλάζει επίσης labels, αλλά μόνο μέχρι το επόμενο relabel, μετά το οποίο το πρόβλημα επιστρέφει. Χρησιμοποιήστε το για πειράματα, όχι για διορθώσεις.

Αν τα labels είναι σωστά και η απόρριψη αφορά συμπεριφορά, ελέγξτε τα booleans πριν γράψετε πολιτική. Πολλές συνηθισμένες ανάγκες, όπως ένας web server που ανοίγει εξερχόμενες συνδέσεις δικτύου, είναι ένας μόνο διακόπτης:

getsebool -a | grep httpd
setsebool -P httpd_can_network_connect on

Να είστε καχύποπτοι με το audit2allow

Το audit2allow διαβάζει απορρίψεις και γράφει ένα policy module που τις επιτρέπει. Θα παράγει πάντα κάτι που δουλεύει, και ακριβώς αυτός είναι ο κίνδυνος. Αν η πραγματική αιτία είναι ένα αρχείο με λάθος label, το παραγόμενο module δίνει ένα ευρύ δικαίωμα για να εξαφανίσει το σύμπτωμα, και κάθε άλλο αρχείο και διεργασία αυτού του τύπου κληρονομεί την πιο αδύναμη πολιτική. Διαβάστε τι προτείνει. Ένας κανόνας που επιτρέπει σε ένα domain να μεταβεί σε ένα πολύ προνομιούχο, ή να διαβάζει τα πάντα ενός κοινού τύπου, είναι ισχυρή ένδειξη ότι το label είναι λάθος και το module είναι η λάθος διόρθωση. Τα custom modules είναι καμιά φορά σωστά, για in-house λογισμικό χωρίς δική του πολιτική, αλλά πρέπει να είναι το τελευταίο βήμα, όχι το πρώτο.

Enforcing με ασφάλεια σε απομακρυσμένο host

Το πέρασμα ενός απομακρυσμένου μηχανήματος από permissive σε enforcing είναι από εκείνες τις αλλαγές που μπορούν να κόψουν το δικό σας session αν κάτι έχει ακόμα λάθος label. Οπλίστε πρώτα ένα δίχτυ ασφαλείας, ώστε ο host να γυρίσει μόνος του πίσω αν χάσετε την πρόσβαση:

systemd-run --on-active=240 --unit=selinux-net /usr/sbin/setenforce 0
setenforce 1
# open a NEW ssh session and confirm it works
systemctl stop selinux-net.timer

Το systemd πυροδοτεί τον timer είτε επιβιώσει το session σας είτε όχι. Ακυρώστε τον μόνο αφού πετύχει μια ολοκαίνουργια σύνδεση. Το ίδιο μοτίβο δουλεύει για αλλαγές firewall, SSH και δρομολόγησης σε μηχάνημα στο οποίο δεν μπορείτε να πάτε με τα πόδια.

Μια σύντομη λίστα ελέγχου

• Τρέξτε restorecon -Rnv στις διαδρομές του συστήματος μετά από κάθε εγκατάσταση, επαναφορά ή μεταφορά.
• Διαβάστε την απόρριψη AVC και συγκρίνετε ls -Z με matchpathcon πριν αλλάξετε πολιτική.
• Χρησιμοποιήστε semanage fcontext συν restorecon για custom διαδρομές, όχι chcon.
• Ελέγξτε τα booleans πριν γράψετε module.
• Αντιμετωπίστε την έξοδο του audit2allow ως ερώτηση, όχι ως απάντηση.
• Ποτέ μη γυρνάτε έναν απομακρυσμένο host σε enforcing χωρίς χρονομετρημένο δρόμο επιστροφής.

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

Related

Σχετικά: Το hardening baseline σε κάθε host · Άμεση απόκριση σε ευπάθειες, την ίδια μέρα