Кои Linux способности му се потребни на вашиот VPN процес?
Поставувањето на интерфејсот, рутите, пристапот до уредите и обичните сокети се одделни привилегии. Именувајте ја операцијата што не успеа пред да доделите CAP_NET_ADMIN.
VPN демонот бара привилегирани мрежни операции, иако обичните апликации отвораат излезни сокети без никаква привилегија. Токму во овој јаз започнуваат повеќето грешки со способностите: некој гледа грешка со дозвола, доделува целото множество, и услугата работи од причини што никој подоцна не може да ги објасни. Прегледот подолу започнува од операцијата што не успеа, ја поврзува со едно овластување и потоа го проверува контекстот во кој процесот навистина работи. Работењето како неограничен root е валиден одговор за некои распоредувања, но треба да биде одлука, а не стандардна вредност.
Започнете од операцијата што не успеа
Прочитајте ја грешката пред да прочитате упатство. „Операцијата не е дозволена“ при промена на интерфејс, одбивање да се отвори јазол на уред и неуспешно bind на низок порт се три различни проблеми со три различни дозволи. Ако процесот стартува и не успее само при првата промена на рута, тоа исто така кажува дека креирањето на интерфејсот веќе успеало, што одговорот значително го стеснува.
Репродуцирајте ја грешката со запрена услуга, потоа стартувајте ја во преден план под истиот корисник ако имплементацијата тоа го дозволува. Грешка што ја гледате е подобра од линија во дневникот што треба да ја погодувате, и ја прави јасна разликата помеѓу проблем со способности и одбивање од SELinux или AppArmor.
Поврзете ја секоја операција со едно овластување
Табелата е почетна карта, не замена за документацијата на имплементацијата:
| Operation | Usual authority | Watch for |
|---|---|---|
| Create or configure tun/tap | CAP_NET_ADMIN in the relevant namespace | Creating the device and opening it are separate steps |
| Add routes, rules, firewall entries | CAP_NET_ADMIN | Same capability, different namespace than you think |
| Open /dev/net/tun | Device permissions, not a capability | Group membership or a udev rule may be enough |
| Raw sockets | CAP_NET_RAW | Needed by some user-space tunnel implementations |
| Bind a port below 1024 | CAP_NET_BIND_SERVICE | Irrelevant for most modern tunnel ports |
Двата реда во таа табела се тие што луѓето ги мешаат. Отворањето на /dev/net/tun е прашање на дозволи за датотека; барањето од јадрото да го конфигурира тоа што сте го отвориле е прашање на способности. Доделувањето на CAP_NET_ADMIN не го поправа јазолот на уред што вашиот корисник на услугата не може да го прочита, а поправањето на јазолот не ви дава овластување за рути. Проверете ги двете пред да смените било кое.
Јадрениот WireGuard и програмите за тунели во кориснички простор исто така немаат идентични барања. Патеката на јадрениот модул конфигурира постоечки интерфејс преку netlink, додека имплементацијата во кориснички простор може да бара и уредот и, за некои транспорти, сурови сокети.
Прочитајте го контекстот: услуга, контејнер или школка
Способност во мрежниот именски простор на домаќинот може да влијае многу повеќе од истата операција во намерно изолиран стек. Контејнерското извршно опкружување обично започнува со намалено множество граници; додавањето на NET_ADMIN на контејнер што ја дели мрежата на домаќинот е многу поголема дозвола отколку додавање на оној со сопствен мрежен именски простор и без монтирања од домаќинот.
За systemd единиците читајте што навистина се применува, а не што навидум вели единицата: systemctl show -p CapabilityBoundingSet -p AmbientCapabilities ги известува ефективните вредности, кои може да ги постави drop-in што сте го заборавиле. Побарајте ја ефективната вредност, никогаш предвидената. Ambient способностите се важни зашто услуга што не е root ги губи способностите преку exec без нив.
Земете ја поддржаната поставеност на пакетот или сликата како основа. Не додавајте дозволи за сурови сокети или привилегиран режим само затоа што друго упатство ги навело за друг алат; тоа размислување не пренесува ништо и ве чини изолацијата што сте ја платиле. Кога се сомневате, не доделувајте ништо и прочитајте ги белешките на имплементацијата за точната операција што ви треба.
Гледајте што се случува откако ќе паднат привилегиите
Многу демони започнуваат привилегирано, го конфигурираат интерфејсот, потоа преминуваат на непривилегиран корисник и го задржуваат тунелот. Од тој момент процесот повеќе не може да додаде рута, да препише правило на огнено ѕид или да отвори нов привилегиран уред, што е во ред сѐ додека повторното поврзување не побара токму тоа. Подоцнежните читања на датотеки и извршување на куки може да не успеат од истата причина.
Тестирајте го целиот животен циклус, а не првата секунда: стартување, обновување или повторно поврзување и чистење при запирање. Првото успешно креирање на интерфејсот не докажува дека секоја подоцнежна привилегирана операција сѐ уште работи, а грешката обично се појавува часови подоцна во продукција.
Имплементациите што го држат тунелот отворен при промена на корисник обично тоа го поврзуваат со опции за зачувување на тунелот и клучевите. На страната на systemd, еквивалентното прашање е дали множеството способности на единицата ја преживува промената на корисник што сте ја конфигурирале.
Запишете ја дозволата и нејзината причина
Запишете ја точната дозвола, операцијата што ја овозможува и грешката што ја исправи. Еден ред во белешките за распоредување — «CAP_NET_ADMIN во мрежниот именски простор на единицата, потребно за промени на рутите по повторно поврзување» — е доволен за да го спречи следниот човек повторно да ја прошири дозволата.
Потоа прочитајте го ефективното множество повторно по секое надградување. Добавувачите додаваат функции, сликите ги менуваат стандардните вредности, и способност што минатата година беше непотребна може да стане носечка без никој да забележи.