OpenVPN ਨੂੰ root ਦਿੱਤੇ ਬਿਨਾਂ CAP_NET_ADMIN ਦੇਣਾ

ਸੇਵਾ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ, ਲੌਗ ਸ਼ਿਕਾਇਤ ਕਰਦਾ ਹੈ ਕਿ ਇਹ tun ਜੰਤਰ ਨੂੰ ਖੋਲ੍ਹ ਨਹੀਂ ਸਕਦਾ, ਅਤੇ ਰੂਟ ਕਦੇ ਨਹੀਂ ਦਿਸਦੇ। ਆਪਣੇ ਸ਼ੈੱਲ ਵਿੱਚ capsh --print ਚਲਾਓ ਅਤੇ cap_net_admin ਉੱਥੇ ਹੀ ਹੈ, ਜਿਸ ਨਾਲ ਅਸਫਲਤਾ ਅਸੰਭਵ ਲੱਗਦੀ ਹੈ। ਤੁਹਾਡੇ ਸ਼ੈੱਲ ਅਤੇ ਯੂਨਿਟ ਵਿਚਕਾਰ ਜੋ ਫ਼ਰਕ ਹੈ ਉਹ ਵਿਸ਼ੇਸ਼ ਅਧਿਕਾਰ ਤਬਦੀਲੀ ਹੈ, ਕਰਨਲ ਦੀ ਸਮਰੱਥਾ ਦੇਣ ਦੀ ਇੱਛਾ ਨਹੀਂ। ਹੇਠਾਂ ਦਿੱਤੀਆਂ ਚਾਰ ਜਾਂਚਾਂ ਕ੍ਰਮ ਵਿੱਚ ਕਰੋ ਅਤੇ ਫ਼ਰਕ ਸਮਝਾਉਣ ਵਾਲੀ ਪਹਿਲੀ 'ਤੇ ਰੁਕੋ।

ਗੁੰਮ ਸਮਰੱਥਾ ਨੂੰ ਲੁਕੇ ਹੋਏ ਜੰਤਰ ਤੋਂ ਵੱਖ ਕਰੋ

ਲੌਗ ਲਾਈਨ ਤੋਂ ਦੋ ਅਸਫਲਤਾਵਾਂ ਇੱਕੋ ਜਿਹੀਆਂ ਦਿਸਦੀਆਂ ਹਨ। CAP_NET_ADMIN ਤੋਂ ਬਿਨਾਂ ਪ੍ਰਕਿਰਿਆ ਟਨਲ ਇੰਟਰਫੇਸ ਨਾ ਬਣਾ ਸਕਦੀ ਹੈ ਨਾ ਸੰਰਚਿਤ ਕਰ ਸਕਦੀ ਹੈ, ਅਤੇ ਜਿਸ ਪ੍ਰਕਿਰਿਆ ਦਾ ਸੈਂਡਬਾਕਸ /dev/net/tun ਲੁਕਾਉਂਦਾ ਹੈ ਉਹ ਇਸਨੂੰ ਸ਼ੁਰੂ ਵਿੱਚ ਹੀ ਖੋਲ੍ਹ ਨਹੀਂ ਸਕਦੀ। ਸਮਰੱਥਾਵਾਂ ਜੋੜਨ ਨਾਲ ਦੂਜਾ ਕੇਸ ਠੀਕ ਨਹੀਂ ਹੋਵੇਗਾ।

ਕੁਝ ਵੀ ਸੋਧਣ ਤੋਂ ਪਹਿਲਾਂ ਜਾਂਚੋ ਕਿ ਜੰਤਰ ਸੇਵਾ ਦੇ ਨਾਮ-ਥਾਂ ਦੇ ਅੰਦਰ ਹੈ ਜਾਂ ਨਹੀਂ। PrivateDevices=yes ਇੱਕ ਆਮ ਹਾਰਡਨਿੰਗ ਲਾਈਨ ਹੈ ਜੋ tun ਨੋਡ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਹਟਾ ਦਿੰਦੀ ਹੈ, ਅਤੇ ਪਾਬੰਦੀਸ਼ੁਦਾ ProtectSystem ਸੰਰਚਨਾ ਮਾਰਗ ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਸਿਰਫ਼-ਪੜ੍ਹਨਯੋਗ ਬਣਾ ਸਕਦਾ ਹੈ ਜੋ ਇਜਾਜ਼ਤ ਤਰੁੱਟੀ ਵਾਂਗ ਪੜ੍ਹਿਆ ਜਾਵੇ। ਦੋਵੇਂ ਟਨਲ ਦਾ ਜ਼ਿਕਰ ਕਰਨ ਵਾਲੀਆਂ ਲੌਗ ਲਾਈਨਾਂ ਬਣਾਉਂਦੇ ਹਨ, ਇਸ ਲਈ ਦੋਸ਼ ਸਮਰੱਥਾਵਾਂ 'ਤੇ ਪੈਂਦਾ ਹੈ। ਪਹਿਲਾਂ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਨੋਡ ਮੌਜੂਦ ਹੈ ਅਤੇ ਖੁੱਲ੍ਹ ਸਕਦਾ ਹੈ, ਫਿਰ ਅੱਗੇ ਵਧੋ।

ਜਾਣੋ ਕਿ ਤੁਸੀਂ ਕਿਹੜਾ ਸਮਰੱਥਾ-ਸਮੂਹ ਵੇਖ ਰਹੇ ਹੋ

Linux ਮਨਜ਼ੂਰ, ਪ੍ਰਭਾਵੀ, ਵਿਰਾਸਤੀ, ਸੀਮਿਤ ਅਤੇ ਪਰਿਵੇਸ਼ ਸਮੂਹ ਰੱਖਦਾ ਹੈ, ਅਤੇ ਪਰਿਵੇਸ਼ ਸਮੂਹ ਹੀ ਉਹ ਹੈ ਜੋ ਗੈਰ-root ਉਪਭੋਗਤਾ ਦੇ exec ਤੋਂ ਬਾਅਦ ਬਚਦਾ ਹੈ। ਬਾਈਨਰੀ ਉੱਤੇ ਫਾਈਲ-ਸਮਰੱਥਾਵਾਂ exec ਸਮੇਂ ਮਨਜ਼ੂਰ ਅਤੇ ਪ੍ਰਭਾਵੀ ਹੱਕ ਦੇ ਸਕਦੀਆਂ ਹਨ, ਪਰ ਸਿਰਫ਼ ਤਦ ਤੱਕ ਜਦੋਂ ਤੱਕ ਜ਼ੰਜੀਰ ਵਿੱਚ ਕੋਈ ਚੀਜ਼ ਉਸ ਤਬਾਦਲੇ ਨੂੰ ਨਹੀਂ ਰੋਕਦੀ।

ਇੱਥੇ ਹੀ sudo ਲੋਕਾਂ ਨੂੰ ਭਟਕਾਉਂਦਾ ਹੈ। sudo -u ਰਾਹੀਂ ਚਲਾਇਆ ਆਦੇਸ਼ ਨਵੀਂ ਵਿਸ਼ੇਸ਼ ਅਧਿਕਾਰ ਤਬਦੀਲੀ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ ਅਤੇ ਪਰਿਵੇਸ਼ ਸਮੂਹ ਚਲਾ ਜਾਂਦਾ ਹੈ, ਇਸ ਲਈ root ਵਜੋਂ ਸਫਲ ਹੋਣ ਵਾਲੀ ਉਹੀ ਜਾਂਚ ਉੱਥੇ ਅਸਫਲ ਹੁੰਦੀ ਹੈ। ਸੇਵਾ ਪ੍ਰਬੰਧਕ ਹੋਰ ਇੱਕ ਤਬਦੀਲੀ ਹੈ, ਅਤੇ ਯੂਨਿਟ ਨਾ ਕਹੇ ਤਾਂ ਇਹ ਪਰਿਵੇਸ਼ ਵਿੱਚ ਕੁਝ ਨਹੀਂ ਦਿੰਦਾ।

ਸਮਰੱਥਾ ਯੂਨਿਟ ਵਿੱਚ ਦਿਓ, ਰੈਪਰ ਵਿੱਚ ਨਹੀਂ

ਜੰਤਰ ਬਣਾਉਣ ਅਤੇ ਰੂਟ ਸਥਾਪਤ ਕਰਨ ਦੀ ਲੋੜ ਵਾਲੀ ਟਨਲ ਲਈ ਘੱਟੋ-ਘੱਟ ਸੇਵਾ ਭਾਗ ਇਸ ਤਰ੍ਹਾਂ ਦਿਸਦਾ ਹੈ।

[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 ਪ੍ਰਕਿਰਿਆ ਸ਼ੁਰੂ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਹੱਕ ਨੂੰ ਪਰਿਵੇਸ਼ ਸਮੂਹ ਵਿੱਚ ਰੱਖਦਾ ਹੈ, ਅਤੇ CapabilityBoundingSet ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਉਸ ਸੂਚੀ ਤੋਂ ਬਾਹਰ ਕੁਝ ਵੀ ਰੱਖਣ ਤੋਂ ਰੋਕਦਾ ਹੈ। NoNewPrivileges=yes setuid ਜਾਂ ਫਾਈਲ-ਸਮਰੱਥਾਵਾਂ ਰਾਹੀਂ ਵਿਸ਼ੇਸ਼ ਅਧਿਕਾਰ ਲੈਣ ਨੂੰ ਰੋਕਦਾ ਹੈ, ਜਦੋਂ ਕਿ ਯੂਨਿਟ ਵੱਲੋਂ ਸਪਸ਼ਟ ਦਿੱਤੀ ਸਮਰੱਥਾ ਅਜੇ ਵੀ ਲਾਗੂ ਰਹਿੰਦੀ ਹੈ। CAP_NET_BIND_SERVICE ਤਦ ਹੀ ਜੋੜੋ ਜਦੋਂ ਸੇਵਾ ਨੂੰ ਨੀਵਾਂ ਪੋਰਟ ਬੰਨ੍ਹਣਾ ਪਵੇ, ਅਤੇ ਸਿਰਫ਼ ਇਸ ਲਈ ਕਦੇ CAP_SYS_ADMIN ਨਾ ਜੋੜੋ ਕਿ ਕਿਸੇ ਫੋਰਮ ਥ੍ਰੈਡ ਨੇ ਕੀਤਾ ਸੀ।

ਜੇ ਯੂਨਿਟ ਬਾਈਨਰੀ ਨੂੰ sudo ਵਿੱਚ ਲਪੇਟਦੀ ਹੈ, ਤਾਂ ਰੈਪਰ ਹਟਾਓ। systemd ਪਹਿਲਾਂ ਹੀ User= ਲਾਗੂ ਕਰਦਾ ਹੈ, ਅਤੇ ਉਹ ਵਾਧੂ ਪਰਤ ਹੀ ਪਰਿਵੇਸ਼ ਸਮੂਹ ਖਾਲੀ ਹੋਣ ਦਾ ਸਭ ਤੋਂ ਸੰਭਾਵਿਤ ਕਾਰਨ ਹੈ।

ਯੂਨਿਟ ਫਾਈਲ 'ਤੇ ਨਹੀਂ, ਜੀਵਤ ਪ੍ਰਕਿਰਿਆ 'ਤੇ ਪੁਸ਼ਟੀ ਕਰੋ

ਪੜ੍ਹੋ ਕਿ ਪ੍ਰਬੰਧਕ ਨੇ ਅਸਲ ਵਿੱਚ ਕੀ ਲਾਗੂ ਕੀਤਾ, ਫਿਰ ਉਹ ਪ੍ਰਕਿਰਿਆ ਪੜ੍ਹੋ ਜੋ ਉਸਨੇ ਪੈਦਾ ਕੀਤੀ।

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

ਜੇ ਯੂਨਿਟ ਸਮਰੱਥਾ ਸੂਚੀਬੱਧ ਕਰਦੀ ਹੈ ਅਤੇ CapEff ਵਿੱਚ ਅਜੇ ਵੀ ਨਹੀਂ ਹੈ, ਤਾਂ ਕੋਈ drop-in ਸੈਟਿੰਗ ਨੂੰ ਪਾਸੇ ਕਰ ਰਿਹਾ ਹੈ ਜਾਂ ExecStartPre ਕਦਮ ਵਾਤਾਵਰਣ ਬਦਲ ਰਿਹਾ ਹੈ। ਮੁੱਖ ਫਾਈਲ ਨੂੰ ਅਧਿਕਾਰਤ ਮੰਨਣ ਤੋਂ ਪਹਿਲਾਂ drop-in ਡਾਇਰੈਕਟਰੀਆਂ ਵਿੱਚ ਯੂਨਿਟ ਦਾ ਨਾਮ ਲੱਭੋ, ਕਿਉਂਕਿ ਬਾਅਦ ਵਾਲੀ ਫਾਈਲ ਚੁੱਪਚਾਪ ਜਿੱਤਦੀ ਹੈ। ਜੇ ਯੂਨਿਟ ਅਤੇ ਪ੍ਰਕਿਰਿਆ ਦੋਵੇਂ ਸਮਰੱਥਾ ਦਿਖਾਉਂਦੇ ਹਨ ਅਤੇ ਟਨਲ ਫਿਰ ਵੀ ਅਸਫਲ ਹੁੰਦੀ ਹੈ, ਤਾਂ ਸੀਮਿਤ ਸਮੂਹ ਨੂੰ ਚੌੜਾ ਕਰਨ ਦੀ ਥਾਂ ਜੰਤਰ ਅਤੇ ਮਾਰਗ ਜਾਂਚਾਂ ਵੱਲ ਵਾਪਸ ਜਾਓ। ਇਸਨੂੰ ਚੌੜਾ ਕਰਨਾ ਅਸਲ ਕਾਰਨ ਲੁਕਾ ਦਿੰਦਾ ਹੈ ਅਤੇ ਸੇਵਾ ਨੂੰ ਪਹਿਲਾਂ ਨਾਲੋਂ ਵੱਧ ਵਿਸ਼ੇਸ਼ ਅਧਿਕਾਰਾਂ ਵਾਲੀ ਛੱਡ ਦਿੰਦਾ ਹੈ।

ਸ਼ੁਰੂ ਹੋਣ ਤੋਂ ਬਾਅਦ ਵਿਸ਼ੇਸ਼ ਅਧਿਕਾਰ ਛੱਡਣਾ ਤਰਜੀਹ ਦਿਓ

OpenVPN ਆਪਣੇ user ਅਤੇ group ਵਿਕਲਪਾਂ ਰਾਹੀਂ ਵਿਸ਼ੇਸ਼ ਅਧਿਕਾਰਾਂ ਨਾਲ ਸ਼ੁਰੂ ਹੋ ਕੇ ਬਾਅਦ ਵਿੱਚ ਗੈਰ-ਵਿਸ਼ੇਸ਼ ਅਧਿਕਾਰ ਵਾਲੇ ਖਾਤੇ ਵਿੱਚ ਉੱਤਰ ਸਕਦਾ ਹੈ, ਅਤੇ persist-key ਤੇ persist-tun ਟਨਲ ਨੂੰ ਬਾਅਦ ਵਿੱਚ ਵੀ ਵਰਤੋਂਯੋਗ ਰੱਖਦੇ ਹਨ। ਇਹ ਬੰਦੋਬਸਤ ਉਸ ਵਿੰਡੋ ਨੂੰ ਤੰਗ ਕਰਦੀ ਹੈ ਜਿਸ ਵਿੱਚ ਪ੍ਰਕਿਰਿਆ ਕੋਲ ਹੱਕ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਸਥਾਈ ਸਮਰੱਥਾਵਾਂ ਨਾਲ ਪੂਰੇ ਡੈਮਨ ਨੂੰ ਗੈਰ-ਵਿਸ਼ੇਸ਼ ਅਧਿਕਾਰ ਨਾਲ ਸ਼ੁਰੂ ਕਰਨ ਨਾਲੋਂ ਇਹ ਅਕਸਰ ਵਧੇਰੇ ਢੁਕਵੀਂ ਹੁੰਦੀ ਹੈ।

ਤੁਸੀਂ ਕੋਈ ਵੀ ਮਾਡਲ ਚੁਣੋ, ਯੂਨਿਟ ਨੂੰ ਮੁੜ ਸ਼ੁਰੂ ਕਰੋ ਅਤੇ ਰੀਬੂਟ ਤੋਂ ਬਾਅਦ ਜਾਂਚਾਂ ਦੁਹਰਾਓ, ਕਿਉਂਕਿ ਇੰਟਰਐਕਟਿਵ root ਸ਼ੈੱਲ ਤੋਂ ਕੰਮ ਕਰਨ ਵਾਲੀ ਪਰ ਬੂਟ 'ਤੇ ਅਸਫਲ ਹੋਣ ਵਾਲੀ ਸੇਵਾ ਆਮ ਤੌਰ 'ਤੇ ਸਮਰੱਥਾ, ਜੰਤਰ ਜਾਂ ਫਾਈਲ-ਇਜਾਜ਼ਤ ਦਾ ਫ਼ਰਕ ਹੁੰਦੀ ਹੈ। ਯੂਨਿਟ ਸੈਟਿੰਗਾਂ ਪ੍ਰਕਿਰਿਆ ਦੇ ਸਮਰੱਥਾ ਆਉਟਪੁੱਟ ਦੇ ਕੋਲ ਲਿਖੋ, ਤਾਂ ਜੋ ਅਗਲਾ ਸਮੀਖਿਅਕ ਵੇਖ ਸਕੇ ਕਿ ਪੈਕੇਜ ਅਪਡੇਟ ਜਾਂ drop-in ਨੇ ਸੀਮਾ ਹਿਲਾਈ ਹੈ ਜਾਂ ਨਹੀਂ।