MacOS ನಲ್ಲಿ ಪ್ರಕ್ರಿಯೆಗಳು ಮತ್ತು ಕರ್ನಲ್ ವಿಸ್ತರಣೆಗಳನ್ನು ಹೇಗೆ ರಕ್ಷಿಸುವುದು

ಹಲೋ, ಹಬ್ರ್! MacOS ನಲ್ಲಿ ಆಕ್ರಮಣಕಾರರ ದಾಳಿಯಿಂದ ನೀವು ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ಹೇಗೆ ರಕ್ಷಿಸಬಹುದು ಎಂಬುದರ ಕುರಿತು ಇಂದು ನಾನು ಮಾತನಾಡಲು ಬಯಸುತ್ತೇನೆ. ಉದಾಹರಣೆಗೆ, ಇದು ಆಂಟಿವೈರಸ್ ಅಥವಾ ಬ್ಯಾಕಪ್ ಸಿಸ್ಟಮ್‌ಗೆ ಉಪಯುಕ್ತವಾಗಿದೆ, ವಿಶೇಷವಾಗಿ ಮ್ಯಾಕೋಸ್ ಅಡಿಯಲ್ಲಿ ಪ್ರಕ್ರಿಯೆಯನ್ನು "ಕೊಲ್ಲಲು" ಹಲವಾರು ಮಾರ್ಗಗಳಿವೆ. ಕಟ್ ಅಡಿಯಲ್ಲಿ ಈ ಮತ್ತು ರಕ್ಷಣೆ ವಿಧಾನಗಳ ಬಗ್ಗೆ ಓದಿ.

ಪ್ರಕ್ರಿಯೆಯನ್ನು "ಕೊಲ್ಲಲು" ಶ್ರೇಷ್ಠ ಮಾರ್ಗ

ಪ್ರಕ್ರಿಯೆಯನ್ನು "ಕೊಲ್ಲಲು" ಒಂದು ಪ್ರಸಿದ್ಧ ಮಾರ್ಗವೆಂದರೆ ಪ್ರಕ್ರಿಯೆಗೆ SIGKILL ಸಂಕೇತವನ್ನು ಕಳುಹಿಸುವುದು. ಬ್ಯಾಷ್ ಮೂಲಕ ನೀವು ಸ್ಟ್ಯಾಂಡರ್ಡ್ "kill -SIGKILL PID" ಅಥವಾ "pkill -9 NAME" ಅನ್ನು ಕೊಲ್ಲಲು ಕರೆಯಬಹುದು. "ಕಿಲ್" ಆಜ್ಞೆಯು UNIX ನ ದಿನಗಳಿಂದಲೂ ತಿಳಿದುಬಂದಿದೆ ಮತ್ತು ಇದು ಮ್ಯಾಕೋಸ್‌ನಲ್ಲಿ ಮಾತ್ರವಲ್ಲದೆ ಇತರ UNIX-ತರಹದ ವ್ಯವಸ್ಥೆಗಳಲ್ಲಿಯೂ ಲಭ್ಯವಿದೆ.

UNIX-ರೀತಿಯ ವ್ಯವಸ್ಥೆಗಳಲ್ಲಿರುವಂತೆ, ಸಿಗ್‌ಕಿಲ್ ಮತ್ತು ಸಿಗ್‌ಸ್ಟಾಪ್ ಎರಡನ್ನು ಹೊರತುಪಡಿಸಿ ಯಾವುದೇ ಪ್ರಕ್ರಿಯೆಗೆ ಯಾವುದೇ ಸಂಕೇತಗಳನ್ನು ಪ್ರತಿಬಂಧಿಸಲು ಮ್ಯಾಕೋಸ್ ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ಈ ಲೇಖನವು ಪ್ರಾಥಮಿಕವಾಗಿ SIGKILL ಸಿಗ್ನಲ್ ಅನ್ನು ಸಂಕೇತವಾಗಿ ಕೇಂದ್ರೀಕರಿಸುತ್ತದೆ, ಅದು ಪ್ರಕ್ರಿಯೆಯನ್ನು ಕೊಲ್ಲಲು ಕಾರಣವಾಗುತ್ತದೆ.

macOS ವಿಶೇಷತೆಗಳು

MacOS ನಲ್ಲಿ, XNU ಕರ್ನಲ್‌ನಲ್ಲಿನ ಕಿಲ್ ಸಿಸ್ಟಮ್ ಕರೆಯು psignal(SIGKILL,...) ಕಾರ್ಯವನ್ನು ಕರೆಯುತ್ತದೆ. ಸಿಗ್ನಲ್ ಫಂಕ್ಷನ್‌ನಿಂದ ಯೂಸರ್‌ಸ್ಪೇಸ್‌ನಲ್ಲಿ ಯಾವ ಇತರ ಬಳಕೆದಾರ ಕ್ರಿಯೆಗಳನ್ನು ಕರೆಯಬಹುದು ಎಂಬುದನ್ನು ನೋಡಲು ಪ್ರಯತ್ನಿಸೋಣ. ಕರ್ನಲ್‌ನ ಆಂತರಿಕ ಕಾರ್ಯವಿಧಾನಗಳಲ್ಲಿ ಸಿಗ್ನಲ್ ಫಂಕ್ಷನ್‌ಗೆ ಕರೆಗಳನ್ನು ಕಳೆಯೋಣ (ಅವುಗಳು ಕ್ಷುಲ್ಲಕವಾಗಿರಬಹುದು, ಆದರೆ ನಾವು ಅವುಗಳನ್ನು ಮತ್ತೊಂದು ಲೇಖನಕ್ಕೆ ಬಿಡುತ್ತೇವೆ 🙂 - ಸಹಿ ಪರಿಶೀಲನೆ, ಮೆಮೊರಿ ದೋಷಗಳು, ನಿರ್ಗಮನ/ನಿರ್ವಹಣೆಯನ್ನು ಕೊನೆಗೊಳಿಸುವುದು, ಫೈಲ್ ರಕ್ಷಣೆ ಉಲ್ಲಂಘನೆಗಳು, ಇತ್ಯಾದಿ

ಕಾರ್ಯ ಮತ್ತು ಅನುಗುಣವಾದ ಸಿಸ್ಟಮ್ ಕರೆಯೊಂದಿಗೆ ವಿಮರ್ಶೆಯನ್ನು ಪ್ರಾರಂಭಿಸೋಣ ಟರ್ಮಿನೇಟ್_ವಿತ್_ಪೇಲೋಡ್. ಕ್ಲಾಸಿಕ್ ಕಿಲ್ ಕರೆಗೆ ಹೆಚ್ಚುವರಿಯಾಗಿ, ಮ್ಯಾಕೋಸ್ ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್‌ಗೆ ನಿರ್ದಿಷ್ಟವಾದ ಮತ್ತು ಬಿಎಸ್‌ಡಿಯಲ್ಲಿ ಕಂಡುಬರದ ಪರ್ಯಾಯ ವಿಧಾನವಿದೆ ಎಂದು ನೋಡಬಹುದು. ಎರಡೂ ಸಿಸ್ಟಮ್ ಕರೆಗಳ ಕಾರ್ಯಾಚರಣೆಯ ತತ್ವಗಳು ಸಹ ಹೋಲುತ್ತವೆ. ಅವು ಕರ್ನಲ್ ಫಂಕ್ಷನ್ psignal ಗೆ ನೇರ ಕರೆಗಳು. ಪ್ರಕ್ರಿಯೆಯನ್ನು ಕೊಲ್ಲುವ ಮೊದಲು, "ಕ್ಯಾನ್ಸಿಗ್ನಲ್" ಚೆಕ್ ಅನ್ನು ನಡೆಸಲಾಗುತ್ತದೆ - ಪ್ರಕ್ರಿಯೆಯು ಮತ್ತೊಂದು ಪ್ರಕ್ರಿಯೆಗೆ ಸಂಕೇತವನ್ನು ಕಳುಹಿಸಬಹುದೇ ಎಂದು ಗಮನಿಸಿ; ಸಿಸ್ಟಮ್ ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ಕೊಲ್ಲಲು ಯಾವುದೇ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಸಿಸ್ಟಮ್ ಅನುಮತಿಸುವುದಿಲ್ಲ, ಉದಾಹರಣೆಗೆ.

static int
terminate_with_payload_internal(struct proc *cur_proc, int target_pid, uint32_t reason_namespace,
				uint64_t reason_code, user_addr_t payload, uint32_t payload_size,
				user_addr_t reason_string, uint64_t reason_flags)
{
...
	target_proc = proc_find(target_pid);
...
	if (!cansignal(cur_proc, cur_cred, target_proc, SIGKILL)) {
		proc_rele(target_proc);
		return EPERM;
	}
...
	if (target_pid == cur_proc->p_pid) {
		/*
		 * psignal_thread_with_reason() will pend a SIGKILL on the specified thread or
		 * return if the thread and/or task are already terminating. Either way, the
		 * current thread won't return to userspace.
		 */
		psignal_thread_with_reason(target_proc, current_thread(), SIGKILL, signal_reason);
	} else {
		psignal_with_reason(target_proc, SIGKILL, signal_reason);
	}
...
}

ಪ್ರಾರಂಭಿಸಲಾಯಿತು

ಸಿಸ್ಟಮ್ ಪ್ರಾರಂಭದಲ್ಲಿ ಡೀಮನ್‌ಗಳನ್ನು ರಚಿಸಲು ಮತ್ತು ಅವರ ಜೀವಿತಾವಧಿಯನ್ನು ನಿಯಂತ್ರಿಸಲು ಪ್ರಮಾಣಿತ ಮಾರ್ಗವನ್ನು ಪ್ರಾರಂಭಿಸಲಾಗಿದೆ. MacOS 10.10 ವರೆಗಿನ ಲಾಂಚ್‌ಸಿಟಿಎಲ್‌ನ ಹಳೆಯ ಆವೃತ್ತಿಗೆ ಮೂಲಗಳು ಎಂಬುದನ್ನು ದಯವಿಟ್ಟು ಗಮನಿಸಿ, ಕೋಡ್ ಉದಾಹರಣೆಗಳನ್ನು ವಿವರಣಾತ್ಮಕ ಉದ್ದೇಶಗಳಿಗಾಗಿ ಒದಗಿಸಲಾಗಿದೆ. ಆಧುನಿಕ ಲಾಂಚ್ಕ್ಟ್ಲ್ ಎಕ್ಸ್‌ಪಿಸಿ ಮೂಲಕ ಲಾಂಚ್ಡ್ ಸಿಗ್ನಲ್‌ಗಳನ್ನು ಕಳುಹಿಸುತ್ತದೆ, ಲಾಂಚ್ಕ್ಟ್ಲ್ ಲಾಜಿಕ್ ಅನ್ನು ಅದಕ್ಕೆ ಸರಿಸಲಾಗಿದೆ.

ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಹೇಗೆ ನಿಖರವಾಗಿ ನಿಲ್ಲಿಸಲಾಗಿದೆ ಎಂಬುದನ್ನು ನೋಡೋಣ. SIGTERM ಸಂಕೇತವನ್ನು ಕಳುಹಿಸುವ ಮೊದಲು, "proc_terminate" ಸಿಸ್ಟಮ್ ಕರೆಯನ್ನು ಬಳಸಿಕೊಂಡು ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ನಿಲ್ಲಿಸಲು ಪ್ರಯತ್ನಿಸಲಾಗಿದೆ.

<launchctl src/core.c>
...
	error = proc_terminate(j->p, &sig);
	if (error) {
		job_log(j, LOG_ERR | LOG_CONSOLE, "Could not terminate job: %d: %s", error, strerror(error));
		job_log(j, LOG_NOTICE | LOG_CONSOLE, "Using fallback option to terminate job...");
		error = kill2(j->p, SIGTERM);
		if (error) {
			job_log(j, LOG_ERR, "Could not signal job: %d: %s", error, strerror(error));
		} 
...
<>

ಹುಡ್ ಅಡಿಯಲ್ಲಿ, proc_terminate, ಅದರ ಹೆಸರಿನ ಹೊರತಾಗಿಯೂ, SIGTERM ನೊಂದಿಗೆ psignal ಅನ್ನು ಮಾತ್ರವಲ್ಲದೆ SIGKILL ಅನ್ನು ಸಹ ಕಳುಹಿಸಬಹುದು.

ಪರೋಕ್ಷ ಕಿಲ್ - ಸಂಪನ್ಮೂಲ ಮಿತಿ

ಮತ್ತೊಂದು ಸಿಸ್ಟಂ ಕರೆಯಲ್ಲಿ ಹೆಚ್ಚು ಆಸಕ್ತಿದಾಯಕ ಪ್ರಕರಣವನ್ನು ಕಾಣಬಹುದು ಪ್ರಕ್ರಿಯೆ_ನೀತಿ. ಫೈಲ್ ಕ್ಯಾಶಿಂಗ್ ಚಟುವಟಿಕೆಗಳಿಂದ ಸಿಸ್ಟಮ್ ಗಮನಾರ್ಹವಾಗಿ ನಿಧಾನವಾಗದಂತೆ ಸಿಪಿಯು ಸಮಯ ಮತ್ತು ಮೆಮೊರಿ ಕೋಟಾಗಳನ್ನು ಮಿತಿಗೊಳಿಸಲು ಸೂಚ್ಯಂಕಕ್ಕಾಗಿ ಅಪ್ಲಿಕೇಶನ್ ಸಂಪನ್ಮೂಲಗಳಂತಹ ಅಪ್ಲಿಕೇಶನ್ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಮಿತಿಗೊಳಿಸುವುದು ಈ ಸಿಸ್ಟಮ್ ಕರೆಯ ಸಾಮಾನ್ಯ ಬಳಕೆಯಾಗಿದೆ. ಒಂದು ಅಪ್ಲಿಕೇಶನ್ ತನ್ನ ಸಂಪನ್ಮೂಲ ಮಿತಿಯನ್ನು ತಲುಪಿದ್ದರೆ, proc_apply_resource_actions ಕಾರ್ಯದಿಂದ ನೋಡಬಹುದಾದಂತೆ, ಪ್ರಕ್ರಿಯೆಗೆ SIGKILL ಸಂಕೇತವನ್ನು ಕಳುಹಿಸಲಾಗುತ್ತದೆ.

ಈ ಸಿಸ್ಟಂ ಕರೆಯು ಪ್ರಕ್ರಿಯೆಯನ್ನು ಕೊಲ್ಲಬಹುದಾದರೂ, ಸಿಸ್ಟಮ್ ಕರೆಯನ್ನು ಕರೆಯುವ ಪ್ರಕ್ರಿಯೆಯ ಹಕ್ಕುಗಳನ್ನು ಸಿಸ್ಟಮ್ ಸಮರ್ಪಕವಾಗಿ ಪರಿಶೀಲಿಸಲಿಲ್ಲ. ವಾಸ್ತವವಾಗಿ ಪರಿಶೀಲಿಸಲಾಗುತ್ತಿದೆ ಅಸ್ತಿತ್ವದಲ್ಲಿತ್ತು, ಆದರೆ ಈ ಸ್ಥಿತಿಯನ್ನು ಬೈಪಾಸ್ ಮಾಡಲು ಪರ್ಯಾಯ ಫ್ಲ್ಯಾಗ್ PROC_POLICY_ACTION_SET ಅನ್ನು ಬಳಸುವುದು ಸಾಕು.

ಆದ್ದರಿಂದ, ನೀವು ಅಪ್ಲಿಕೇಶನ್‌ನ CPU ಬಳಕೆಯ ಕೋಟಾವನ್ನು "ಮಿತಿಗೊಳಿಸಿದರೆ" (ಉದಾಹರಣೆಗೆ, ಕೇವಲ 1 ns ಅನ್ನು ಚಲಾಯಿಸಲು ಅನುಮತಿಸಿದರೆ), ನಂತರ ನೀವು ಸಿಸ್ಟಮ್‌ನಲ್ಲಿ ಯಾವುದೇ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಕೊಲ್ಲಬಹುದು. ಹೀಗಾಗಿ, ಆಂಟಿವೈರಸ್ ಪ್ರಕ್ರಿಯೆ ಸೇರಿದಂತೆ ಸಿಸ್ಟಂನಲ್ಲಿನ ಯಾವುದೇ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಮಾಲ್ವೇರ್ ಕೊಲ್ಲಬಹುದು. Pid 1 (launchctl) ನೊಂದಿಗೆ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಕೊಲ್ಲುವಾಗ ಉಂಟಾಗುವ ಪರಿಣಾಮವು ಸಹ ಆಸಕ್ತಿದಾಯಕವಾಗಿದೆ - SIGKILL ಸಿಗ್ನಲ್ ಅನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲು ಪ್ರಯತ್ನಿಸುವಾಗ ಕರ್ನಲ್ ಪ್ಯಾನಿಕ್ :)

ಸಮಸ್ಯೆಯನ್ನು ಹೇಗೆ ಪರಿಹರಿಸುವುದು?

ಒಂದು ಪ್ರಕ್ರಿಯೆಯನ್ನು ಕೊಲ್ಲುವುದನ್ನು ತಡೆಯಲು ಅತ್ಯಂತ ಸರಳವಾದ ಮಾರ್ಗವೆಂದರೆ ಸಿಸ್ಟಮ್ ಕರೆ ಟೇಬಲ್‌ನಲ್ಲಿ ಫಂಕ್ಷನ್ ಪಾಯಿಂಟರ್ ಅನ್ನು ಬದಲಾಯಿಸುವುದು. ದುರದೃಷ್ಟವಶಾತ್, ಈ ವಿಧಾನವು ಅನೇಕ ಕಾರಣಗಳಿಗಾಗಿ ಕ್ಷುಲ್ಲಕವಲ್ಲ.

ಮೊದಲಿಗೆ, sysent ನ ಮೆಮೊರಿ ಸ್ಥಳವನ್ನು ನಿಯಂತ್ರಿಸುವ ಚಿಹ್ನೆಯು XNU ಕರ್ನಲ್ ಚಿಹ್ನೆಗೆ ಖಾಸಗಿಯಾಗಿರದೆ, ಕರ್ನಲ್ ಚಿಹ್ನೆಗಳಲ್ಲಿ ಕಂಡುಬರುವುದಿಲ್ಲ. ಕಾರ್ಯವನ್ನು ಕ್ರಿಯಾತ್ಮಕವಾಗಿ ಡಿಸ್ಅಸೆಂಬಲ್ ಮಾಡುವುದು ಮತ್ತು ಅದರಲ್ಲಿ ಪಾಯಿಂಟರ್ ಅನ್ನು ಹುಡುಕುವಂತಹ ಹ್ಯೂರಿಸ್ಟಿಕ್ ಹುಡುಕಾಟ ವಿಧಾನಗಳನ್ನು ನೀವು ಬಳಸಬೇಕಾಗುತ್ತದೆ.

ಎರಡನೆಯದಾಗಿ, ಕೋಷ್ಟಕದಲ್ಲಿನ ನಮೂದುಗಳ ರಚನೆಯು ಕರ್ನಲ್ ಅನ್ನು ಸಂಕಲಿಸಿದ ಧ್ವಜಗಳ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿರುತ್ತದೆ. CONFIG_REQUIRES_U32_MUNGING ಧ್ವಜವನ್ನು ಘೋಷಿಸಿದರೆ, ರಚನೆಯ ಗಾತ್ರವನ್ನು ಬದಲಾಯಿಸಲಾಗುತ್ತದೆ - ಹೆಚ್ಚುವರಿ ಕ್ಷೇತ್ರವನ್ನು ಸೇರಿಸಲಾಗುತ್ತದೆ sy_arg_munge32. ಕರ್ನಲ್ ಅನ್ನು ಯಾವ ಫ್ಲ್ಯಾಗ್‌ನೊಂದಿಗೆ ಸಂಕಲಿಸಲಾಗಿದೆ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸಲು ಹೆಚ್ಚುವರಿ ಪರಿಶೀಲನೆಯನ್ನು ಕೈಗೊಳ್ಳುವುದು ಅವಶ್ಯಕ ಅಥವಾ ಪರ್ಯಾಯವಾಗಿ, ತಿಳಿದಿರುವವರ ವಿರುದ್ಧ ಫಂಕ್ಷನ್ ಪಾಯಿಂಟರ್‌ಗಳನ್ನು ಪರಿಶೀಲಿಸಿ.

struct sysent {         /* system call table */
        sy_call_t       *sy_call;       /* implementing function */
#if CONFIG_REQUIRES_U32_MUNGING || (__arm__ && (__BIGGEST_ALIGNMENT__ > 4))
        sy_munge_t      *sy_arg_munge32; /* system call arguments munger for 32-bit process */
#endif
        int32_t         sy_return_type; /* system call return types */
        int16_t         sy_narg;        /* number of args */
        uint16_t        sy_arg_bytes;   /* Total size of arguments in bytes for
                                         * 32-bit system calls
                                         */
};

ಅದೃಷ್ಟವಶಾತ್, MacOS ನ ಆಧುನಿಕ ಆವೃತ್ತಿಗಳಲ್ಲಿ, ಪ್ರಕ್ರಿಯೆಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು Apple ಹೊಸ API ಅನ್ನು ಒದಗಿಸುತ್ತದೆ. ಎಂಡ್‌ಪಾಯಿಂಟ್ ಸೆಕ್ಯುರಿಟಿ API ಕ್ಲೈಂಟ್‌ಗಳು ಇತರ ಪ್ರಕ್ರಿಯೆಗಳಿಗೆ ಅನೇಕ ವಿನಂತಿಗಳನ್ನು ಅಧಿಕೃತಗೊಳಿಸಲು ಅನುಮತಿಸುತ್ತದೆ. ಹೀಗಾಗಿ, ಮೇಲೆ ತಿಳಿಸಿದ API ಅನ್ನು ಬಳಸಿಕೊಂಡು SIGKILL ಸಿಗ್ನಲ್ ಸೇರಿದಂತೆ ಪ್ರಕ್ರಿಯೆಗಳಿಗೆ ನೀವು ಯಾವುದೇ ಸಂಕೇತಗಳನ್ನು ನಿರ್ಬಂಧಿಸಬಹುದು.

#include <bsm/libbsm.h>
#include <EndpointSecurity/EndpointSecurity.h>
#include <unistd.h>

int main(int argc, const char * argv[]) {
    es_client_t* cli = nullptr;
    {
        auto res = es_new_client(&cli, ^(es_client_t * client, const es_message_t * message) {
            switch (message->event_type) {
                case ES_EVENT_TYPE_AUTH_SIGNAL:
                {
                    auto& msg = message->event.signal;
                    auto target = msg.target;
                    auto& token = target->audit_token;
                    auto pid = audit_token_to_pid(token);
                    printf("signal '%d' sent to pid '%d'n", msg.sig, pid);
                    es_respond_auth_result(client, message, pid == getpid() ? ES_AUTH_RESULT_DENY : ES_AUTH_RESULT_ALLOW, false);
                }
                    break;
                default:
                    break;
            }
        });
    }

    {
        es_event_type_t evs[] = { ES_EVENT_TYPE_AUTH_SIGNAL };
        es_subscribe(cli, evs, sizeof(evs) / sizeof(*evs));
    }

    printf("%dn", getpid());
    sleep(60); // could be replaced with other waiting primitive

    es_unsubscribe_all(cli);
    es_delete_client(cli);

    return 0;
}

ಅಂತೆಯೇ, MAC ನೀತಿಯನ್ನು ಕರ್ನಲ್‌ನಲ್ಲಿ ನೋಂದಾಯಿಸಬಹುದು, ಇದು ಸಿಗ್ನಲ್ ಪ್ರೊಟೆಕ್ಷನ್ ವಿಧಾನವನ್ನು ಒದಗಿಸುತ್ತದೆ (ನೀತಿ proc_check_signal), ಆದರೆ API ಅಧಿಕೃತವಾಗಿ ಬೆಂಬಲಿತವಾಗಿಲ್ಲ.

ಕರ್ನಲ್ ವಿಸ್ತರಣೆ ರಕ್ಷಣೆ

ವ್ಯವಸ್ಥೆಯಲ್ಲಿನ ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ರಕ್ಷಿಸುವುದರ ಜೊತೆಗೆ, ಕರ್ನಲ್ ವಿಸ್ತರಣೆಯನ್ನು ಸ್ವತಃ ರಕ್ಷಿಸುವುದು (ಕೆಕ್ಸ್ಟ್) ಸಹ ಅಗತ್ಯವಾಗಿದೆ. MacOS ಡೆವಲಪರ್‌ಗಳಿಗೆ IOKit ಸಾಧನ ಡ್ರೈವರ್‌ಗಳನ್ನು ಸುಲಭವಾಗಿ ಅಭಿವೃದ್ಧಿಪಡಿಸಲು ಚೌಕಟ್ಟನ್ನು ಒದಗಿಸುತ್ತದೆ. ಸಾಧನಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು ಪರಿಕರಗಳನ್ನು ಒದಗಿಸುವುದರ ಜೊತೆಗೆ, IOKit C++ ತರಗತಿಗಳ ನಿದರ್ಶನಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಡ್ರೈವರ್ ಪೇರಿಸುವಿಕೆಗೆ ವಿಧಾನಗಳನ್ನು ಒದಗಿಸುತ್ತದೆ. ಕರ್ನಲ್-ಯೂಸರ್‌ಸ್ಪೇಸ್ ಸಂಬಂಧವನ್ನು ಸ್ಥಾಪಿಸಲು ಯೂಸರ್‌ಸ್ಪೇಸ್‌ನಲ್ಲಿರುವ ಅಪ್ಲಿಕೇಶನ್ ವರ್ಗದ ನೋಂದಾಯಿತ ನಿದರ್ಶನವನ್ನು "ಹುಡುಕಲು" ಸಾಧ್ಯವಾಗುತ್ತದೆ.

ಸಿಸ್ಟಂನಲ್ಲಿ ವರ್ಗ ನಿದರ್ಶನಗಳ ಸಂಖ್ಯೆಯನ್ನು ಪತ್ತೆಹಚ್ಚಲು, ioclasscount ಸೌಲಭ್ಯವಿದೆ.

my_kext_ioservice = 1
my_kext_iouserclient = 1

ಡ್ರೈವರ್ ಸ್ಟ್ಯಾಕ್‌ನೊಂದಿಗೆ ನೋಂದಾಯಿಸಲು ಬಯಸುವ ಯಾವುದೇ ಕರ್ನಲ್ ವಿಸ್ತರಣೆಯು IOService ನಿಂದ ಆನುವಂಶಿಕವಾಗಿ ಪಡೆಯುವ ವರ್ಗವನ್ನು ಘೋಷಿಸಬೇಕು, ಉದಾಹರಣೆಗೆ my_kext_ioservice ಈ ಸಂದರ್ಭದಲ್ಲಿ. ಬಳಕೆದಾರ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಸಂಪರ್ಕಿಸುವುದು IOUserClient ನಿಂದ ಆನುವಂಶಿಕವಾಗಿ ಪಡೆಯುವ ವರ್ಗದ ಹೊಸ ನಿದರ್ಶನದ ರಚನೆಗೆ ಕಾರಣವಾಗುತ್ತದೆ, ಉದಾಹರಣೆಗೆ my_kext_iouserclient.

ಸಿಸ್ಟಂನಿಂದ ಚಾಲಕವನ್ನು ಇಳಿಸಲು ಪ್ರಯತ್ನಿಸುವಾಗ (kextunload ಆಜ್ಞೆ), "bool terminate (IOOptionBits ಆಯ್ಕೆಗಳು)" ವರ್ಚುವಲ್ ಕಾರ್ಯವನ್ನು ಕರೆಯಲಾಗುತ್ತದೆ. ಕೆಕ್ಸ್‌ಟುನ್‌ಲೋಡ್ ಅನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಲು ಅನ್‌ಲೋಡ್ ಮಾಡಲು ಪ್ರಯತ್ನಿಸುವಾಗ ಮುಕ್ತಾಯಗೊಳಿಸಲು ಕರೆಯಲ್ಲಿ ತಪ್ಪು ಎಂದು ಹಿಂತಿರುಗಿಸಲು ಸಾಕು.

bool Kext::terminate(IOOptionBits options)
{

  if (!IsUnloadAllowed)
  {
    // Unload is not allowed, returning false
    return false;
  }

  return super::terminate(options);
}

ಲೋಡ್ ಮಾಡುವಾಗ IOUserClient ಮೂಲಕ IsUnloadAllowed ಫ್ಲ್ಯಾಗ್ ಅನ್ನು ಹೊಂದಿಸಬಹುದು. ಡೌನ್‌ಲೋಡ್ ಮಿತಿ ಇದ್ದಾಗ, kextunload ಆಜ್ಞೆಯು ಈ ಕೆಳಗಿನ ಔಟ್‌ಪುಟ್ ಅನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತದೆ:

admin@admins-Mac drivermanager % sudo kextunload ./test.kext
Password:
(kernel) Can't remove kext my.kext.test; services failed to terminate - 0xe00002c7.
Failed to unload my.kext.test - (iokit/common) unsupported function.

IOUserClient ಗೆ ಇದೇ ರೀತಿಯ ರಕ್ಷಣೆಯನ್ನು ಮಾಡಬೇಕು. "IOCatalogueTerminate(mach_port_t, uint32_t flag, io_name_t ವಿವರಣೆ) IOKitLib ಯೂಸರ್‌ಸ್ಪೇಸ್ ಕಾರ್ಯವನ್ನು ಬಳಸಿಕೊಂಡು ತರಗತಿಗಳ ನಿದರ್ಶನಗಳನ್ನು ಅನ್‌ಲೋಡ್ ಮಾಡಬಹುದು. ಯೂಸರ್‌ಸ್ಪೇಸ್ ಅಪ್ಲಿಕೇಶನ್ “ಡೈಸ್” ಆಗುವವರೆಗೆ “ಟರ್ಮಿನೇಟ್” ಆಜ್ಞೆಯನ್ನು ಕರೆಯುವಾಗ ನೀವು ತಪ್ಪನ್ನು ಹಿಂತಿರುಗಿಸಬಹುದು, ಅಂದರೆ “ಕ್ಲೈಂಟ್ ಡೈಡ್” ಕಾರ್ಯವನ್ನು ಕರೆಯಲಾಗುವುದಿಲ್ಲ.

ಫೈಲ್ ರಕ್ಷಣೆ

ಫೈಲ್‌ಗಳನ್ನು ರಕ್ಷಿಸಲು, ಕೌತ್ API ಅನ್ನು ಬಳಸುವುದು ಸಾಕು, ಇದು ಫೈಲ್‌ಗಳಿಗೆ ಪ್ರವೇಶವನ್ನು ನಿರ್ಬಂಧಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. Apple ವ್ಯಾಪ್ತಿಯ ವಿವಿಧ ಈವೆಂಟ್‌ಗಳ ಕುರಿತು ಡೆವಲಪರ್‌ಗಳಿಗೆ ಅಧಿಸೂಚನೆಗಳನ್ನು ಒದಗಿಸುತ್ತದೆ; ನಮಗೆ, KAUTH_VNODE_DELETE, KAUTH_VNODE_WRITE_DATA ಮತ್ತು KAUTH_VNODE_DELETE_CHILD ಕಾರ್ಯಾಚರಣೆಗಳು ಮುಖ್ಯವಾಗಿವೆ. ಫೈಲ್‌ಗಳಿಗೆ ಪ್ರವೇಶವನ್ನು ನಿರ್ಬಂಧಿಸಲು ಸುಲಭವಾದ ಮಾರ್ಗವೆಂದರೆ ಮಾರ್ಗದ ಮೂಲಕ - ನಾವು ಫೈಲ್‌ಗೆ ಮಾರ್ಗವನ್ನು ಪಡೆಯಲು ಮತ್ತು ಪಥ ಪೂರ್ವಪ್ರತ್ಯಯವನ್ನು ಹೋಲಿಸಲು “vn_getpath” API ಅನ್ನು ಬಳಸುತ್ತೇವೆ. ಫೈಲ್ ಫೋಲ್ಡರ್ ಮಾರ್ಗಗಳ ಮರುನಾಮಕರಣವನ್ನು ಆಪ್ಟಿಮೈಸ್ ಮಾಡಲು, ಸಿಸ್ಟಮ್ ಪ್ರತಿ ಫೈಲ್‌ಗೆ ಪ್ರವೇಶವನ್ನು ಅನುಮತಿಸುವುದಿಲ್ಲ, ಆದರೆ ಮರುಹೆಸರಿಸಲಾದ ಫೋಲ್ಡರ್‌ಗೆ ಮಾತ್ರ. ಪೋಷಕ ಮಾರ್ಗವನ್ನು ಹೋಲಿಸುವುದು ಮತ್ತು ಅದಕ್ಕಾಗಿ KAUTH_VNODE_DELETE ಅನ್ನು ನಿರ್ಬಂಧಿಸುವುದು ಅವಶ್ಯಕ.

ಪೂರ್ವಪ್ರತ್ಯಯಗಳ ಸಂಖ್ಯೆ ಹೆಚ್ಚಾದಂತೆ ಈ ವಿಧಾನದ ಅನನುಕೂಲವೆಂದರೆ ಕಡಿಮೆ ಕಾರ್ಯಕ್ಷಮತೆಯಾಗಿರಬಹುದು. ಹೋಲಿಕೆಯು O(ಪೂರ್ವಪ್ರತ್ಯಯ*ಉದ್ದ)ಕ್ಕೆ ಸಮವಾಗಿಲ್ಲ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು, ಪೂರ್ವಪ್ರತ್ಯಯವು ಪೂರ್ವಪ್ರತ್ಯಯಗಳ ಸಂಖ್ಯೆ, ಉದ್ದವು ಸ್ಟ್ರಿಂಗ್‌ನ ಉದ್ದವಾಗಿದೆ, ನೀವು ಪೂರ್ವಪ್ರತ್ಯಯಗಳಿಂದ ನಿರ್ಮಿಸಲಾದ ನಿರ್ಣಾಯಕ ಪರಿಮಿತ ಆಟೊಮ್ಯಾಟನ್ (DFA) ಅನ್ನು ಬಳಸಬಹುದು.

ಕೊಟ್ಟಿರುವ ಪೂರ್ವಪ್ರತ್ಯಯಗಳಿಗೆ ಡಿಎಫ್‌ಎ ನಿರ್ಮಿಸುವ ವಿಧಾನವನ್ನು ಪರಿಗಣಿಸೋಣ. ಪ್ರತಿ ಪೂರ್ವಪ್ರತ್ಯಯದ ಆರಂಭದಲ್ಲಿ ನಾವು ಕರ್ಸರ್ಗಳನ್ನು ಪ್ರಾರಂಭಿಸುತ್ತೇವೆ. ಎಲ್ಲಾ ಕರ್ಸರ್‌ಗಳು ಒಂದೇ ಅಕ್ಷರವನ್ನು ಸೂಚಿಸಿದರೆ, ಪ್ರತಿ ಕರ್ಸರ್ ಅನ್ನು ಒಂದು ಅಕ್ಷರದಿಂದ ಹೆಚ್ಚಿಸಿ ಮತ್ತು ಅದೇ ಸಾಲಿನ ಉದ್ದವು ಒಂದರಿಂದ ಹೆಚ್ಚಾಗಿರುತ್ತದೆ ಎಂಬುದನ್ನು ನೆನಪಿಡಿ. ವಿಭಿನ್ನ ಚಿಹ್ನೆಗಳೊಂದಿಗೆ ಎರಡು ಕರ್ಸರ್‌ಗಳು ಇದ್ದರೆ, ಕರ್ಸರ್‌ಗಳನ್ನು ಅವರು ಸೂಚಿಸುವ ಚಿಹ್ನೆಯ ಪ್ರಕಾರ ಗುಂಪುಗಳಾಗಿ ವಿಂಗಡಿಸಿ ಮತ್ತು ಪ್ರತಿ ಗುಂಪಿಗೆ ಅಲ್ಗಾರಿದಮ್ ಅನ್ನು ಪುನರಾವರ್ತಿಸಿ.

ಮೊದಲ ಸಂದರ್ಭದಲ್ಲಿ (ಕರ್ಸರ್‌ಗಳ ಅಡಿಯಲ್ಲಿರುವ ಎಲ್ಲಾ ಅಕ್ಷರಗಳು ಒಂದೇ ಆಗಿರುತ್ತವೆ), ನಾವು ಒಂದೇ ಸಾಲಿನಲ್ಲಿ ಒಂದೇ ಒಂದು ಪರಿವರ್ತನೆಯನ್ನು ಹೊಂದಿರುವ ಡಿಎಫ್‌ಎ ಸ್ಥಿತಿಯನ್ನು ಪಡೆಯುತ್ತೇವೆ. ಎರಡನೆಯ ಸಂದರ್ಭದಲ್ಲಿ, ಕಾರ್ಯವನ್ನು ಪುನರಾವರ್ತಿತವಾಗಿ ಕರೆಯುವ ಮೂಲಕ ಪಡೆದ ನಂತರದ ಸ್ಥಿತಿಗಳಿಗೆ ಗಾತ್ರ 256 (ಅಕ್ಷರಗಳ ಸಂಖ್ಯೆ ಮತ್ತು ಗರಿಷ್ಠ ಸಂಖ್ಯೆಯ ಗುಂಪುಗಳು) ಪರಿವರ್ತನೆಗಳ ಕೋಷ್ಟಕವನ್ನು ನಾವು ಪಡೆಯುತ್ತೇವೆ.

ಒಂದು ಉದಾಹರಣೆಯನ್ನು ನೋಡೋಣ. ಪೂರ್ವಪ್ರತ್ಯಯಗಳ ಗುಂಪಿಗೆ (“/foo/bar/tmp/”, “/var/db/foo/”, “/foo/bar/aba/”, “foo/bar/aac/”) ನೀವು ಈ ಕೆಳಗಿನವುಗಳನ್ನು ಪಡೆಯಬಹುದು DFA. ಅಂಕಿ ಅಂಶವು ಇತರ ರಾಜ್ಯಗಳಿಗೆ ಕಾರಣವಾಗುವ ಪರಿವರ್ತನೆಗಳನ್ನು ಮಾತ್ರ ತೋರಿಸುತ್ತದೆ; ಇತರ ಪರಿವರ್ತನೆಗಳು ಅಂತಿಮವಾಗುವುದಿಲ್ಲ.

DKA ರಾಜ್ಯಗಳ ಮೂಲಕ ಹೋಗುವಾಗ, 3 ಪ್ರಕರಣಗಳು ಇರಬಹುದು.

1. ಅಂತಿಮ ಸ್ಥಿತಿಯನ್ನು ತಲುಪಲಾಗಿದೆ - ಮಾರ್ಗವನ್ನು ರಕ್ಷಿಸಲಾಗಿದೆ, ನಾವು KAUTH_VNODE_DELETE, KAUTH_VNODE_WRITE_DATA ಮತ್ತು KAUTH_VNODE_DELETE_CHILD ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ಮಿತಿಗೊಳಿಸುತ್ತೇವೆ
2. ಅಂತಿಮ ಸ್ಥಿತಿಯನ್ನು ತಲುಪಿಲ್ಲ, ಆದರೆ ಮಾರ್ಗವು "ಮುಕ್ತಾಯಗೊಂಡಿದೆ" (ಶೂನ್ಯ ಟರ್ಮಿನೇಟರ್ ತಲುಪಿದೆ) - ಮಾರ್ಗವು ಮೂಲವಾಗಿದೆ, KAUTH_VNODE_DELETE ಅನ್ನು ಮಿತಿಗೊಳಿಸುವುದು ಅವಶ್ಯಕ. vnode ಒಂದು ಫೋಲ್ಡರ್ ಆಗಿದ್ದರೆ, ನೀವು ಕೊನೆಯಲ್ಲಿ '/' ಅನ್ನು ಸೇರಿಸಬೇಕಾಗುತ್ತದೆ, ಇಲ್ಲದಿದ್ದರೆ ಅದು ತಪ್ಪಾಗಿರುವ "/for/bar/t" ಫೈಲ್‌ಗೆ ಮಿತಿಗೊಳಿಸಬಹುದು.
3. ಅಂತಿಮ ಸ್ಥಿತಿಯನ್ನು ತಲುಪಲಿಲ್ಲ, ಮಾರ್ಗವು ಕೊನೆಗೊಂಡಿಲ್ಲ. ಯಾವುದೇ ಪೂರ್ವಪ್ರತ್ಯಯಗಳು ಇದಕ್ಕೆ ಹೊಂದಿಕೆಯಾಗುವುದಿಲ್ಲ, ನಾವು ನಿರ್ಬಂಧಗಳನ್ನು ಪರಿಚಯಿಸುವುದಿಲ್ಲ.

ತೀರ್ಮಾನಕ್ಕೆ

ಬಳಕೆದಾರ ಮತ್ತು ಅವನ ಡೇಟಾದ ಸುರಕ್ಷತೆಯ ಮಟ್ಟವನ್ನು ಹೆಚ್ಚಿಸುವುದು ಅಭಿವೃದ್ಧಿಪಡಿಸುತ್ತಿರುವ ಭದ್ರತಾ ಪರಿಹಾರಗಳ ಗುರಿಯಾಗಿದೆ. ಒಂದೆಡೆ, ಅಕ್ರೊನಿಸ್ ಸಾಫ್ಟ್‌ವೇರ್ ಉತ್ಪನ್ನದ ಅಭಿವೃದ್ಧಿಯಿಂದ ಈ ಗುರಿಯನ್ನು ಸಾಧಿಸಲಾಗುತ್ತದೆ, ಇದು ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್ ಸ್ವತಃ "ದುರ್ಬಲ" ಆಗಿರುವ ದುರ್ಬಲತೆಗಳನ್ನು ಮುಚ್ಚುತ್ತದೆ. ಮತ್ತೊಂದೆಡೆ, OS ಭಾಗದಲ್ಲಿ ಸುಧಾರಿಸಬಹುದಾದ ಭದ್ರತಾ ಅಂಶಗಳನ್ನು ಬಲಪಡಿಸುವುದನ್ನು ನಾವು ನಿರ್ಲಕ್ಷಿಸಬಾರದು, ವಿಶೇಷವಾಗಿ ಅಂತಹ ದುರ್ಬಲತೆಗಳನ್ನು ಮುಚ್ಚುವುದರಿಂದ ಉತ್ಪನ್ನವಾಗಿ ನಮ್ಮ ಸ್ವಂತ ಸ್ಥಿರತೆಯನ್ನು ಹೆಚ್ಚಿಸುತ್ತದೆ. ದುರ್ಬಲತೆಯನ್ನು Apple ಉತ್ಪನ್ನ ಭದ್ರತಾ ತಂಡಕ್ಕೆ ವರದಿ ಮಾಡಲಾಗಿದೆ ಮತ್ತು ಇದನ್ನು macOS 10.14.5 (https://support.apple.com/en-gb/HT210119) ನಲ್ಲಿ ಸರಿಪಡಿಸಲಾಗಿದೆ.

ನಿಮ್ಮ ಉಪಯುಕ್ತತೆಯನ್ನು ಅಧಿಕೃತವಾಗಿ ಕರ್ನಲ್‌ನಲ್ಲಿ ಸ್ಥಾಪಿಸಿದ್ದರೆ ಮಾತ್ರ ಇದೆಲ್ಲವನ್ನೂ ಮಾಡಬಹುದು. ಅಂದರೆ, ಬಾಹ್ಯ ಮತ್ತು ಅನಗತ್ಯ ಸಾಫ್ಟ್‌ವೇರ್‌ಗಳಿಗೆ ಅಂತಹ ಯಾವುದೇ ಲೋಪದೋಷಗಳಿಲ್ಲ. ಆದಾಗ್ಯೂ, ನೀವು ನೋಡುವಂತೆ, ಆಂಟಿವೈರಸ್ ಮತ್ತು ಬ್ಯಾಕಪ್ ಸಿಸ್ಟಮ್‌ಗಳಂತಹ ಕಾನೂನುಬದ್ಧ ಕಾರ್ಯಕ್ರಮಗಳನ್ನು ರಕ್ಷಿಸಲು ಸಹ ಕೆಲಸ ಮಾಡುವ ಅಗತ್ಯವಿದೆ. ಆದರೆ ಈಗ ಮ್ಯಾಕೋಸ್‌ಗಾಗಿ ಹೊಸ ಅಕ್ರೊನಿಸ್ ಉತ್ಪನ್ನಗಳು ಸಿಸ್ಟಮ್‌ನಿಂದ ಇಳಿಸುವಿಕೆಯ ವಿರುದ್ಧ ಹೆಚ್ಚುವರಿ ರಕ್ಷಣೆಯನ್ನು ಹೊಂದಿವೆ.

ಮೂಲ: www.habr.com