VPN जडानपछिको कार्यलाई डेमनको रूपमा नभई प्रयोगकर्ताको रूपमा चलाउनुहोस्

VPN डेमनका जडान hook हरू डेमनको रूपमा चल्छन्, र सामान्यतया यसको अर्थ तिनीहरू root को रूपमा चल्छन्। ती hook मध्ये एउटाले कसैको होम डाइरेक्टरीमा लेख्दा वा डेस्कटप सहायक पुनः सुरु गर्दा, तपाईंले नेटवर्क घटनालाई कुनै पनि स्थानीय प्रयोगकर्ताको रूपमा कार्य गर्ने क्षमता दिनुभएको छ। सामान्य छोटो बाटो, अर्थात् वातावरण चरबाट प्रयोगकर्ता नाम पढेर अगाडि पठाउनु, यसलाई सुधार्दैन। यसले कार्यलाई पुनः लेबल गर्छ तर कुन खाताले यसलाई कार्यान्वयन गर्छ भन्ने बदल्दैन। काम गर्ने कुरा तीन भागको हस्तान्तरण हो, जसमा विशेषाधिकार प्राप्त चरणले के भयो भन्छ र अलग इकाइले सही पहिचानमा कार्य गर्छ।

वातावरणमा रहेको प्रयोगकर्ता नाम पहिचान स्विच होइन

युनिक्सले प्रक्रियाले के छुन सक्छ भन्ने उसको प्रभावकारी प्रयोगकर्ता ID बाट निर्धारण गर्छ, उसको वातावरणका स्ट्रिङबाट होइन। USER=alice सेट गर्नु वा LOGNAME निर्यात गर्नुले लापरवाह सफ्टवेयरले आफ्नो आउटपुटमा के छाप्छ भन्ने बदल्छ; फाइल स्वामित्व जाँचमा यसले केही बदल्दैन। त्यो चर सेट गरिएको अवस्थामा root को रूपमा चल्ने hook ले अझै root कै रूपमा Alice का फाइलहरू खोल्छ।

नामहरू पनि एउटै नाम होइनन्। टाढाको पहुँच लगइन, स्थानीय युनिक्स खाता र प्रमाणपत्रको साझा नाम तीन पहिचानकर्ता हुन् जो प्रायः मिल्छन् र कहिलेकाहीं मिल्दैनन्। a.smith को रूपमा प्रमाणीकरण गर्ने प्रयोगकर्ताको स्थानीय खाता नै नहुन सक्छ, वा डाइरेक्टरी सेवामार्फत asmith मा म्याप हुन सक्छ। एउटै स्ट्रिङले तीनै भूमिका निर्वाह गर्छ भन्ने मान्ने कुनै पनि डिजाइन पहिलो ठेकेदारमै भाँचिन्छ।

त्यसैले पहिलो प्रश्न «कुन प्रयोगकर्ता जोडिएको छ» होइन, तर «कुन स्थानीय खातालाई यो कार्य गर्न अनुमति छ» हो। यसको उत्तर आफ्नै खाता डाटाबेसबाट दिनुहोस्, क्लाइन्टले पठाएकोबाट होइन:

id -u alice
getent passwd alice | cut -d: -f1,3,6
stat -c '%U:%G %a %n' /home/alice/.local/state/vpn-status.json

तेस्रो आदेश त्यो हो जुन मानिसहरूले छोड्छन्। यदि लक्ष्य फाइल root को स्वामित्वमा छ किनभने अघिल्लो hook ले त्यो बनायो, तब राम्ररी कन्फिगर गरिएको प्रयोगकर्ता कार्य systemd समस्याजस्तो देखिने, तर नभएको अनुमति त्रुटिले असफल हुन्छ।

डेमन आफ्नै ठाउँमा रहन्छ

VPN सेवाको आफ्नै User= लाई Alice मा बदल्नु गलत लिभर हो। यसले डेमनले इन्टरफेस कसरी बाइन्ड गर्छ, कुञ्जी कसरी पढ्छ, आफ्नो स्थिति फाइल कसरी लेख्छ र मार्ग कसरी व्यवस्थापन गर्छ भन्ने बदल्छ, र त्यो सम्पूर्ण जोखिम चलिरहेको इकाइमा सार्छ। डेमनलाई आफ्ना विशेषाधिकार चाहिन्छ; पछिको कार्यलाई चाहिँदैन।

इकाइलाई छुनुअघि त्यसले वास्तवमा के गरिरहेको छ हेर्नुहोस्। दुई आदेशले तपाईंलाई कार्यान्वयन पहिचान र लागू रहेका ठ्याक्कै आदेश रेखाहरू बताउँछन्, ओभरराइडले थपेको सबै सहित:

systemctl show -p User -p Group -p ExecStart openvpn-server@server
systemctl cat openvpn-server@server

पूर्वनिर्धारित प्याकेज स्थापनामा डेमन root हुन्छ र --up स्क्रिप्टले त्यो उत्तराधिकारमा पाउँछ। अनुमान गर्नुको सट्टा त्यो पुष्टि गर्नुहोस्, किनभने कठोर गरिएको वितरणले यसलाई समर्पित खातामा सारेको हुन सक्छ, र हातले लेखिएको drop-in ले फरक नियम भएको र्यापरमार्फत hook चलाउन सक्छ।

तीन नामित भाग, एउटा साँघुरो ट्रिगर

मर्मतसम्भारमा टिक्ने व्यवस्थामा घटना, ट्रिगर र कार्य हुन्छन्। डेमनले नामित सत्र माथि आयो भनी जानकारी दिन्छ। ट्रिगरले त्यो सानो तथ्य स्वीकार गर्छ र एउटा निश्चित कार्य माग्छ। कार्यले छुने फाइलहरूको मालिक रहेको स्थानीय खातामुनि चल्छ। शृंखलामा केहीले पनि स्वेच्छाचारी आदेश मार्ग स्वीकार गर्दैन।

कार्य आफैं साधारण सेवा इकाइ हो, र पहिचान त्यसभित्रको एउटा निर्देश हो:

[Service]
Type=oneshot
User=alice
Group=alice
ExecStart=/usr/local/bin/refresh-vpn-status --slot %i

ध्यान दिनुहोस् कि User=alice सम्पूर्ण इकाइमा लागू हुन्छ, र systemd ले जान्नैपर्ने एउटा अपवाद अभिलेख गर्छ: + उपसर्ग भएको आदेश यसलाई वास्ता नगरी पूर्ण विशेषाधिकारसहित चल्छ। त्यो उपसर्ग एउटै विशेषाधिकार प्राप्त चरणका लागि वैध औजार हो र भर्खरै बनाइएको पृथकीकरण रद्द गर्ने सुविधाजनक मार्ग हो, त्यसैले त्यो इकाइभित्रको कुनै पनि + लाई समीक्षामा जायज ठहराउनुपर्ने कुराको रूपमा लिनुहोस्।

ट्रिगरको इनपुट न्यूनतम र गोप्य नभएको राख्नुहोस्। सत्र पहिचानकर्ता, म्याप गरिएको खाता र समयछाप सामान्यतया आवश्यक सबै हुन्। सीमापार कहिल्यै शेल टुक्रा, कार्यान्वयनयोग्य फाइलको मार्ग वा क्लाइन्टले दिएको वातावरण ब्लक पठाउनुहोस् न, किनभने प्राप्त गर्ने पक्षसँग वैध मान र इन्जेक्ट गरिएको मान छुट्याउने कुनै उपाय छैन।

वास्तवमा चलेको पहिचान प्रमाणित गर्नुहोस्

कन्फिगरेसन समीक्षा प्रमाण होइन। स्वीकृत परीक्षण जडानपछि, फाइल छोएको UID र डेमनले अझै प्रयोग गरिरहेको UID पुष्टि गर्नुहोस्:

stat -c '%U %G %y %n' /home/alice/.local/state/vpn-status.json
ps -o user=,pid=,cmd= -p "$(pgrep -o -f 'openvpn --daemon')"
systemd-run --uid=alice --pipe /usr/local/bin/refresh-vpn-status --dry-run

पहिलो लाइनले Alice र तपाईंको परीक्षण विन्डोभित्रको समयछाप देखाउनुपर्छ। दोस्रोले अझै root वा प्याकेजको सेवा खाता देखाउनुपर्छ, जसले डेमन सरेको छैन भनी प्रमाणित गर्छ। तेस्रो भनेको वास्तविक पुनःजडान कुर्नु नपरी कार्यको अनुमति परीक्षण गर्ने सबैभन्दा सस्तो उपाय हो।

यदि फाइलको मालिक Alice छ तर उसको समूह वा मोड चलाइहरूबीच बदलिएको छ भने, तर्क त्रुटि नभई UMask= वा डाइरेक्टरी अनुमतिको फरक खोज्नुहोस्। यदि समयछाप अलिकति पनि सरेन भने, ट्रिगर कहिल्यै सक्रिय भएन, र उपयोगी अर्को कदम अर्को क्लाइन्ट पुनःजडान होइन, कार्य इकाइका लागि journalctl -u हो।

जडान घटनाले अझै के प्रमाणित गर्दैन

स्थापित सुरुङ एउटा तथ्य हो। यसको अर्थ डेस्कटप सत्र खुला छ, सत्र बस पुग्न सकिन्छ, वा कार्यले चाहेको निजी स्रोत अहिले नै उपलब्ध छ भन्ने होइन। Alice को UID मुनिको oneshot इकाइसँग उनको पहिचान छ र उनको सत्रबाट केही छैन, त्यसैले ग्राफिकल बस आवश्यक पर्ने सबै कुरा समर्थित प्रयोगकर्ता-सत्र संयन्त्रमार्फत जानुपर्छ र उनी लगआउट हुँदा के हुन्छ भनी परिभाषित गर्नुपर्छ।

पुनःजडानहरू पनि दोहोरिन्छन्। रेलमा सुतेको ल्यापटपले एक घण्टामा दर्जनौं जडान घटना उत्पन्न गर्न सक्छ, र हरेक पटक एक लाइन थप्ने hook ले स्थिति फाइललाई कसैले पनि पढ्न नसक्ने लगमा बदल्छ। कार्यलाई इडेम्पोटेन्ट बनाउनुहोस्, वा सत्र-कुञ्जी भएको एउटै रेकर्ड प्रतिस्थापन गर्न दिनुहोस्।

अन्तमा, इकाइभित्रै हानिको त्रिज्या सीमित गर्नुहोस्: स्थिति डाइरेक्टरीबाहिर पढ्ने मात्र फाइलसिस्टम दृश्य, नयाँ विशेषाधिकार छैनन्, र स्पष्ट समयसीमा। डेमन र प्रयोगकर्ता कार्यबीचको पृथकीकरण आफैंमा मूल्यवान् छ, तर कार्यले तपाईंले स्वीकृत गरेको एउटै कुराबाहेक अरू केही गर्न नसक्दा त्यो धेरै बढी मूल्यवान् हुन्छ।