ਤੁਸੀਂ up ਸਕ੍ਰਿਪਟ ਨੂੰ ਰੂਟ ਵਜੋਂ ਚਲਾਉਂਦੇ ਹੋ, ਇਹ ਪੂਰੀ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਸੇਵਾ ਵੱਲੋਂ ਬੁਲਾਏ ਜਾਣ ’ਤੇ ਉਹੀ ਸਕ੍ਰਿਪਟ ਫੇਲ੍ਹ ਹੋ ਜਾਂਦੀ ਹੈ। ਫ਼ਾਈਲ ਦੀਆਂ ਇਜਾਜ਼ਤਾਂ ਵਿੱਚ ਕੁਝ ਨਹੀਂ ਬਦਲਿਆ, ਇਸ ਲਈ ਅਗਲਾ ਕੁਦਰਤੀ ਕਦਮ ਉਹਨਾਂ ਨੂੰ ਦੁਬਾਰਾ ਢਿੱਲਾ ਕਰਨਾ ਹੈ, ਜੋ ਕੁਝ ਵੀ ਠੀਕ ਨਹੀਂ ਕਰਦਾ। SELinux ਹੋਸਟ ’ਤੇ ਨਿਰਣਾਇਕ ਕਾਰਕ ਅਕਸਰ ਇਹ ਨਹੀਂ ਹੁੰਦਾ ਕਿ ਪ੍ਰਕਿਰਿਆ ਕੌਣ ਹੈ, ਸਗੋਂ ਇਹ ਹੁੰਦਾ ਹੈ ਕਿ ਇਹ ਕਿਹੜੇ ਡੋਮੇਨ ਵਿੱਚ ਚੱਲਦੀ ਹੈ, ਅਤੇ ਸੀਮਤ ਡੋਮੇਨ ਦੇ ਅੰਦਰ ਰੂਟ ਵੀ ਸੀਮਤ ਹੀ ਰਹਿੰਦਾ ਹੈ।

ਉਹੀ ਕਮਾਂਡ, ਦੋ ਵੱਖਰੇ ਸੁਰੱਖਿਆ ਡੋਮੇਨ

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

ਇਸੇ ਲਈ ਦੋਵੇਂ ਰਨਾਂ ਦੀ ਤੁਲਨਾ ਸਿਰਫ਼ ਤਦ ਲਾਭਦਾਇਕ ਹੈ ਜੇ ਤੁਸੀਂ ਉਹਨਾਂ ਦੇ ਸੰਦਰਭਾਂ ਦੀ ਤੁਲਨਾ ਕਰੋ। ਉਹੀ ਕਮਾਂਡ ਸ਼ੈੱਲ ਅਤੇ hook ਤੋਂ ਚਲਾਓ; ਸ਼ੈੱਲ ਵਾਲਾ ਸੰਸਕਰਣ ਸਾਬਤ ਕਰਦਾ ਹੈ ਕਿ ਬਾਈਨਰੀ ਮੌਜੂਦ ਹੈ ਅਤੇ ਆਰਗਿਊਮੈਂਟ ਸਹੀ ਹਨ, ਪਰ ਇਹ ਸਾਬਤ ਨਹੀਂ ਕਰਦਾ ਕਿ ਸੇਵਾ ਨੂੰ ਇਸਨੂੰ ਚਲਾਉਣ ਦੀ ਇਜਾਜ਼ਤ ਹੈ। ਦੋਵੇਂ ਤਰੀਕਿਆਂ ਨਾਲ ਚਲਾਓ ਅਤੇ ਸਿਰਫ਼ ਐਗਜ਼ਿਟ ਕੋਡ ਨਹੀਂ, ਡੋਮੇਨਾਂ ਦੀ ਤੁਲਨਾ ਕਰੋ। ਇਹੀ ਤੁਲਨਾ ਇੱਕ ਅਸਪਸ਼ਟ ਇਜਾਜ਼ਤ ਸ਼ਿਕਾਇਤ ਨੂੰ ਇੱਕ ਡੋਮੇਨ ਅਤੇ ਇੱਕ ਲੇਬਲ ਬਾਰੇ ਠੋਸ ਸਵਾਲ ਵਿੱਚ ਬਦਲਦੀ ਹੈ।

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

hook ਗਲਤੀ ਦੇ ਕੋਲ AVC ਰਿਕਾਰਡ ਪੜ੍ਹੋ

AVC ਰੱਦ ਕੇਸ ਦਾ ਫੈਸਲਾ ਕਰਨ ਵਾਲੇ ਖੇਤਰਾਂ ਦੇ ਨਾਂ ਦੱਸਦੀ ਹੈ: ਪ੍ਰਕਿਰਿਆ ਦਾ ਸਰੋਤ ਸੰਦਰਭ, ਆਬਜੈਕਟ ਦਾ ਨਿਸ਼ਾਨਾ ਸੰਦਰਭ, ਆਬਜੈਕਟ ਵਰਗ ਅਤੇ ਰੱਦ ਕੀਤੀ ਖਾਸ ਇਜਾਜ਼ਤ। ਸਿਧਾਂਤ ਬਣਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਚਾਰੇ ਪੜ੍ਹੋ, ਕਿਉਂਕਿ ਐਗਜ਼ੀਕਿਊਟ ’ਤੇ ਰੱਦ ਅਤੇ ਰਾਈਟ ’ਤੇ ਰੱਦ ਦੀਆਂ ਮੁਰੰਮਤਾਂ ਬਿਲਕੁਲ ਵੱਖਰੀਆਂ ਹਨ।

ausearch -m AVC,USER_AVC -ts recent
ls -Z /usr/local/sbin/vpn-up.sh
ps -eZ | grep openvpn

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

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

ਲੇਬਲ, ਸੰਰਚਨਾ ਜਾਂ ਨੀਤੀ: ਤਿੰਨ ਮੁਰੰਮਤਾਂ

ਪਹਿਲੀ ਮੁਰੰਮਤ ਉਹ ਲੇਬਲ ਹੈ ਜੋ ਫ਼ਾਈਲ ਦੀ ਇੰਸਟਾਲ ਹੋਈ ਥਾਂ ਨਾਲ ਮੇਲ ਨਹੀਂ ਖਾਂਦਾ। cp ਨਾਲ ਥਾਂ ’ਤੇ ਕਾਪੀ ਕੀਤੀ ਜਾਂ ਐਡੀਟਰ ਨਾਲ ਲਿਖੀ ਸਕ੍ਰਿਪਟ ਅਜਿਹਾ ਡਿਫ਼ਾਲਟ ਲੇਬਲ ਰੱਖ ਸਕਦੀ ਹੈ ਜੋ ਸੇਵਾ ਡੋਮੇਨ ਵਰਤ ਨਹੀਂ ਸਕਦਾ, ਅਤੇ ਉਮੀਦ ਕੀਤਾ ਸੰਦਰਭ ਬਹਾਲ ਕਰਨ ਨਾਲ ਨੀਤੀ ਨੂੰ ਛੋਹੇ ਬਿਨਾਂ ਹੀ ਇਹ ਠੀਕ ਹੋ ਜਾਂਦਾ ਹੈ।

ਦੂਜੀ ਸੰਰਚਨਾ ਹੈ। ਡਿਸਟਰੀਬਿਊਸ਼ਨ ਕਾਰਵਾਈ ਚਲਾਉਣ ਦਾ ਸਮਰਥਿਤ ਤਰੀਕਾ, ਸਹਾਇਕ ਲਈ ਦਸਤਾਵੇਜ਼ੀ ਡਾਇਰੈਕਟਰੀ, ਜਾਂ ਪਹਿਲਾਂ ਹੀ ਇਜਾਜ਼ਤ ਦੇਣ ਵਾਲਾ ਅੱਪਡੇਟ ਕੀਤਾ ਨੀਤੀ ਪੈਕੇਜ ਦੇ ਸਕਦਾ ਹੈ। ਤੁਹਾਡਾ ਲੇਆਉਟ ਸਮਰਥਿਤ ਇੱਕ ਵਿੱਚ ਬਦਲਣਾ ਨੀਤੀ ਲਿਖਣ ਤੋਂ ਸਸਤਾ ਹੈ ਅਤੇ ਅੱਪਡੇਟਾਂ ਵਿੱਚ ਟਿਕਦਾ ਹੈ।

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

ਪੁਰਾਣਾ allow ਮੌਡਿਊਲ ਜਵਾਬ ਕਿਉਂ ਨਹੀਂ

ਇਸ ਖ਼ਰਾਬੀ ਲਈ ਖੋਜ ਨਤੀਜੇ ਤਿਆਰ ਮੌਡਿਊਲਾਂ ਨਾਲ ਭਰੇ ਹਨ, ਅਕਸਰ ਅਜਿਹੇ ਸਾਧਨ ਲਈ ਜਿਸਨੂੰ hook ਹੁਣ ਨਹੀਂ ਬੁਲਾਉਂਦਾ। ਇੱਕ ਇੰਸਟਾਲ ਕਰਨ ਨਾਲ ਅਜਿਹੀਆਂ ਇਜਾਜ਼ਤਾਂ ਮਿਲਦੀਆਂ ਹਨ ਜਿਨ੍ਹਾਂ ਦਾ ਤੁਹਾਡੇ ਰੱਦ ਨਾਲ ਕੋਈ ਸੰਬੰਧ ਨਹੀਂ ਹੋ ਸਕਦਾ, ਅਤੇ ਇਹ ਸਥਾਈ ਮੋਰੀ ਜੋੜਦਿਆਂ ਅਸਲ ਬੇਮੇਲ ਨੂੰ ਥਾਂ ’ਤੇ ਹੀ ਰਹਿਣ ਦਿੰਦਾ ਹੈ।

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

ਅਨੁਸ਼ਾਸਿਤ ਤੁਲਨਾ ਤੁਹਾਡੇ ਪੜ੍ਹ ਸਕਣ ਵਾਲੇ ਰੱਦ ਅਤੇ ਤੁਹਾਡੇ ਵੱਲੋਂ ਸੁਝਾਏ ਬਦਲਾਅ ਵਿਚਕਾਰ ਹੈ। Red Hat ਦੀ SELinux ਸਮੱਸਿਆ ਨਿਵਾਰਨ ਗਾਈਡ ਲੇਬਲਿੰਗ ਅਤੇ ਸੰਰਚਨਾ ਜਾਂਚਾਂ ਨੂੰ ਪੈਦਾ ਕੀਤੀ ਨੀਤੀ ਤੋਂ ਪਹਿਲਾਂ ਰੱਖਦੀ ਹੈ, ਠੀਕ ਇਸੇ ਕਾਰਨ। ਜੇ ਰਿਕਾਰਡ ਵਿੱਚ ਮਿਲਦਾ ਰੱਦ ਨਹੀਂ ਹੈ, ਤਾਂ SELinux ਸੰਭਵ ਤੌਰ ’ਤੇ ਤੁਹਾਡੀ ਸਮੱਸਿਆ ਨਹੀਂ ਹੈ, ਅਤੇ ਪਾਥ, ਸੈਂਡਬਾਕਸ ਜਾਂ ਇਜਾਜ਼ਤ ਦੇ ਮੁੱਦੇ ਅਜੇ ਵੀ ਖੁੱਲ੍ਹੇ ਹਨ।

ਸੰਬੰਧਿਤ ਲੇਖ