root ტერმინალში, უარყოფილი SELinux-ის ქვეშ: რატომ ვარდება hook

თქვენ up სკრიპტს root-ით უშვებთ, ის სრულდება, და იგივე სკრიპტი ვარდება, როცა სერვისი მას იძახებს. ფაილის ნებართვებში არაფერი შეცვლილა, ამიტომ ბუნებრივი შემდეგი ნაბიჯი მათი ხელახლა შესუსტებაა, რაც არაფერს ასწორებს. SELinux ჰოსტზე გადამწყვეტი ფაქტორი ხშირად არ არის ის, თუ ვინ არის პროცესი, არამედ ის, თუ რომელ დომენში მუშაობს, და root შეზღუდული დომენის შიგნით მაინც შეზღუდულია.

იგივე ბრძანება, ორი განსხვავებული უსაფრთხოების დომენი

ტიპების იძულება ერთად აფასებს წყაროს დომენს, სამიზნე იარლიყს და მოთხოვნილ ოპერაციას. თქვენი ტერმინალის სესია მუშაობს შეუზღუდავ ან ადმინისტრაციულ დომენში, ხოლო დემონი მუშაობს იმ დომენში, რომელიც მის ერთეულს აქვს მინიჭებული. ამიტომ იდენტური ბრძანებები სხვადასხვა გადაწყვეტილებას იძლევა, და განსხვავება განზრახ არის და არა პოლიტიკის ხარვეზი.

ამიტომ ორი გაშვების შედარება მხოლოდ მაშინ არის სასარგებლო, თუ მათ კონტექსტებს ადარებთ. გაუშვით იგივე ბრძანება shell-იდან და hook-იდან, და shell-ის ვერსია ადასტურებს, რომ ბინარული არსებობს და არგუმენტები სწორია; ის არაფერს ადასტურებს იმაზე, აქვს თუ არა სერვისს მისი გაშვების უფლება. გაუშვით ორივე გზით და შეადარეთ დომენები, და არა მხოლოდ გასვლის კოდები. სწორედ ეს შედარება აქცევს ბუნდოვან ნებართვის საჩივარს კონკრეტულ კითხვად ერთი დომენისა და ერთი იარლიყის შესახებ.

ამ ხარვეზის კლასიკური ფორმაა დამხმარე, რომელიც გარე ხელსაწყოს იძახებს. თავად hook შეიძლება ნებადართული იყოს, მაშინ როცა ის ხელსაწყო, რომელსაც ის იძახებს, ატარებს იარლიყს, რომლის გაშვებაც სერვისის დომენს არ შეუძლია, ან წერს საქაღალდეში, რომლის იარლიყი ამას კრძალავს.

წაიკითხეთ AVC ჩანაწერი hook-ის შეცდომის გვერდით

AVC უარყოფა ასახელებს იმ ველებს, რომლებიც საქმეს წყვეტენ: პროცესის წყაროს კონტექსტი, ობიექტის სამიზნე კონტექსტი, ობიექტის კლასი და კონკრეტული ნებართვა, რომელიც უარყოფილ იქნა. წაიკითხეთ ოთხივე თეორიის შექმნამდე, რადგან შესრულებაზე უარყოფას და ჩაწერაზე უარყოფას სრულიად განსხვავებული შესწორებები აქვთ.

ausearch -m AVC,USER_AVC -ts recent
ls -Z /usr/local/sbin/vpn-up.sh
ps -eZ | grep openvpn

წყაროს კონტექსტი უნდა შეესაბამებოდეს იმ დომენს, რომელშიც სერვისი რეალურად მუშაობს, ხოლო სამიზნე კონტექსტი — იმ ფაილის ან საქაღალდის იარლიყს, რომელსაც ოპერაცია შეეხო. თუ რომელიმე მათგანი არ ემთხვევა იმ შეცდომას, რომელსაც მისდევთ, თქვენ სხვა მოვლენას კითხულობთ.

ჩანაწერის გვერდით ჩაინიშნეთ პოლიტიკის ვერსია და შესრულებადი ფაილის ზუსტი გზა. დომენის სახელი, რომელიც ერთი დისტრიბუციის პოლიტიკაში გვხვდება, ამ ინსტალაციის შესახებ მტკიცებულებაა და არა გარანტია, რომ სხვა ბილდი იმავე წესებს აწვდის. სწორედ ეს კონტექსტი აძლევს სხვას საშუალებას, გაიმეოროს თქვენი დასკვნა საკუთარ ჰოსტზე. მის გარეშე ჩანაწერი ანეკდოტად იკითხება და არა მტკიცებულებად.

იარლიყი, კონფიგურაცია თუ პოლიტიკა: სამი შესწორება

პირველი შესწორებაა იარლიყი, რომელიც არ ემთხვევა ფაილის დაყენებულ ადგილს. cp-ით ადგილზე კოპირებულ ან რედაქტორით დაწერილ სკრიპტს შეიძლება ჰქონდეს ნაგულისხმევი იარლიყი, რომელსაც სერვისის დომენი ვერ გამოიყენებს, და მოსალოდნელი კონტექსტის აღდგენა ამას პოლიტიკის შეხების გარეშე ასწორებს.

მეორე კონფიგურაციაა. დისტრიბუციამ შეიძლება შესთავაზოს ოპერაციის გაშვების მხარდაჭერილი ხერხი, დამხმარისთვის დოკუმენტირებული საქაღალდე ან განახლებული პოლიტიკის პაკეტი, რომელიც უკვე ნებადართავს მას. თქვენი განლაგების მხარდაჭერილზე შეცვლა იაფია, ვიდრე პოლიტიკის დაწერა, და განახლებებს უძლებს.

მესამე ნამდვილად არსებული წესია, და ის უკანასკნელი ღონისძიება უნდა იყოს. შექმენით კანდიდატი აუდიტის ხელსაწყოებით, წაიკითხეთ, რას უშვებს ის რეალურად, შეზღუდეთ იმ ოპერაციასა და დომენზე, რომელიც დააკვირდით, და სთხოვეთ სხვას გადახედოს მას, სანამ პროდუქციას მიუახლოვდება.

რატომ არ არის ძველი allow მოდული პასუხი

ამ ხარვეზის ძიების შედეგები სავსეა მზა მოდულებით, ხშირად იმ ხელსაწყოსთვის, რომელსაც hook აღარ იძახებს. ერთის დაყენება იძლევა ნებართვებს, რომლებსაც შეიძლება საერთო არაფერი ჰქონდეს თქვენს უარყოფასთან, და ის ნამდვილ შეუსაბამობას ადგილზე ტოვებს, სამაგიეროდ მუდმივ ხვრელს ამატებს.

ის მალავს შემდეგ მარცხსაც. მოდული, რომელიც ოპერაციების ფართო კლასს უშვებს, ამ შეცდომას გააქრობს და შემდეგს გაცილებით ძნელად მისაწერ ნივთად აქცევს. მოდულის მოგვიანებით მოხსნა ისეთივე ცვლილებაა, რომლის დაგეგმვაც არავის სურს, ამიტომ მოკლე გზა მიდრეკილია მუდმივი გახდეს.

დისციპლინირებული შედარება არის თქვენს მიერ წაკითხულ უარყოფასა და თქვენს მიერ შემოთავაზებულ ცვლილებას შორის. Red Hat-ის SELinux-ის პრობლემების მოგვარების გზამკვლევი იარლიყებისა და კონფიგურაციის შემოწმებებს გენერირებულ პოლიტიკამდე სწორედ ამ მიზეზის გამო აყენებს. თუ ჩანაწერში შესაბამისი უარყოფა არ არის, SELinux სავარაუდოდ თქვენი პრობლემა არ არის, და გზის, sandbox-ის ან ნებართვების საკითხები ჯერ კიდევ ღიაა.