OpenVPN 'ਤੇ chroot ਫੇਲ੍ਹ: AppArmor ਨਿਯਮ ਜਾਂ ਯੋਗਤਾ?

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

ਦੋ ਵੱਖਰੇ ਦਰਵਾਜ਼ੇ, ਅਤੇ ਸਿਰਫ਼ ਇੱਕ AppArmor ਦਾ

chroot ਨੂੰ ਉਸ ਵਰਤੋਂਕਾਰ ਨਾਮ-ਥਾਂ ਵਿੱਚ CAP_SYS_CHROOT ਚਾਹੀਦਾ ਹੈ ਜਿੱਥੇ ਪ੍ਰਕਿਰਿਆ ਚੱਲ ਰਹੀ ਹੈ। ਇਹ ਆਮ Linux ਵਿਸ਼ੇਸ਼ ਅਧਿਕਾਰ ਹੈ, ਜੋ ਕਰਨਲ ਕਾਲ ਦੇ ਪਾਥਾਂ ਨਾਲ ਕੁਝ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਜਾਂਚਦਾ ਹੈ। ਵੱਖਰੇ ਤੌਰ 'ਤੇ, ਲਾਗੂ ਕਰਨ ਵਾਲਾ AppArmor ਪ੍ਰੋਫਾਈਲ ਯੋਗਤਾ ਨੂੰ ਰੱਦ ਵੀ ਸਕਦਾ ਹੈ ਭਾਵੇਂ ਪ੍ਰਕਿਰਿਆ ਕੋਲ ਉਹ ਹੋਵੇ, ਕਿਉਂਕਿ ਲਾਜ਼ਮੀ ਨੀਤੀ ਪ੍ਰਮਾਣ-ਪੱਤਰਾਂ ਦੀ ਥਾਂ 'ਤੇ ਨਹੀਂ ਸਗੋਂ ਉਨ੍ਹਾਂ ਦੇ ਨਾਲ ਵੇਖੀ ਜਾਂਦੀ ਹੈ। ਇਹ ਫ਼ਰਕ ਵਿਵਹਾਰ ਵਿੱਚ ਮਹੱਤਵਪੂਰਨ ਹੈ: ਦੋਵੇਂ ਪਰਤਾਂ ਵੱਖਰੀਆਂ ਫਾਈਲਾਂ ਵਿੱਚ ਰਹਿੰਦੀਆਂ ਹਨ ਅਤੇ ਆਮ ਤੌਰ 'ਤੇ ਵੱਖਰੇ ਲੋਕ ਉਨ੍ਹਾਂ ਦੀ ਸੰਭਾਲ ਕਰਦੇ ਹਨ।

ਉਹ ਦੋਵੇਂ ਦਰਵਾਜ਼ੇ ਇੱਕੋ errno ਨਾਲ ਫੇਲ੍ਹ ਹੁੰਦੇ ਹਨ। ਦੋਵੇਂ EPERM ਪੈਦਾ ਕਰਦੇ ਹਨ, ਅਤੇ ਦੋਵੇਂ ਡੀਮਨ ਲਾਗ ਵਿੱਚ ਆਮ ਆਗਿਆ-ਸ਼ਿਕਾਇਤ ਵਜੋਂ ਦਿਸਦੇ ਹਨ, ਇਸ ਲਈ ਪ੍ਰੋਫਾਈਲ ਦੀ ਸਮੱਗਰੀ ਦਾ ਅੰਦਾਜ਼ਾ ਲਾਉਣਾ ਇੰਨਾ ਸਮਾਂ ਬਰਬਾਦ ਕਰਦਾ ਹੈ। ਜੋ ਪਾਥ ਨਿਯਮ ਤੁਸੀਂ ਜੋੜਨ ਵਾਲੇ ਸੀ ਉਹ chroot ਸਫਲ ਹੋਣ ਤੋਂ ਬਾਅਦ ਫਾਈਲ ਪਹੁੰਚ ਨੂੰ ਨਿਯੰਤਰਿਤ ਕਰਦਾ ਹੈ; ਕਾਰਵਾਈ ਨੂੰ ਮੂਲ ਰੂਪ ਵਿੱਚ ਆਗਿਆ ਹੈ ਜਾਂ ਨਹੀਂ, ਇਸ ਨਾਲ ਉਸਦਾ ਕੋਈ ਸੰਬੰਧ ਨਹੀਂ।

ਤੀਜਾ ਦਰਵਾਜ਼ਾ ਦੋਵਾਂ ਤੋਂ ਉੱਪਰ ਹੈ। ਜੇ ਸੇਵਾ ਪ੍ਰਬੰਧਕ ਜਾਂ ਕੋਈ ਲਪੇਟ ਨੇ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਉਸਦੇ ਸੀਮਤ ਸਮੂਹ ਵਿੱਚ ਯੋਗਤਾ ਤੋਂ ਬਿਨਾਂ ਸ਼ੁਰੂ ਕੀਤਾ ਹੈ, ਤਾਂ ਕੋਈ ਵੀ AppArmor ਬਦਲਾਅ ਉਹ ਵਾਪਸ ਨਹੀਂ ਲਿਆ ਸਕਦਾ, ਅਤੇ ਪ੍ਰੋਫਾਈਲ ਵਿੱਚ ਯੋਗਤਾਵਾਂ ਜੋੜਨਾ ਸਿਰਫ਼ ਉਸ ਇਰਾਦੇ ਨੂੰ ਦਰਜ ਕਰਦਾ ਹੈ ਜਿਸਨੂੰ ਕਰਨਲ ਨਹੀਂ ਮੰਨੇਗਾ।

ਨੀਤੀ ਸੋਧਣ ਤੋਂ ਪਹਿਲਾਂ ਵਿਸ਼ੇਸ਼ ਅਧਿਕਾਰ ਦੀ ਸਥਿਤੀ ਪੜ੍ਹੋ

ਉਸ ਸੰਰਚਨਾ ਤੋਂ ਨਹੀਂ ਜਿਸਨੂੰ ਤੁਸੀਂ ਸਰਗਰਮ ਸਮਝਦੇ ਹੋ, ਸਗੋਂ ਚੱਲ ਰਹੀ ਪ੍ਰਕਿਰਿਆ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ। ਸਥਿਤੀ ਫਾਈਲ ਪੰਜ ਯੋਗਤਾ-ਮਾਸਕ ਅਤੇ no-new-privileges ਝੰਡਾ ਦਿਖਾਉਂਦੀ ਹੈ, ਅਤੇ ਉਹ ਵੱਖਰੇ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਦਿੰਦੇ ਹਨ:

grep -E '^(CapInh|CapPrm|CapEff|CapBnd|CapAmb|NoNewPrivs):' /proc/$(pidof openvpn)/status
sudo aa-status | grep -i openvpn

CapEff ਉਹ ਸਮੂਹ ਹੈ ਜੋ ਕਾਲ ਲਈ ਮਹੱਤਵਪੂਰਨ ਹੈ: CapBnd ਵਿੱਚ ਮੌਜੂਦ ਪਰ CapEff ਵਿੱਚ ਗੈਰਹਾਜ਼ਰ ਯੋਗਤਾ ਛੱਤ ਵੱਲੋਂ ਆਗਿਆ ਪ੍ਰਾਪਤ ਹੈ ਅਤੇ ਇਸ ਸਮੇਂ ਧਾਰਨ ਨਹੀਂ ਕੀਤੀ ਗਈ। CapAmb ਉਦੋਂ ਮਹੱਤਵਪੂਰਨ ਹੈ ਜਦੋਂ ਬਾਈਨਰੀ ਆਮ setuid ਅਰਥ ਵਿੱਚ ਵਿਸ਼ੇਸ਼ ਅਧਿਕਾਰ ਵਾਲੀ ਨਹੀਂ, ਕਿਉਂਕਿ ਵਾਤਾਵਰਣ ਯੋਗਤਾਵਾਂ ਹੀ ਉਹ ਤਰੀਕਾ ਹਨ ਜਿਸ ਨਾਲ ਸੇਵਾ ਫਾਈਲ ਯੋਗਤਾਵਾਂ ਤੋਂ ਬਿਨਾਂ exec ਦੇ ਪਾਰ ਵਿਸ਼ੇਸ਼ ਅਧਿਕਾਰ ਰੱਖਦੀ ਹੈ। CapInh ਵਿੱਚ ਅਜਿਹੇ ਬਿੱਟ ਹਨ ਜੋ exec ਦੇ ਪਾਰ ਵਿਰਾਸਤ ਵਿੱਚ ਆ ਸਕਦੇ ਹਨ, ਪਰ ਸਿਰਫ਼ ਉਦੋਂ ਜਦੋਂ ਚਲਾਈ ਜਾਣ ਵਾਲੀ ਫਾਈਲ ਦਾ ਵਿਰਾਸਤੀ ਸਮੂਹ ਆਗਿਆ ਦਿੰਦਾ ਹੈ, ਇਸ ਲਈ ਉੱਥਲਾ ਇੱਕ ਬਿੱਟ ਆਪਣੇ ਆਪ ਕੁਝ ਨਹੀਂ ਦਿੰਦਾ।

ਫਿਰ ਪੱਕਾ ਕਰੋ ਕਿ ਕਿਹੜਾ ਪ੍ਰੋਫਾਈਲ ਸੱਚਮੁੱਚ ਜੁੜਿਆ ਹੈ। ਪ੍ਰਕਿਰਿਆ ਉਸ ਪ੍ਰੋਫਾਈਲ ਨਾਮ ਨਾਲ ਸੀਮਤ ਹੋ ਸਕਦੀ ਹੈ ਜਿਸਦੀ ਤੁਸੀਂ ਉਮੀਦ ਨਹੀਂ ਕੀਤੀ, ਖ਼ਾਸਕਰ ਜਦੋਂ ਕੋਈ ਵੰਡ ਆਪਣੀ ਯੂਨਿਟ ਫਾਈਲ ਅਤੇ ਪ੍ਰੋਫਾਈਲ ਇਕੱਠੇ ਭੇਜਦੀ ਹੈ, ਅਤੇ /proc/PID/attr/current ਪੜ੍ਹਨਾ ਇਹ ਇੱਕ ਲਾਈਨ ਵਿੱਚ ਤੈਅ ਕਰ ਦਿੰਦਾ ਹੈ। ਆਪਣੀ ਸੋਧੀ ਫਾਈਲ ਦੀ ਤੁਲਨਾ ਕਰਨਲ ਵੱਲੋਂ ਦੱਸੇ ਪ੍ਰੋਫਾਈਲ ਨਾਲ ਕਰਨਾ ਕਾਰਨ ਠੀਕ ਕਰਨ ਅਤੇ ਅਜਿਹੀ ਫਾਈਲ ਸੋਧਣ ਵਿਚਕਾਰਲਾ ਫ਼ਰਕ ਹੈ ਜਿਸਨੂੰ ਕੋਈ ਲੋਡ ਨਹੀਂ ਕਰਦਾ।

ਯੋਗਤਾ ਨਿਯਮ ਸਿਰਫ਼ ਉਦੋਂ ਜੋੜੋ ਜਦੋਂ ਆਡਿਟ ਟ੍ਰੇਲ ਇਸ ਤਰ੍ਹਾਂ ਕਹੇ

ਕਰਨਲ ਅਤੇ ਆਡਿਟ ਰਿਕਾਰਡ ਰੱਦ ਕਰਨ ਵਾਲੀ ਪਰਤ ਦਾ ਨਾਮ ਲੈਂਦੇ ਹਨ। ਅਜਿਹਾ ਇਨਕਾਰ ਲੱਭੋ ਜਿਸ ਵਿੱਚ ਕਾਰਵਾਈ capable ਅਤੇ ਨਾਮ sys_chroot ਹੋਵੇ, ਨਾਲ ਹੀ ਉਹ ਪ੍ਰੋਫਾਈਲ ਜਿਸਨੇ ਇਹ ਪੈਦਾ ਕੀਤਾ। ਜੇ ਉਹ ਰਿਕਾਰਡ ਮੌਜੂਦ ਹੈ, ਤਾਂ ਪ੍ਰਕਿਰਿਆ ਕੋਲ ਯੋਗਤਾ ਪਹਿਲਾਂ ਹੀ ਸੀ ਅਤੇ AppArmor ਨੇ ਇਨਕਾਰ ਕੀਤਾ, ਅਤੇ ਨਿਸ਼ਾਨਾ ਬਦਲਾਅ ਅਸਲ ਪ੍ਰੋਫਾਈਲ ਅੰਦਰ ਇੱਕ ਯੋਗਤਾ ਨਿਯਮ ਹੈ:

capability sys_chroot,

ਇਸਨੂੰ ਸੱਚਮੁੱਚ ਜੁੜੇ ਪ੍ਰੋਫਾਈਲ ਵਿੱਚ ਟੁਕੜੇ ਵਜੋਂ ਰੱਖੋ, ਅਤੇ ਕੀਵਰਡ ਨੂੰ ਅਸੰਬੰਧਿਤ ਟਿਊਟੋਰਿਅਲ ਤੋਂ ਨਿਯਮ ਨਕਲ ਕਰਨ ਦੀ ਥਾਂ apparmor.d ਪ੍ਰੋਫਾਈਲ ਹਵਾਲੇ ਨਾਲ ਜਾਂਚੋ। ਇਸਨੂੰ ਸਾਂਝੇ include ਵਿੱਚ ਪਾਉਣਾ ਉਹ ਹਰ ਸੀਮਤ ਪ੍ਰੋਗਰਾਮ ਨੂੰ ਦੇ ਦਿੰਦਾ ਹੈ ਜੋ ਉਹ ਫਾਈਲ ਖਿੱਚਦਾ ਹੈ, ਅਤੇ ਪ੍ਰੋਫਾਈਲ ਨੂੰ complain ਮੋਡ ਵਿੱਚ ਬਦਲਣਾ ਇਸਨੂੰ ਹੱਲ ਕਰਨ ਦੀ ਥਾਂ ਅਗਲਾ ਇਨਕਾਰ ਲੁਕਾ ਦਿੰਦਾ ਹੈ। ਪ੍ਰੋਫਾਈਲ ਨਿਯਮ ਨੀਤੀ ਦਾ ਇਨਕਾਰ ਹਟਾਉਂਦਾ ਹੈ; ਇਹ ਵਿਸ਼ੇਸ਼ ਅਧਿਕਾਰ ਨਹੀਂ ਬਣਾਉਂਦਾ, ਇਸ ਲਈ ਜਿਸ ਪ੍ਰਕਿਰਿਆ ਕੋਲ ਕਦੇ ਵੀ ਆਪਣੇ ਪ੍ਰਭਾਵੀ ਸਮੂਹ ਵਿੱਚ CAP_SYS_CHROOT ਨਹੀਂ ਸੀ ਉਹ ਨਿਯਮ ਹੋਣ 'ਤੇ ਵੀ ਫੇਲ੍ਹ ਹੋਵੇਗੀ।

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

ਸੇਵਾ ਪ੍ਰਬੰਧਕ ਆਪਣੀ ਛੱਤ ਰੱਖਦਾ ਹੈ

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

ਛੱਤ ਚੁੱਕਣਾ ਅਤੇ ਯੋਗਤਾ ਦੇਣਾ ਦੋ ਬਦਲਾਅ ਹਨ, ਇੱਕ ਨਹੀਂ। ਸੀਮਤ ਸਮੂਹ ਦੀ ਐਂਟਰੀ ਕਹਿੰਦੀ ਹੈ ਕਿ ਪ੍ਰਕਿਰਿਆ ਯੋਗਤਾ ਰੱਖ ਸਕਦੀ ਹੈ; ਇਹ ਇਸਨੂੰ ਪ੍ਰਭਾਵੀ ਸਮੂਹ ਵਿੱਚ ਨਹੀਂ ਜੋੜਦੀ, ਅਤੇ NoNewPrivs ਬਾਕੀ ਸਭ ਠੀਕ ਹੋਣ 'ਤੇ ਵੀ ਬਾਅਦ ਦੀ ਉੱਨਤੀ ਨੂੰ ਸਫਲ ਹੋਣ ਤੋਂ ਰੋਕ ਸਕਦਾ ਹੈ। ਸਿਰਫ਼ ਉਹੀ ਜੋੜੋ ਜੋ ਕਾਰਵਾਈ ਨੂੰ ਚਾਹੀਦਾ ਹੈ, ਬਾਕੀ ਕਠੋਰਤਾ ਕਾਇਮ ਰੱਖੋ, ਅਤੇ ਇੱਕ ਕਾਲ ਲੰਘਾਉਣ ਲਈ ਸਾਰੀਆਂ ਯੋਗਤਾਵਾਂ ਦੇਣ ਵਾਲੇ ਛੋਟੇ ਰਾਹ ਨੂੰ ਰੱਦ ਕਰੋ।

ਇੱਥੇ ਕ੍ਰਮ ਵੀ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਪਹਿਲਾਂ ਯੂਨਿਟ ਦੀ ਛੱਤ ਬਦਲੋ, ਪੱਕਾ ਕਰੋ ਕਿ CapEff ਵਿੱਚ ਹੁਣ ਉਹ ਬਿੱਟ ਹੈ, ਅਤੇ ਫਿਰ ਹੀ ਤੈਅ ਕਰੋ ਕਿ AppArmor ਅਜੇ ਵੀ ਇਨਕਾਰ ਕਰਦਾ ਹੈ ਜਾਂ ਨਹੀਂ। ਦੋਵੇਂ ਬਦਲਾਅ ਇਕੱਠੇ ਕਰਨ ਨਾਲ ਫੇਲ੍ਹ ਜਾਰੀ ਰਹਿਣ 'ਤੇ ਤੁਸੀਂ ਮੁੜ ਅੰਦਾਜ਼ੇ ਵਿੱਚ ਪੈ ਜਾਂਦੇ ਹੋ।

ਇਨਕਾਰ ਹਟਣ ਤੋਂ ਬਾਅਦ ਜੇਲ੍ਹ ਆਪ ਜਾਂਚੋ

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

chroot ਕੀ ਨਹੀਂ ਕਰਦਾ, ਇਹ ਯਾਦ ਰੱਖਣਾ ਵੀ ਮਦਦ ਕਰਦਾ ਹੈ। ਇਹ ਪਾਥ ਦੀ ਸੀਮਾ ਹੈ, ਸੈਂਡਬਾਕਸ ਨਹੀਂ: ਵਿਸ਼ੇਸ਼ ਅਧਿਕਾਰ ਰੱਖਣ ਵਾਲੀ ਪ੍ਰਕਿਰਿਆ ਇਸ ਤੋਂ ਭੱਜ ਸਕਦੀ ਹੈ, ਇਸ ਲਈ ਯੋਗਤਾ ਆਮ ਤੌਰ 'ਤੇ ਕਾਲ ਤੋਂ ਬਾਅਦ ਛੱਡ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ ਅਤੇ ਇਸ ਲਈ ਘੇਰਾਬੰਦੀ ਡੀਮਨ ਦੇ ਦੁਆਲੇ ਰਹਿਣੀ ਚਾਹੀਦੀ ਹੈ। AppArmor ਪ੍ਰੋਫਾਈਲ, ਯੋਗਤਾਵਾਂ ਦਾ ਸੀਮਤ ਸਮੂਹ ਅਤੇ ਫਾਈਲਸਿਸਟਮ ਪਾਬੰਦੀਆਂ ਨੂੰ ਇਕੱਠੇ ਰੱਖਣਾ ਇਸ ਅਭਿਆਸ ਦਾ ਮਕਸਦ ਹੈ, ਸੇਵਾ ਸ਼ੁਰੂ ਹੋਣ 'ਤੇ ਹਟਾਉਣ ਵਾਲਾ ਬਚਿਆ ਕੂੜਾ ਨਹੀਂ।

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