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 ಅನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಬೇಡಿ. ಎರಡೂ ಶಾರ್ಟ್ಕಟ್ಗಳು ಕೆಲಸ ಮಾಡುತ್ತಿರುವಂತೆ ಕಾಣುವ ವ್ಯವಸ್ಥೆ ಮತ್ತು ಯಾರೂ ವಿವರಿಸಲಾಗದ ಭದ್ರತಾ ನಿಲುವನ್ನು ನೀಡುತ್ತವೆ. ಸಣ್ಣ ತನಿಖೆ ಎರಡಕ್ಕಿಂತಲೂ ಉತ್ತಮ.