څنګه معلوم کړو چې کوم systemd سانډباکس ستاسو OpenVPN هک رد کړی

هک هغه وخت کار کوي چې په لاسي ډول یې د root په توګه چلوئ او بیرته راګرځوي Operation not permitted په هغه شیبه کې چې خدمت یې پیلوي. د دې دواړو چلولو ترمنځ فایل بدل شو نه؛ چاپېریال بدل شو. systemd پروسې ته کوچنی نړۍ ورکوي: لږ وړتیاوې، بل /dev, یوازې لوستلو د فایل سیستم لارې او د دندو پورتنۍ حد. ناکامي د هغې پولې په توګه ولولئ چې یوه ځانګړې عملیه یې رد کړې، نه د ماتې سکریپټ په توګه.

له هغې عملیې پیل کړئ چې رد شوې

داسې لاګ کرښه چې وایي unit ناکام شو، تاسو ته نږدې هېڅ نه وایي. ګټوره کرښه هغه غوښتنې نوم اخلي چې رد شوې: هغه د وسیلې نوډ چې نه پرانیستل شو، هغه ډایرکټري چې نه پکې ولیکل شو، هغه نوم ځای چې نه جوړ شو. د یوې لارښوونې له لمس کولو دمخه هغه غوښتنه ومومئ، ځکه هر یو بل محدودیت سره سمون لري. بیا هغه unit ولولئ چې واقعاً وچلېد، د drop-in په ګډون، نه هغه فایل چې بسته راوړی.

لاندې پوښتنه د برخې لار، drop-in ډایرکټري او هغه ځانګړنې چاپوي چې د وسیلې یا فایل سیستم رد لپاره مهمې دي. مخکې له دې چې پرېکړه وکړئ کومه پوله اړوند ده، ټولې ولولئ:

systemctl show "[email protected]" -p FragmentPath -p DropInPaths -p PrivateDevices -p DevicePolicy -p DeviceAllow -p ProtectHome -p ProtectSystem -p TasksMax
journalctl -u "[email protected]" -b --no-pager | grep -iE 'operation not permitted|permission denied|cannot open|failed'

په هغه بلاک کې هېڅ نه لیکل کېږي. که رد شوې غوښتنه په ژورنال کې نه وي، د لارښوونو اټکل کولو پرځای د یو چلولو لپاره د کلاینټ تفصیل لوړ کړئ. روانه پروسه ثابتوي چې unit پیل شو، نه دا چې هک اړینو واکونو سره وچلېد.

نوم ځای ته د mount هغه حقونه غواړي چې TUN وسیله یې هېڅکله نه کاروي

دوه عملیې چې په یوه هک کې ورته ښکاري، بېل د اجازې پروفایل لري. /dev/net/tun پرانیستل او انټرفیس جوړول د شبکې ادارې او هغه نوډ ته لاسرسي ته اړتیا لري. نوم لرونکي شبکه یي نوم ځای جوړول هم mount کار ته اړتیا لري، ځکه د نوم ځای وسیله نوی /sys لید mount کوي او د حالت ډایرکټري په خپل ځای تړي. پورته بهیر کلاینټ unit د mount اداره په قصدي ډول د خپلې پولې ټولګې څخه بهر پرېږدي، نو د نوم ځای ګام رد کېږي، په داسې حال کې چې تونل خپله به کار کړی وي.

نو د وسیلې نوډ ورکول سکریپټ نه ژغوري. د وسیلې اجازه یوې پوښتنې ته ځواب وایي، ایا دا پروسه دا نوډ پرانیستلی شي، او د نوم ځای پوښتنه بله ده. مخکې له دې چې څه پراخ کړئ، ناکامه غوښتنه د هغې وړتیا سره سمه کړئ.

ستاسو په shell کې ازموینه هغه ټولې وړتیاوې په میراث اخلي چې بې حده root لري، او unit هغه اخلي چې د هغې پولې ټولګې ساتلې. هغه دوه چلول بېلې تجربې دي حتی کله چې باینري یو شان وي.

وسیلې، خوندي لارې او د دندو پورتنۍ حدود

کله چې رد شوې عملیه معلومه شوه، درې لارښوونې ډلې ډېری ناکامۍ څرګندوي. د وسیلو لاسرسي کنټرولوي PrivateDevices, کوم چې /dev له لږ تر لږه جعلي وسیلو ټولګې سره بدلوي، او DevicePolicy سره DeviceAllow, کوم چې پرېکړه کوي cgroup څه اجازه ورکوي. /dev/net/tun د هغې لږ تر لږه ټولګې برخه نه ده، نو PrivateDevices=yes لرونکی unit یې نه شي پرانیستلی، هر څه چې د وسیلو پالیسي ووایي.

د فایل سیستم ساتنه دویمې پوښتنې ته ځواب وایي. ProtectHome=yes جوړوي /home, /root او /run/user بې لاسرسي، او ProtectSystem=full جوړوي /usr, /boot او /etc یوازې لوستلو. نو هغه هک چې د خپل کنفیګریشن فایل ترڅنګ لیکي، ستاسو په shell کې کار کوي او د unit لاندې ناکامېږي، د ورکو وړتیا په څېر د اجازې هماغه بڼه سره. لیکل کېدونکی انپټ هغې لارې ته یوسئ چې پالیسي یې اجازه ورکوي، یا یوه تنګه ReadWritePaths= ننوتنه اضافه کړئ.

د سرچینو حدود درېیمه ډله ده، او ترټولو لږ څرګنده. TasksMax= محدودوي چې unit څو دندې جوړولی شي، او د فایل ډیسکریپټر حد د socket او لاسنیو لپاره هماغسې چلند کوي. هغه ځای پرځای کول چې له حد څخه وده کړې، د اجازې تېروتنې پرځای د سرچینې تېروتنې سره ناکامېږي، او له همدې امله دقیق پیغام لا هم مهم دی.

د نوم ځای ګام له هک څخه وباسئ

هغه چمتووالی چې هغه واک غواړي چې کلاینټ یې نه باید ولري، خپل unit ته اړوند دی. هغه oneshot چې د کلاینټ دمخه چلېږي، خپله پایله ساتي او د اړیکې دمخه ترتیب شوی، د نوم ځای ګام ته هغه څه ورکوي چې ورته اړتیا لري، پرته له دې چې هغه حقونه د تونل پروسې ته وسپاري. بیا کلاینټ هغه unit ته اشاره کوي، نه دا چې سکریپټ له خپل up هک څخه وبولي.

لاندې کالب د پیل بڼه ده، نه هغه څه چې نالوستل شوي تطبیق شي. چمتووالی هغه ځای ساتي چې واک هلته ژوند کوي او د تونل unit نه لمسوي:

# /etc/systemd/system/[email protected]
[Unit]
Description=Namespace preparation for %i
Before=openvpn-client@%i.service
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/local/sbin/netns-up.sh %i
CapabilityBoundingSet=CAP_NET_ADMIN CAP_SYS_ADMIN
[Install]
WantedBy=multi-user.target

ترتیب د بسته شوي unit د سمون پرځای د drop-in سره اضافه کړئ، ترڅو تازه کول ستاسو بدلون په خاموشۍ ونه غورځوي. ډایرکټري د نمونې نوم سره تړلې ده، نو دویم پروفایل خپل فایل ته اړتیا لري:

sudo mkdir -p /etc/systemd/system/[email protected]
sudo tee /etc/systemd/system/[email protected]/10-namespace.conf >/dev/null <<'CONF'
[Unit]
[email protected]
[email protected]
CONF
sudo systemctl daemon-reload

له بدلون وروسته هماغه غوښتنه تکرار کړئ

ترمیم یوازې هغه وخت تاییدېږي چې هماغه غوښتنه بله پایله ورکړي. دواړه unit بیا پیل کړئ، هغه عملیه چې ناکامه شوه ترسره کړئ، او پایله یې له هغې ژورنال کرښې سره پرتله کړئ چې له بدلون دمخه مو خوندي کړې وه. هغه unit چې پیلېږي په داسې حال کې چې هک نور هېڅکله نه چلېږي، ترمیم نه دی.

لاندې ترتیب پرتله امانت ساتي، ځکه چې د unit رنګ نه، بلکې رد شوې غوښتنه ګوري. د هغې پایلې د بدلون دمخه نیول شوې ژورنال کرښې ترڅنګ خوندي کړئ:

sudo systemctl restart "[email protected]" "[email protected]"
systemctl status "[email protected]" --no-pager
journalctl -u "[email protected]" -b --no-pager | grep -c 'Operation not permitted'
ip -brief addr show tun0

د وروستۍ کرښې لوستلو پرځای ردونه وشمېرئ، ځکه هک کېدای شي ناکام شي، بیا هڅه وکړي او بریالی شي، او یوازې شمېر ښیي چې پوله ښویېدلې که نه. په drop-in کې یادښت پرېږدئ چې هغه لارښوونه او لامل نوموي چې تاسو یې سست کړې، ځکه راتلونکی تازه کول ستاسو کنفیګریشن د بستې له ډیفالټ سره پرتله کوي. هغه unit چې یوازې د هرې ساتنې له بندولو وروسته پیلېږي، سم شوی نه دی.