რატომ ამტვრევს VPN სერტიფიკატის გადატანა მის SELinux ეტიკეტს

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

რას აკეთებს გადარქმევა სინამდვილეში ეტიკეტთან

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

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

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

წაიკითხეთ მიმდინარე ეტიკეტი მოსალოდნელის წინააღმდეგ

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

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-ს სიმპტომის გასაქრობად. ორივე მოკლე გზა იძლევა სისტემას, რომელიც მუშაობს თითქოს, და უსაფრთხოების პოზიციას, რომელსაც ვერავინ აღწერს. მოკლე გამოკვლევა სჯობს ორივეს.