VPN ღილაკს sudo სჭირდება: შემოფარგლე წესი, გადაამოწმე პოლიტიკა
სამუშაო მაგიდის ღილაკი არ არის მიზეზი უპაროლო root-ისთვის. შეამოწმე, შეუძლია თუ არა ქსელის მენეჯერს ეს თავად, შემოფარგლე ერთი ბრძანება და შემდეგ გადაამოწმე მთელი sudo პოლიტიკა.
VPN ღილაკი ადმინისტრატორთან მუშაობს, დანარჩენებთან კი ვარდება, ამიტომ ვიღაც sudoers-ში ხაზს ამატებს. ის ხაზი ჩვეულებრივ უფრო დიდხანს ცოცხლობს, ვიდრე პრობლემა, რომლის გადასაჭრელადაც შეიქმნა, და ხშირად მეტს ანიჭებს, ვიდრე ღილაკს სჭირდება. პოლიტიკის რედაქტირებამდე შეამოწმე, შეუძლია თუ არა მხარდაჭერილი კავშირის მფლობელს უკვე ამ სამუშაოს შესრულება. ქვემოთ მოცემული სამი პირობა წყვეტს, საერთოდ მონაწილეობს თუ არა sudo.
პირობა 1: მხარდაჭერილ მფლობელს ეს sudo-ს გარეშე შეუძლია
Linux-ის სამუშაო მაგიდების უმეტესობაზე ქსელის მენეჯერი უკვე ფლობს VPN კავშირებს და მისი ავტორიზაცია sudo-ს ნაცვლად polkit-ის გავლით მიდის. მომხმარებელს, რომელსაც კავშირის აწევის უფლება აქვს, ეს ბრძანების ხაზიდან ნებისმიერი root წესის გარეშე შეუძლია. სანამ იფიქრებ, რომ ღილაკს პრივილეგია სჭირდება, შეამოწმე, რას უშვებს მენეჯერი. თუ პასუხი კი არის, მაშინ sudoers-ის ცვლილება პრობლემას წყვეტს, რომელიც არ არსებობს.
nmcli connection show
nmcli connection up "Work VPN"
თუ მენეჯერი უარს ამბობს, წაიკითხე რატომ: დაკარგული polkit წესი, სხვა მომხმარებლის კუთვნილი კავშირი ან პროფილი, რომელიც იქ არის შენახული, სადაც მომხმარებელი მას ვერ წაიკითხავს. თითოეულ მათგანს აქვს მხარდაჭერილი გადაწყვეტა, sudo წესზე უფრო ვიწრო. პრივილეგიის ამაღლება ბოლო საშუალებაა, არა პირველი.
პირობა 2: წესი ასახელებს ერთ შესრულებად ფაილს და მის არგუმენტებს
თუ sudo ნამდვილად საჭიროა, წესმა ზუსტი ბრძანება და, სადაც შესაძლებელია, ის არგუმენტები უნდა დაასახელოს, რომელთა გამოყენებაც შეიძლება. წესი, რომელიც მომხმარებელს სახვევი სკრიპტის გაშვების უფლებას აძლევს, მხოლოდ იმდენად უსაფრთხოა, რამდენადაც უსაფრთხოა ამ სკრიპტის უფლებები, რადგან მომხმარებელს შეუძლია შეცვალოს ის, რასაც root შეასრულებს. წესი ბრძანების შემდეგ ნებისმიერი სიმბოლოს ნიშნით იგივე პრობლემაა უფრო მოკლე ფორმით.
sudo -l -U alice
ls -l /usr/local/sbin/vpn-up
შეამოწმე ბრძანების ჯაჭვის ყოველი ბილიკი: ბინარული, სკრიპტი, რომელსაც ის იძახებს, კონფიგურაციის ფაილი, რომელსაც კითხულობს და მათ შორის არსებული ნებისმიერი დირექტორია. თუ რომელიმე მათგანი მომხმარებლისთვის ჩასაწერია, შემოფარგლული წესი პრაქტიკაში შეუზღუდავი root-ია. არგუმენტებიც მნიშვნელოვანია, რადგან კონფიგურაციის ბილიკის მიმღები ბრძანება შეიძლება მომხმარებლის მიერ კონტროლირებად ფაილზე იყოს მიმართული. წესი დაწერე ოპერაციისთვის და არა ღილაკისთვის.
შეჩერდი, თუ ბრძანებას სამუშაოდ მომხმარებლის მიერ კონტროლირებადი ფაილი სჭირდება. მაშინ დიზაინი არასწორია და ვერც ერთი sudoers სინტაქსი მას უსაფრთხოს ვერ გახდის.
პირობა 3: მთელი პოლიტიკა ანალიზდება, არა მხოლოდ შენი ხაზი
შეამოწმე იმ რედაქტორით, რომელიც ფაილს კეტავს და სინტაქსს ამოწმებს, და შეამოწმე აწყობილი პოლიტიკა და არა ფრაგმენტი. ფაილი, რომელიც დამოუკიდებლად ანალიზდება, მაინც შეიძლება ჩართვის წესრიგი დაარღვიოს ან წესი გააორმაგოს ისე, რომ ქცევა შეიცვალოს.visudo-ს სახელმძღვანელო აღწერს როგორც კეტავ რედაქტორს, ისე აქ გამოყენებულ მხოლოდ-შემოწმების რეჟიმს.
sudo visudo -c
sudo visudo -cf /etc/sudoers.d/vpn-launcher
შემოწმება წარუმატებლობისას აცნობებს ფაილსა და ხაზს, და სწორედ ეს ანგარიშია სასარგებლო ნაწილი. გაასწორე განზრახული ცვლილება რედაქტორის მეშვეობით და ნუ შეინახავ ძალით ცნობილ შეცდომას, რადგან გატეხილ პოლიტიკას შეუძლია ერთდროულად ყველა ადმინისტრატორი ჩაკეტოს. ჩართვის დირექტორიაში მყოფ ფაილებსაც სჭირდებათ სახელმძღვანელოს მოთხოვნილი საკუთრება და რეჟიმი, თორემ მათ იგნორირება ან უარყოფა მოხდება. სინტაქსი მხოლოდ პირველი კარიბჭეა: გავლის შემდეგ კიდევ წაიკითხე წესი და იკითხე, რას უშვებს ის სინამდვილეში.
შეჩერდი, თუ ცვლილების მუშაობის ერთადერთი გზა სინტაქსის შემოწმების გამორთვაა. ეს პოლიტიკა არ არის, ეს გადატვირთვას მოლოდინში მყოფი შეფერხებაა.
აღდგენა: შეინარჩუნე ჯერ კიდევ მომუშავე სესია
შენახვამდე დარწმუნდი, რომ უფლებამოსილი ადმინისტრაციული სესია უკვე ღიაა და რომ მანქანაში შესვლის მეორე გზა არსებობს. sudoers-ის შეცდომამ შეიძლება წაგართვას მისი გასწორების უნარი, და სამუშაო მაგიდის ღილაკი ამ რისკის ფასი არ არის. თუ sudo უკვე გატეხილია, გამოიყენე სისტემის დოკუმენტირებული აღდგენის გზა და ნუ მოიგონებ საკუთარს.
sudo -n true
id
pkexec-ის მსგავსი ალტერნატივები საკუთარ ინსტალაციასა და პოლიტიკაზეა დამოკიდებული, ამიტომ ისინი გარანტირებული მეორე root მოთხოვნა არ არიან. ლოკალური ავტორიზაცია VPN-ის საიდუმლოს მიწოდებისგანაც ცალკე შეინახე: sudo წესს არ შეუძლია არარსებული საიდუმლო აგენტის გახსნა და არ აკმაყოფილებს კარიბჭის MFA-ს. გასწორების შემდეგ სცადე ჩვეულებრივი ანგარიში მხოლოდ განზრახული ოპერაციის შესრულებით, შემდეგ გამოიყენე მენეჯერის ჩვეულებრივი კონტროლი.
გადაწყვეტილება მთავრდება მაშინ, როცა შეგიძლია თქვა, რომელმა პირობამ გაამართლა sudo, რას ასახელებს წესი, რომ მთელი პოლიტიკა ანალიზდება და როგორ აღადგენდი, თუ არა. პრივილეგირებული გამშვები, რომელიც ადმინისტრაციული წვდომა გაკარგვინებს, ცუდი გარიგებაა და, როგორც წესი, თავიდან ასაცილებელი.