ნუ დააწყობთ systemd-ის გამაგრებას OpenVPN-ის user-ის დაშვებაზე

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

ორი მოდელი, გადართვის ერთი მფლობელი

პირველი მოდელი დემონს ეკუთვნის. საზოგადოებრივი OpenVPN-ის user და group პარამეტრები იდენტობას ცვლიან გვირაბისა და გასაღებების დაყენების შემდეგ, ხოლო persist-key და persist-tun ერთად ინარჩუნებს ამ რესურსებს შემდგომში გამოსაყენებლად.

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

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

გადაწყვიტეთ, სად იცვლება იდენტობა

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

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

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

შესაძლებლობები საზღვრებია, არა ნიჭები

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

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

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

გაამაპეთ უფლებამოსილება სასიცოცხლო ციკლზე

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

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

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

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

ჩაწერეთ გეგმა და შეინარჩუნეთ აღდგენის წვდომა

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

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

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