◉

systemd बिल्डर

सुरक्षित सर्विस यूनिट बनाएँ

विवरणExecStartसर्विस उपयोगकर्ताकार्य निर्देशिका

परिणाम.service

[Unit]
Description=Otho worker
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=otho
WorkingDirectory=/opt/otho
ExecStart=/opt/otho/bin/worker
Restart=on-failure
RestartSec=5s
NoNewPrivileges=true
PrivateTmp=true
ProtectSystem=strict
ProtectHome=true

[Install]
WantedBy=multi-user.target

परिचय

systemd बिल्डर एक सर्विस यूनिट (.service फ़ाइल) बनाता है जिसमें ऐसे हार्डनिंग विकल्प होते हैं जो भूलना आसान है: गैर-root उपयोगकर्ता, NoNewPrivileges, PrivateTmp, ProtectSystem=strict और ProtectHome।

systemd आपको यह बताने देता है कि एक सेवा क्या छू सकती है। बनी यूनिट पृष्ठभूमि worker, agent या किसी लंबे समय तक चलने वाली प्रक्रिया के लिए एक बचाव योग्य प्रारंभिक बिंदु है।

उद्देश्य

नाम, कमांड, उपयोगकर्ता और कार्य निर्देशिका से सिंटैक्टिक रूप से सही .service यूनिट बनाना।
आधार हार्डनिंग लागू करना: समर्पित उपयोगकर्ता, विफलता पर पुनः आरंभ, कोई नया विशेषाधिकार नहीं, निजी /tmp और केवल-पठनीय सिस्टम पथ।
यूनिट को पढ़ने योग्य रखना ताकि प्रशासक तैनाती से पहले उसे समायोजित कर सके।

इनपुट

विवरण (मुक्त पाठ)।
ExecStart — निष्पादन योग्य का पूर्ण पथ।
सर्विस उपयोगकर्ता — वह अन-विशेषाधिकार प्राप्त खाता जिसके अंतर्गत सेवा चलती है।
कार्य निर्देशिका (वैकल्पिक)।

यह कैसे काम करता है

उपकरण तीन अनुभाग जोड़ता है। [Unit] विवरण घोषित करता है और सेवा को network-online.target के बाद क्रमित करता है। [Service] Type=simple, उपयोगकर्ता और कार्य निर्देशिका, ExecStart और Restart=on-failure को 5 सेकंड की देरी के साथ सेट करता है।

हार्डनिंग निर्देश इस प्रकार हैं: NoNewPrivileges=true setuid बाइनरी के माध्यम से नए विशेषाधिकार प्राप्त करना रोकता है; PrivateTmp=true सेवा को अपना /tmp देता है; ProtectSystem=strict पूरे फ़ाइलसिस्टम को केवल-पठनीय बनाता है सिवाय स्पष्ट रूप से अनुमत पथों के; ProtectHome=true /home, /root और /run/user छिपाता है।

[Install] WantedBy=multi-user.target घोषित करता है ताकि यूनिट systemctl enable से सक्षम हो सके।

परीक्षण योग्य उदाहरण

आज़माएँ — विश्लेषण आपके ब्राउज़र में स्थानीय रूप से चलता है।

उदाहरण

विवरण: Otho worker
ExecStart:  /opt/otho/bin/worker
उपयोगकर्ता: otho
निर्देशिका: /opt/otho

अपेक्षित आउटपुट

[Unit]
Description=Otho worker
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=otho
WorkingDirectory=/opt/otho
ExecStart=/opt/otho/bin/worker
Restart=on-failure
RestartSec=5s
NoNewPrivileges=true
PrivateTmp=true
ProtectSystem=strict
ProtectHome=true

[Install]
WantedBy=multi-user.target

आउटपुट पढ़ना

आउटपुट को /etc/systemd/system/<नाम>.service के रूप में सहेजें, फिर sudo systemctl daemon-reload और sudo systemctl start <नाम> चलाएँ।
यदि सेवा को सिस्टम पथों में लिखना है, तो ProtectSystem=strict रोकेगा — ReadWritePaths जोड़ें या लिखने योग्य डेटा कार्य निर्देशिका के अंतर्गत रखें।
यूनिट एक टेम्पलेट है: कार्यभार के अनुसार TimeoutStartSec, संसाधन सीमाएँ (MemoryMax, CPUQuota) और capabilities (CapabilityBoundingSet) समायोजित करें।

जोखिम

नेटवर्क पहुँच के साथ root के रूप में सेवा चलाना सबसे जोखिम भरा डिफ़ॉल्ट है; बनी यूनिट इसे टालती है, लेकिन जाँचें कि आपका ExecStart बाइनरी root के स्वामित्व में है।
ProtectSystem=strict उन सेवाओं को तोड़ सकता है जो अपनी कार्य निर्देशिका के बाहर लिखती हैं — उत्पादन से पहले परीक्षण करें।
Restart=on-failure उन क्रैश से नहीं बचाता जो 0 निकास कोड के साथ समाप्त होते हैं; महत्वपूर्ण workers के लिए Restart=always पर विचार करें।

सीमाएँ

उपकरण फ़ाइल बनाता है; यह परीक्षण नहीं कर सकता कि आपका निष्पादन योग्य शुरू होता है या उसकी अनुमतियाँ सही हैं।
यह socket activation, timers या जटिल निर्भरता ग्राफ नहीं बनाता।
हार्डनिंग आधार है — वास्तविक समीक्षा में capabilities, seccomp और नेटवर्क namespace शामिल होने चाहिए।

आधिकारिक संदर्भ

FAQ

हर सेवा के लिए समर्पित उपयोगकर्ता क्यों?

समर्पित अन-विशेषाधिकार प्राप्त उपयोगकर्ता समझौता की गई सेवा की क्षमता सीमित करता है: वह दूसरों की फ़ाइलें नहीं पढ़ सकती और न ही अपने पथों के बाहर लिख सकती है। Root केवल उन्हीं सेवाओं के लिए आरक्षित होना चाहिए जिन्हें वास्तव में ज़रूरत है।

NoNewPrivileges=true क्या करता है?

यह सेवा और उसकी संतानों को setuid बाइनरी या समान तंत्रों के माध्यम से विशेषाधिकार प्राप्त करने से रोकता है, भले ही ऐसी बाइनरी सिस्टम पर मौजूद हों।

ProtectSystem=strict क्या है?

यह स्पष्ट रूप से अनुमत पथों को छोड़कर पूरे फ़ाइलसिस्टम को सेवा के लिए केवल-पठनीय बनाता है। यह सबसे मज़बूत ProtectSystem स्तर है और उन सेवाओं के साथ अच्छा चलता है जो केवल अपनी कार्य निर्देशिका या /tmp में लिखती हैं।