მივცეთ OpenVPN-ს CAP_NET_ADMIN root-ის მიცემის გარეშე
ერთეულს, რომელიც არაპრივილეგირებული მომხმარებლით იწყება, მაინც სჭირდება სწორი შესაძლებლობების ნაკრები. შეამოწმეთ ერთეული, ცოცხალი პროცესი და exec-ის საზღვარი ამ თანმიმდევრობით.
სერვისი იწყება, ჟურნალი წუწუნებს, რომ tun მოწყობილობას ვერ ხსნის, და მარშრუტები არასდროს ჩნდება. გაუშვით capsh --print თქვენს shell-ში და cap_net_admin სწორედ იქ არის, რაც წარუმატებლობას შეუძლებლად აჩენს. რაც განსხვავდება თქვენს shell-სა და ერთეულს შორის, არის პრივილეგიათა გადასვლა და არა ბირთვის სურვილი, მოგცეთ შესაძლებლობა. გაიარეთ ქვემოთ მოცემული ოთხი შემოწმება რიგრიგობით და გაჩერდით პირველზე, რომელიც ხსნის სხვაობას.
გამოყავით ნაკლული შესაძლებლობა დამალული მოწყობილობისგან
ორი წარუმატებლობა ჟურნალის სტრიქონიდან ერთნაირად გამოიყურება. პროცესი CAP_NET_ADMIN-ის გარეშე ვერ შექმნის ან ვერ დააკონფიგურირებს გვირაბის ინტერფეისს, ხოლო პროცესი, რომლის sandbox-იც მალავს /dev/net/tun-ს, საერთოდ ვერ გახსნის მას. შესაძლებლობების დამატება მეორე შემთხვევას არ გამოასწორებს.
სანამ რამეს შეცვლით, შეამოწმეთ, არსებობს თუ არა მოწყობილობა სერვისის სახელთა სივრცეში. PrivateDevices=yes გავრცელებული გამაგრების სტრიქონია, რომელიც tun-ის კვანძს მთლიანად შლის, ხოლო შემზღუდველი ProtectSystem-ს შეუძლია კონფიგურაციის გზა მხოლოდ-წაკითხვადი გახადოს ისე, რომ ნებართვის შეცდომად იკითხება. ორივე ქმნის ჟურნალის სტრიქონებს, რომლებიც გვირაბს ახსენებს, ამიტომ ბრალს შესაძლებლობებს აყენებენ. ჯერ დაადასტურეთ, რომ კვანძი არსებობს და იხსნება, შემდეგ გადადით შემდეგზე.
იცოდეთ, რომელ შესაძლებლობათა ერთობლიობას უყურებთ
Linux ინახავს ნებადართულ, ეფექტურ, მემკვიდრეობით, შემზღუდველ და ატმოსფერულ კრებულებს, და სწორედ ატმოსფერული კრებული გადაურჩება არა-root მომხმარებლის exec-ს. ბინარზე არსებულ ფაილურ შესაძლებლობებს exec-ის დროს შეუძლია გადასცეს ნებადართული და ეფექტური უფლებები, მაგრამ მხოლოდ მანამ, სანამ ჯაჭვში რამე ამ გადაცემას არ დაბლოკავს.
აქ sudo ხალხს შეცდომაში შეჰყავს. sudo -u-ის გავლით გაშვებული ბრძანება იწყებს პრივილეგიათა ახალ გადასვლას და ატმოსფერული კრებული ქრება, ამიტომ იგივე შემოწმება, რომელიც root-ად წარმატდება, იქ მარცხდება. სერვისების მმართველი კიდევ სხვა გადასვლაა და ატმოსფერულს არაფერს აძლევს, თუ ერთეული ასე არ ამბობს.
მიეცით შესაძლებლობა ერთეულში და არა გადაფუთვაში
მინიმალური სერვისის განყოფილება გვირაბისთვის, რომელსაც მოწყობილობის შექმნა და მარშრუტების დაყენება სჭირდება, ასე გამოიყურება.
[Unit]
Description=OpenVPN client, office profile
After=network-online.target
[Service]
Type=notify
User=openvpn
Group=openvpn
NoNewPrivileges=yes
AmbientCapabilities=CAP_NET_ADMIN
CapabilityBoundingSet=CAP_NET_ADMIN
ExecStart=/usr/sbin/openvpn --config /etc/openvpn/office.confAmbientCapabilities უფლებას ატმოსფერულ კრებულში დებს პროცესის დაწყებამდე, ხოლო CapabilityBoundingSet ხელს უშლის პროცესს ამ სიის გარეთ რამე ჰქონდეს. NoNewPrivileges=yes ბლოკავს პრივილეგიების მოპოვებას setuid-ით ან ფაილური შესაძლებლობებით, მაშინ როცა ერთეულის მიერ ცხადად მოცემული შესაძლებლობა კვლავ მოქმედებს. დაამატეთ CAP_NET_BIND_SERVICE მხოლოდ მაშინ, როცა სერვისმა დაბალი პორტი უნდა შეკრას, და არასდროს დაამატოთ CAP_SYS_ADMIN მხოლოდ იმიტომ, რომ ფორუმის თემმა ასე გააკეთა.
თუ ერთეული ბინარს sudo-ში ახვევს, მოაშორეთ გადაფუთვა. systemd უკვე იყენებს User=-ს და სწორედ ეს დამატებითი ფენაა ატმოსფერული კრებულის ცარიელობის ყველაზე სავარაუდო მიზეზი.
შეამოწმეთ ცოცხალ პროცესზე და არა ერთეულის ფაილზე
წაიკითხეთ, რა გამოიყენა მმართველმა სინამდვილეში, შემდეგ წაიკითხეთ პროცესი, რომელიც მან შექმნა.
unit=openvpn-client@office
systemctl show -p User -p AmbientCapabilities "$unit"
systemctl show -p MainPID --value "$unit" | xargs -r getpcaps
grep -E '^Cap(Eff|Amb)' /proc/$(systemctl show -p MainPID --value "$unit")/statusთუ ერთეული შესაძლებლობას ჩამოთვლის და CapEff-ს ის მაინც არ აქვს, რომელიმე drop-in ანაცვლებს პარამეტრს ან ExecStartPre საფეხური ცვლის გარემოს. სანამ ძირითად ფაილს უფლებამოსილად მიიჩნევთ, მოძებნეთ ერთეულის სახელი drop-in საქაღალდეებში, რადგან გვიან მოსული ფაილი ჩუმად იმარჯვებს. თუ ერთეულიც და პროცესიც შესაძლებლობას აჩვენებენ და გვირაბი მაინც ვერ მუშაობს, დაუბრუნდით მოწყობილობისა და გზის შემოწმებებს და ნუ გააფართოვებთ შემზღუდველ კრებულს. მისი გაფართოება მალავს ნამდვილ მიზეზს და სერვისს უფრო პრივილეგირებულს ტოვებს, ვიდრე იყო.
უმჯობესია პრივილეგიები გაუშვათ გაშვების შემდეგ
OpenVPN შესაძლებელია დაიწყოს პრივილეგიებით და შემდეგ თავისივე user და group პარამეტრებით გადავიდეს არაპრივილეგირებულ ანგარიშზე, ხოლო persist-key და persist-tun გვირაბს შემდგომშიც გამოსადეგს ინახავენ. ასეთი წყობა ავიწროებს იმ ფანჯარას, რომელშიც პროცესს უფლებები აქვს, და ხშირად უფრო მართებულია, ვიდრე მთელი დემონის არაპრივილეგირებულად, მუდმივი შესაძლებლობებით გაშვება.
რომელი მოდელიც არ უნდა აირჩიოთ, გადატვირთეთ ერთეული და გაიმეორეთ შემოწმებები გადატვირთვის შემდეგ, რადგან სერვისი, რომელიც ინტერაქტიული root shell-იდან მუშაობს და ჩატვირთვისას მარცხდება, ჩვეულებრივ შესაძლებლობის, მოწყობილობის ან ფაილის ნებართვის განსხვავებაა. ჩაწერეთ ერთეულის პარამეტრები პროცესის შესაძლებლობათა გამოსავლის გვერდით, რომ შემდეგმა მიმომხილველმა დაინახოს, გადაძრო თუ არა საზღვარი პაკეტის განახლებამ ან drop-in-მა.