VPN ਸਰਟੀਫਿਕੇਟ ਨੂੰ ਹਿਲਾਉਣ ਨਾਲ ਉਸ ਦਾ SELinux ਲੇਬਲ ਕਿਉਂ ਟੁੱਟਦਾ ਹੈ

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

ਨਾਮ ਬਦਲਣਾ ਲੇਬਲ ਨਾਲ ਅਸਲ ਵਿੱਚ ਕੀ ਕਰਦਾ ਹੈ

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

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

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

ਮੌਜੂਦਾ ਲੇਬਲ ਨੂੰ ਉਮੀਦ ਵਾਲੇ ਦੇ ਸਾਹਮਣੇ ਪੜ੍ਹੋ

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

ls -lZ /etc/openvpn/client/office-ca.crt
matchpathcon /etc/openvpn/client/office-ca.crt
restorecon -Rn -v /etc/openvpn/client

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

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

ਅਪਵਾਦ ਘੜਨ ਦੀ ਥਾਂ ਮੈਪਿੰਗ ਬਹਾਲ ਕਰੋ

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

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

semanage fcontext -a -t openvpn_etc_t '/etc/openvpn/custom(/.*)?'
restorecon -Rv /etc/openvpn/custom

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

chcon ਹੀ ਹੱਲ ਕਿਉਂ ਨਹੀਂ

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

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

ਜਦੋਂ ਲੇਬਲ ਸਹੀ ਹੋਵੇ ਅਤੇ ਪਹੁੰਚ ਫਿਰ ਵੀ ਫੇਲ੍ਹ ਹੋਵੇ

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

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

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