OpenVPN-ə root vermədən CAP_NET_ADMIN vermək

Xidmət başlayır, jurnal tun cihazını aça bilmədiyindən şikayət edir və marşrutlar heç vaxt görünmür. Öz shell-inizdə capsh --print işə salın və cap_net_admin dərhal oradadır, bu da nasazlığı qeyri-mümkün kimi göstərir. Shell-inizlə unit arasındakı fərq imtiyaz keçididir, nüvənin imkanı vermək istəyi deyil. Aşağıdakı dörd yoxlamanı sıra ilə keçin və boşluğu izah edən ilk yoxlamada dayanın.

İtkin imkanı gizli cihazdan ayırın

İki nasazlıq jurnal sətrindən eyni görünür. CAP_NET_ADMIN olmayan proses tun interfeysini yarada və ya qura bilməz, sandbox-u /dev/net/tun gizlədən proses isə onu ilk növbədə aça bilməz. İmkan əlavə etmək ikinci halı düzəltməyəcək.

Heç nəyi redaktə etməzdən əvvəl cihazın xidmətin adlar məkanında mövcud olub-olmadığını yoxlayın. PrivateDevices=yes tun qovşağını tamamilə silən geniş yayılmış sərtləşdirmə sətridir və məhdudlaşdırıcı ProtectSystem konfiqurasiya yolunu icazə xətası kimi oxunan şəkildə yalnız-oxunaqlı edə bilər. Hər ikisi tuneldən bəhs edən jurnal sətirləri yaradır, buna görə də günah imkanların üzərinə atılır. Əvvəlcə qovşağın mövcud və açıla bilən olduğunu təsdiqləyin, sonra davam edin.

Hansı imkan dəstinə baxdığınızı bilin

Linux icazəli, effektiv, miras alına bilən, məhdudlaşdırıcı və ambient dəstlərini saxlayır və qeyri-root istifadəçinin exec əməliyyatından sağ çıxan ambient dəstidir. Binar fayl üzərindəki fayl imkanları exec zamanı icazəli və effektiv hüquqları ötürə bilər, ancaq zəncirdə heç nə bu ötürməni bloklamadıqca.

Burada sudo insanları yanıldır. sudo -u vasitəsilə işlədilən əmr yeni imtiyaz keçidi başladır və ambient dəsti yox olur, ona görə root kimi uğur qazanan eyni yoxlama orada uğursuz olur. Xidmət meneceri yenə başqa keçiddir və unit bunu deməzsə, heç bir ambient imkan vermir.

İmkanı wrapper-də deyil, unit-in içində verin

Cihaz yaratmalı və marşrutlar quraşdırmalı tunel üçün minimal xidmət bölməsi belə görünür.

[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.conf

AmbientCapabilities proses başlamazdan əvvəl hüququ ambient dəstinə qoyur və CapabilityBoundingSet prosesin bu siyahıdan kənarda heç nə saxlamamasını təmin edir. NoNewPrivileges=yes setuid və ya fayl imkanları ilə imtiyaz qazanmanı bloklayır, unit-in açıq şəkildə verdiyi imkan isə yenə də qüvvədə qalır. CAP_NET_BIND_SERVICE yalnız xidmət aşağı port bağlamalı olduqda əlavə edin və CAP_SYS_ADMIN heç vaxt bir forum mövzusu belə etdi deyə əlavə etməyin.

Unit binari sudo içində sarıyırsa, sarğı çıxarın. systemd artıq User= tətbiq edir və bu əlavə qat ambient dəstinin boş olmasının ən ehtimal olunan səbəbidir.

Unit faylına deyil, canlı prosesə qarşı yoxlayın

Menecerin həqiqətən tətbiq etdiyini oxuyun, sonra yaratdığı prosesi oxuyun.

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

Unit imkanı sadalayır və CapEff hələ də onu göstərmirsə, bir drop-in parametri üstələyir və ya ExecStartPre addımı mühiti dəyişir. Əsas faylın səlahiyyətli olduğunu güman etməzdən əvvəl drop-in qovluqlarında unit adını axtarın, çünki sonrakı fayl səssizcə qalib gəlir. Həm unit, həm də proses imkanı göstərir və tunel yenə də uğursuz olursa, məhdudlaşdırıcı dəsti genişləndirmək əvəzinə cihaz və yol yoxlamalarına qayıdın. Onu genişləndirmək əsl səbəbi gizlədir və xidməti əvvəlkindən daha imtiyazlı qoyur.

Başlamadan sonra imtiyazları buraxmağı üstün tutun

OpenVPN öz user və group seçimləri ilə imtiyazlı başlayıb sonra imtiyazsız hesaba keçə bilər, persist-key və persist-tun isə tuneli sonradan istifadə edilə bilən saxlayır. Bu quruluş prosesin hüquq saxladığı pəncərəni daraldır və çox vaxt bütün daemon-u daimi imkanlarla imtiyazsız başlatmaqdan daha uyğundur.

Hansı modeli seçsəniz də, unit-i yenidən başladın və yoxlamaları reboot-dan sonra təkrarlayın, çünki interaktiv root shell-dən işləyib boot zamanı uğursuz olan xidmət adətən imkan, cihaz və ya fayl icazəsi fərqidir. Unit parametrlərini prosesin imkan çıxışının yanında qeyd edin ki, növbəti rəyçi paket yeniləməsinin və ya drop-in-in sərhədi tərpədib-tərpətmədiyini görə bilsin.