PAM-ის ავთენტიფიკაცია ხელით მუშაობს, მაგრამ როგორც OpenVPN სერვისი იშლება
PAM-ის შესვლა, რომელიც root-შელიდან მუშაობს და systemd-ის ქვეშ იშლება, მიუთითებს დამხმარეზე და არა პაროლზე. გამოყავით პრივილეგიები, ფაილებზე წვდომა და SELinux.
ავთენტიფიკაცია PAM-ის მეშვეობით შეიძლება წარმატებით დასრულდეს, როცა კლიენტს ხელით უშვებთ, და ჩავარდეს AUTH_FAILED-ით, როგორც კი systemd იმავე პროფილს გაუშვებს. პაროლი ამ გაშვებებს შორის არ იცვლება; იცვლება იმ პროცესის გარშემო არსებული შეზღუდვების ნაკრები, რომელიც PAM-ს კითხვას უსვამს. PAM პასუხობს დამხმარის მეშვეობით, რომლის საკუთარი სერტიფიკატების შეცვლის უნარი ზუსტად ის არის, რასაც გამაგრებული unit აშორებს. იპოვეთ ეს დამხმარე და მისთვის საჭირო საზღვარი, სანამ შესაძლებლობების სიას შეეხებით.
unix_chkpwd არის ბინარული, რომელიც პასუხობს PAM-ის კითხვას
ლოკალური პაროლით ავთენტიფიკაციისას pam_unix იშვიათად კითხულობს თავად hash ფაილს. ის უშვებს unix_chkpwd-ს, რომელსაც დისტრიბუტივები აყენებენ setuid root ან setgid shadow-ის სახით, რათა ერთი პაროლი შემოწმდეს იმ პროცესის სახელით, რომელსაც /etc/shadow-ის კითხვასთან საქმე არ აქვს. მოხსენით ამ იდენტობის მიღების უნარი და დამხმარე ვერ დაასრულებს შემოწმებას, ამიტომ მოდული აბრუნებს ჩვეულებრივ ავთენტიფიკაციის წარუმატებლობას.
შემდეგ ეს წარუმატებლობა ყველა ჟურნალში, რომელსაც კლიენტი ხედავს, სერტიფიკატების პრობლემად გამოიყურება. ეს არის ხაფანგი: კლიენტი იუწყება, რაც PAM-მა უთხრა, ხოლო PAM მხოლოდ იმას იუწყება, რომ სტეკმა თქვა არა. დამხმარის root-ად ხელით გაშვება არც არაფერს ამტკიცებს, რადგან ის პრივილეგიების იმ გზას ამოწმებს, რომელსაც სერვისი არასოდეს იყენებს. წაიკითხეთ unit, რომელიც systemd-მა რეალურად ჩატვირთა, შემდეგ სისტემური ჟურნალი შესრულებული მცდელობისთვის. ეს ორი ხედვა ყოფს sandbox-ის პრობლემას არასწორი პაროლის პრობლემისგან.
წაიკითხეთ unit, სანამ პაროლის ჟურნალს წაიკითხავთ
შეფუთულ unit-ს შეიძლება ჰქონდეს drop-in, რომელიც თქვენ არ დაგიწერიათ, და ეფექტური კონფიგურაცია შერწყმული შედეგია. დაბეჭდეთ unit ისე, როგორც 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პირველი ბრძანება გვიჩვენებს, საიდან მოდის unit და მისი 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ცარიელი შედეგი უდანაშაულობის მტკიცებულება არ არის. ეს ნიშნავს, რომ ან აუდიტი არ აგროვებს, ან თქვენმა ფანჯარამ მცდელობა გამოტოვა, და ორივე შესაძლებლობა უნდა გამოირიცხოს, სანამ პოლიტიკას გამორიცხავთ.
Red Hat-ის SELinux-ის პრობლემების მოგვარების სახელმძღვანელო ეტიკეტებისა და კონფიგურაციის შემოწმებებს allow წესების შექმნამდე აყენებს, რაც ამ პრობლემისთვისაც სწორი თანმიმდევრობაა. არასწორად ეტიკეტირებული დამხმარე ბინარი და პოლიტიკის ხარვეზი მსგავს უარყოფებს იწვევს, მაგრამ სხვადასხვა შეკეთებას მოითხოვს. ეტიკეტირების შეცდომისთვის allow წესის შექმნა მალავს ხარვეზს და შემდეგ პაკეტის განახლებას აძლევს მის ხელახლა შემოტანის საშუალებას. დაადასტურეთ დაყენებული დამხმარის ეტიკეტი, სანამ რაიმე პოლიტიკას დაწერთ.
დაამტკიცეთ ცვლილება ერთი მიღებული და ერთი უარყოფილი შესვლით
შეცვალეთ მხოლოდ ის საზღვარი, რომელიც აჩვენეთ, შემდეგ გამოსცადეთ ორივე შედეგი. ანგარიში, რომელიც უნდა ავთენტიფიცირდეს, უნდა წარმატდეს, ხოლო არასწორი პაროლის მქონე ანგარიში კვლავ უნდა ჩავარდეს. ცვლილება, რომელიც ყველა მცდელობას წარმატებულს ხდის, ავთენტიფიკაცია მოხსნა და არა შეაკეთა.
შეასრულეთ რეალური კავშირის მცდელობა და მაშინვე წაიკითხეთ ჟურნალი. ხაზი, რომელიც შეკეთებას ამტკიცებს, ამ მცდელობის pam_unix(openvpn:auth) ჩანაწერია: მასში უნდა ეწეროს ავთენტიფიკაცია წარმატებული, და არც ერთ AVC ჩანაწერს არ უნდა ჰქონდეს იგივე წამი.
journalctl -u [email protected] -n 30 --no-pager
ss -tnp | grep openvpnმუშა გვირაბს ხელახალი დაკავშირებაც სჭირდება, რადგან sandbox-ის ცვლილებები მეორე კავშირს უფრო ხშირად ამტვრევს, ვიდრე პირველს. შეამოწმეთ დამყარებული socket ხელახალი დაკავშირების შემდეგ და დაადასტურეთ, რომ იგივე unit კვლავ ემსახურება მას.