ਮੈਕੋਸ 'ਤੇ ਪ੍ਰਕਿਰਿਆਵਾਂ ਅਤੇ ਕਰਨਲ ਐਕਸਟੈਂਸ਼ਨਾਂ ਨੂੰ ਕਿਵੇਂ ਸੁਰੱਖਿਅਤ ਕਰਨਾ ਹੈ

ਹੈਲੋ, ਹੈਬਰ! ਅੱਜ ਮੈਂ ਇਸ ਬਾਰੇ ਗੱਲ ਕਰਨਾ ਚਾਹਾਂਗਾ ਕਿ ਤੁਸੀਂ macOS ਵਿੱਚ ਹਮਲਾਵਰਾਂ ਦੇ ਹਮਲਿਆਂ ਤੋਂ ਪ੍ਰਕਿਰਿਆਵਾਂ ਦੀ ਰੱਖਿਆ ਕਿਵੇਂ ਕਰ ਸਕਦੇ ਹੋ। ਉਦਾਹਰਨ ਲਈ, ਇਹ ਇੱਕ ਐਂਟੀਵਾਇਰਸ ਜਾਂ ਬੈਕਅੱਪ ਸਿਸਟਮ ਲਈ ਲਾਭਦਾਇਕ ਹੈ, ਖਾਸ ਕਰਕੇ ਕਿਉਂਕਿ ਮੈਕੋਸ ਦੇ ਅਧੀਨ ਇੱਕ ਪ੍ਰਕਿਰਿਆ ਨੂੰ "ਮਾਰਨ" ਦੇ ਕਈ ਤਰੀਕੇ ਹਨ। ਇਸ ਬਾਰੇ ਅਤੇ ਕੱਟ ਦੇ ਅਧੀਨ ਸੁਰੱਖਿਆ ਦੇ ਤਰੀਕਿਆਂ ਬਾਰੇ ਪੜ੍ਹੋ।

ਇੱਕ ਪ੍ਰਕਿਰਿਆ ਨੂੰ "ਮਾਰਨ" ਦਾ ਕਲਾਸਿਕ ਤਰੀਕਾ

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

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

macOS ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ

ਮੈਕੋਸ ਉੱਤੇ, XNU ਕਰਨਲ ਵਿੱਚ ਕਿੱਲ ਸਿਸਟਮ ਕਾਲ psignal(SIGKILL,...) ਫੰਕਸ਼ਨ ਨੂੰ ਕਾਲ ਕਰਦੀ ਹੈ। ਆਉ ਇਹ ਦੇਖਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੀਏ ਕਿ ਯੂਜ਼ਰਸਪੇਸ ਵਿੱਚ ਹੋਰ ਉਪਭੋਗਤਾ ਕਿਰਿਆਵਾਂ ਨੂੰ psignal ਫੰਕਸ਼ਨ ਦੁਆਰਾ ਕਿਹਾ ਜਾ ਸਕਦਾ ਹੈ। ਆਉ ਕਰਨਲ ਦੇ ਅੰਦਰੂਨੀ ਮਕੈਨਿਜ਼ਮ ਵਿੱਚ ਸਿਗਨਲ ਫੰਕਸ਼ਨ ਲਈ ਕਾਲਾਂ ਨੂੰ ਖਤਮ ਕਰੀਏ (ਹਾਲਾਂਕਿ ਉਹ ਗੈਰ-ਮਾਮੂਲੀ ਹੋ ਸਕਦੇ ਹਨ, ਅਸੀਂ ਉਹਨਾਂ ਨੂੰ ਇੱਕ ਹੋਰ ਲੇਖ ਲਈ ਛੱਡ ਦੇਵਾਂਗੇ 🙂 - ਦਸਤਖਤ ਤਸਦੀਕ, ਮੈਮੋਰੀ ਗਲਤੀਆਂ, ਐਗਜ਼ਿਟ/ਟਰਮੀਨੇਟ ਹੈਂਡਲਿੰਗ, ਫਾਈਲ ਸੁਰੱਖਿਆ ਉਲੰਘਣਾਵਾਂ, ਆਦਿ .

ਆਉ ਫੰਕਸ਼ਨ ਅਤੇ ਸੰਬੰਧਿਤ ਸਿਸਟਮ ਕਾਲ ਨਾਲ ਸਮੀਖਿਆ ਸ਼ੁਰੂ ਕਰੀਏ ਟਰਮੀਨੇਟ_ਵਿਦ_ਪੇਲੋਡ. ਇਹ ਦੇਖਿਆ ਜਾ ਸਕਦਾ ਹੈ ਕਿ ਕਲਾਸਿਕ ਕਿੱਲ ਕਾਲ ਤੋਂ ਇਲਾਵਾ, ਇੱਕ ਵਿਕਲਪਿਕ ਪਹੁੰਚ ਹੈ ਜੋ ਮੈਕੋਸ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਲਈ ਵਿਸ਼ੇਸ਼ ਹੈ ਅਤੇ BSD ਵਿੱਚ ਨਹੀਂ ਮਿਲਦੀ ਹੈ। ਦੋਵੇਂ ਸਿਸਟਮ ਕਾਲਾਂ ਦੇ ਓਪਰੇਟਿੰਗ ਸਿਧਾਂਤ ਵੀ ਸਮਾਨ ਹਨ। ਇਹ ਕਰਨਲ ਫੰਕਸ਼ਨ 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 ਤੱਕ ਲਾਂਚctl ਦੇ ਪੁਰਾਣੇ ਸੰਸਕਰਣ ਲਈ ਹਨ, ਕੋਡ ਦੀਆਂ ਉਦਾਹਰਣਾਂ ਵਿਆਖਿਆਤਮਕ ਉਦੇਸ਼ਾਂ ਲਈ ਪ੍ਰਦਾਨ ਕੀਤੀਆਂ ਗਈਆਂ ਹਨ। ਆਧੁਨਿਕ launchctl XPC ਰਾਹੀਂ ਲਾਂਚਡ ਸਿਗਨਲ ਭੇਜਦਾ ਹੈ, ਲਾਂਚਕਟਲ ਤਰਕ ਨੂੰ ਇਸ ਵਿੱਚ ਭੇਜਿਆ ਗਿਆ ਹੈ।

ਆਓ ਦੇਖੀਏ ਕਿ ਐਪਲੀਕੇਸ਼ਨਾਂ ਨੂੰ ਕਿਵੇਂ ਰੋਕਿਆ ਜਾਂਦਾ ਹੈ। 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 ਵੀ ਭੇਜ ਸਕਦਾ ਹੈ।

ਅਸਿੱਧੇ ਕਤਲ - ਸਰੋਤ ਸੀਮਾ

ਇੱਕ ਹੋਰ ਦਿਲਚਸਪ ਕੇਸ ਇੱਕ ਹੋਰ ਸਿਸਟਮ ਕਾਲ ਵਿੱਚ ਦੇਖਿਆ ਜਾ ਸਕਦਾ ਹੈ ਪ੍ਰਕਿਰਿਆ_ਨੀਤੀ. ਇਸ ਸਿਸਟਮ ਕਾਲ ਦੀ ਇੱਕ ਆਮ ਵਰਤੋਂ ਐਪਲੀਕੇਸ਼ਨ ਸਰੋਤਾਂ ਨੂੰ ਸੀਮਤ ਕਰਨਾ ਹੈ, ਜਿਵੇਂ ਕਿ ਇੱਕ ਸੂਚਕਾਂਕ ਲਈ CPU ਸਮਾਂ ਅਤੇ ਮੈਮੋਰੀ ਕੋਟਾ ਸੀਮਿਤ ਕਰਨਾ ਤਾਂ ਜੋ ਸਿਸਟਮ ਫਾਈਲ ਕੈਚਿੰਗ ਗਤੀਵਿਧੀਆਂ ਦੁਆਰਾ ਮਹੱਤਵਪੂਰਨ ਤੌਰ 'ਤੇ ਹੌਲੀ ਨਾ ਹੋ ਜਾਵੇ। ਜੇਕਰ ਕੋਈ ਐਪਲੀਕੇਸ਼ਨ ਆਪਣੀ ਸਰੋਤ ਸੀਮਾ 'ਤੇ ਪਹੁੰਚ ਗਈ ਹੈ, ਜਿਵੇਂ ਕਿ proc_apply_resource_actions ਫੰਕਸ਼ਨ ਤੋਂ ਦੇਖਿਆ ਜਾ ਸਕਦਾ ਹੈ, ਇੱਕ SIGKILL ਸਿਗਨਲ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਭੇਜਿਆ ਜਾਂਦਾ ਹੈ।

ਹਾਲਾਂਕਿ ਇਹ ਸਿਸਟਮ ਕਾਲ ਸੰਭਾਵੀ ਤੌਰ 'ਤੇ ਇੱਕ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਖਤਮ ਕਰ ਸਕਦੀ ਹੈ, ਸਿਸਟਮ ਨੇ ਸਿਸਟਮ ਕਾਲ ਨੂੰ ਕਾਲ ਕਰਨ ਵਾਲੀ ਪ੍ਰਕਿਰਿਆ ਦੇ ਅਧਿਕਾਰਾਂ ਦੀ ਢੁਕਵੀਂ ਜਾਂਚ ਨਹੀਂ ਕੀਤੀ। ਅਸਲ ਵਿੱਚ ਜਾਂਚ ਕਰ ਰਿਹਾ ਹੈ ਮੌਜੂਦ ਸੀ, ਪਰ ਇਸ ਸਥਿਤੀ ਨੂੰ ਬਾਈਪਾਸ ਕਰਨ ਲਈ ਵਿਕਲਪਕ ਫਲੈਗ PROC_POLICY_ACTION_SET ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਕਾਫ਼ੀ ਹੈ।

ਇਸ ਲਈ, ਜੇਕਰ ਤੁਸੀਂ ਐਪਲੀਕੇਸ਼ਨ ਦੇ CPU ਵਰਤੋਂ ਕੋਟੇ ਨੂੰ "ਸੀਮਿਤ" ਕਰਦੇ ਹੋ (ਉਦਾਹਰਣ ਵਜੋਂ, ਸਿਰਫ 1 ns ਨੂੰ ਚੱਲਣ ਦਿਓ), ਤਾਂ ਤੁਸੀਂ ਸਿਸਟਮ ਵਿੱਚ ਕਿਸੇ ਵੀ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਖਤਮ ਕਰ ਸਕਦੇ ਹੋ। ਇਸ ਤਰ੍ਹਾਂ, ਮਾਲਵੇਅਰ ਐਂਟੀਵਾਇਰਸ ਪ੍ਰਕਿਰਿਆ ਸਮੇਤ ਸਿਸਟਮ 'ਤੇ ਕਿਸੇ ਵੀ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਖਤਮ ਕਰ ਸਕਦਾ ਹੈ। ਇਹ ਵੀ ਦਿਲਚਸਪ ਪ੍ਰਭਾਵ ਹੈ ਜੋ ਪਿਡ 1 (ਲਾਂਚਸੀਟੀਐਲ) - ਸਿਗਕਿੱਲ ਸਿਗਨਲ ਦੀ ਪ੍ਰਕਿਰਿਆ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਵੇਲੇ ਕਰਨਲ ਪੈਨਿਕ ਨਾਲ ਇੱਕ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਖਤਮ ਕਰਨ ਵੇਲੇ ਹੁੰਦਾ ਹੈ :)

ਸਮੱਸਿਆ ਨੂੰ ਕਿਵੇਂ ਹੱਲ ਕਰਨਾ ਹੈ?

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

ਪਹਿਲਾਂ, ਪ੍ਰਤੀਕ ਜੋ ਕਿ 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
                                         */
};

ਖੁਸ਼ਕਿਸਮਤੀ ਨਾਲ, ਮੈਕੋਸ ਦੇ ਆਧੁਨਿਕ ਸੰਸਕਰਣਾਂ ਵਿੱਚ, ਐਪਲ ਪ੍ਰਕਿਰਿਆਵਾਂ ਨਾਲ ਕੰਮ ਕਰਨ ਲਈ ਇੱਕ ਨਵਾਂ 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 ਕਮਾਂਡ) ਤੋਂ ਡਰਾਈਵਰ ਨੂੰ ਅਨਲੋਡ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਸਮੇਂ, ਵਰਚੁਅਲ ਫੰਕਸ਼ਨ “ਬੂਲ ਟਰਮੀਨੇਟ(IOOptionBits ਵਿਕਲਪ)” ਕਿਹਾ ਜਾਂਦਾ ਹੈ। ਕੇਕਸਟੂਨਲੋਡ ਨੂੰ ਅਯੋਗ ਕਰਨ ਲਈ ਅਨਲੋਡ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਸਮੇਂ ਸਮਾਪਤ ਕਰਨ ਲਈ ਕਾਲ 'ਤੇ ਗਲਤ ਵਾਪਸ ਕਰਨਾ ਕਾਫ਼ੀ ਹੈ।

bool Kext::terminate(IOOptionBits options)
{

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

  return super::terminate(options);
}

ਲੋਡ ਕਰਨ ਵੇਲੇ IsUnloadAllowed ਫਲੈਗ ਨੂੰ IOUserClient ਦੁਆਰਾ ਸੈੱਟ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਜਦੋਂ ਇੱਕ ਡਾਊਨਲੋਡ ਸੀਮਾ ਹੁੰਦੀ ਹੈ, ਤਾਂ 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 ਲਈ ਕੀਤੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ। IOKitLib ਯੂਜ਼ਰਸਪੇਸ ਫੰਕਸ਼ਨ "IOCatalogueTerminate(mach_port_t, uint32_t ਫਲੈਗ, io_name_t ਵਰਣਨ);" ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਕਲਾਸਾਂ ਦੀਆਂ ਉਦਾਹਰਣਾਂ ਨੂੰ ਅਨਲੋਡ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਤੁਸੀਂ "ਟਰਮੀਨੇਟ" ਕਮਾਂਡ ਨੂੰ ਕਾਲ ਕਰਨ ਵੇਲੇ ਗਲਤ ਵਾਪਸ ਕਰ ਸਕਦੇ ਹੋ ਜਦੋਂ ਤੱਕ ਯੂਜ਼ਰਸਪੇਸ ਐਪਲੀਕੇਸ਼ਨ "ਡਾਈਜ਼" ਨਹੀਂ ਹੋ ਜਾਂਦੀ, ਯਾਨੀ ਕਿ "ਕਲਾਇੰਟਡਾਈਡ" ਫੰਕਸ਼ਨ ਨੂੰ ਕਾਲ ਨਹੀਂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।

ਫਾਈਲ ਸੁਰੱਖਿਆ

ਫਾਈਲਾਂ ਦੀ ਸੁਰੱਖਿਆ ਲਈ, Kauth API ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਕਾਫ਼ੀ ਹੈ, ਜੋ ਤੁਹਾਨੂੰ ਫਾਈਲਾਂ ਤੱਕ ਪਹੁੰਚ ਨੂੰ ਸੀਮਤ ਕਰਨ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ। Apple ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਸਕੋਪ ਵਿੱਚ ਵੱਖ-ਵੱਖ ਘਟਨਾਵਾਂ ਬਾਰੇ ਸੂਚਨਾਵਾਂ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ; ਸਾਡੇ ਲਈ, KAUTH_VNODE_DELETE, KAUTH_VNODE_WRITE_DATA ਅਤੇ KAUTH_VNODE_DELETE_CHILD ਓਪਰੇਸ਼ਨ ਮਹੱਤਵਪੂਰਨ ਹਨ। ਫਾਈਲਾਂ ਤੱਕ ਪਹੁੰਚ ਨੂੰ ਸੀਮਤ ਕਰਨ ਦਾ ਸਭ ਤੋਂ ਆਸਾਨ ਤਰੀਕਾ ਮਾਰਗ ਦੁਆਰਾ ਹੈ - ਅਸੀਂ ਫਾਈਲ ਦਾ ਮਾਰਗ ਪ੍ਰਾਪਤ ਕਰਨ ਅਤੇ ਪਾਥ ਪ੍ਰੀਫਿਕਸ ਦੀ ਤੁਲਨਾ ਕਰਨ ਲਈ "vn_getpath" API ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ। ਨੋਟ ਕਰੋ ਕਿ ਫਾਈਲ ਫੋਲਡਰ ਮਾਰਗਾਂ ਦੇ ਨਾਮ ਬਦਲਣ ਨੂੰ ਅਨੁਕੂਲ ਬਣਾਉਣ ਲਈ, ਸਿਸਟਮ ਹਰੇਕ ਫਾਈਲ ਤੱਕ ਪਹੁੰਚ ਦਾ ਅਧਿਕਾਰ ਨਹੀਂ ਦਿੰਦਾ ਹੈ, ਪਰ ਸਿਰਫ ਉਸ ਫੋਲਡਰ ਲਈ ਜਿਸਦਾ ਨਾਮ ਬਦਲਿਆ ਗਿਆ ਹੈ। ਮੂਲ ਮਾਰਗ ਦੀ ਤੁਲਨਾ ਕਰਨਾ ਅਤੇ ਇਸਦੇ ਲਈ KAUTH_VNODE_DELETE ਨੂੰ ਪ੍ਰਤਿਬੰਧਿਤ ਕਰਨਾ ਜ਼ਰੂਰੀ ਹੈ।

ਇਸ ਪਹੁੰਚ ਦਾ ਨੁਕਸਾਨ ਘੱਟ ਕਾਰਗੁਜ਼ਾਰੀ ਹੋ ਸਕਦਾ ਹੈ ਕਿਉਂਕਿ ਅਗੇਤਰਾਂ ਦੀ ਗਿਣਤੀ ਵਧਦੀ ਹੈ। ਇਹ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ ਕਿ ਤੁਲਨਾ O(ਅਗੇਤਰ*ਲੰਬਾਈ) ਦੇ ਬਰਾਬਰ ਨਹੀਂ ਹੈ, ਜਿੱਥੇ ਅਗੇਤਰ ਅਗੇਤਰਾਂ ਦੀ ਸੰਖਿਆ ਹੈ, ਲੰਬਾਈ ਸਟ੍ਰਿੰਗ ਦੀ ਲੰਬਾਈ ਹੈ, ਤੁਸੀਂ ਪ੍ਰੀਫਿਕਸ ਦੁਆਰਾ ਬਣਾਏ ਇੱਕ ਨਿਰਧਾਰਕ ਸੀਮਿਤ ਆਟੋਮੇਟਨ (DFA) ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹੋ।

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

ਪਹਿਲੇ ਕੇਸ ਵਿੱਚ (ਕਰਸਰ ਦੇ ਹੇਠਾਂ ਸਾਰੇ ਅੱਖਰ ਇੱਕੋ ਜਿਹੇ ਹਨ), ਸਾਨੂੰ ਇੱਕ 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 ਇੱਕ ਫੋਲਡਰ ਹੈ, ਤਾਂ ਤੁਹਾਨੂੰ ਅੰਤ ਵਿੱਚ ਇੱਕ '/' ਜੋੜਨ ਦੀ ਲੋੜ ਹੈ, ਨਹੀਂ ਤਾਂ ਇਹ ਇਸਨੂੰ "/foor/bar/t" ਫਾਈਲ ਤੱਕ ਸੀਮਿਤ ਕਰ ਸਕਦੀ ਹੈ, ਜੋ ਕਿ ਗਲਤ ਹੈ।
3. ਅੰਤਮ ਅਵਸਥਾ ਨਹੀਂ ਪਹੁੰਚੀ, ਰਸਤਾ ਖਤਮ ਨਹੀਂ ਹੋਇਆ। ਕੋਈ ਵੀ ਅਗੇਤਰ ਇਸ ਨਾਲ ਮੇਲ ਨਹੀਂ ਖਾਂਦਾ, ਅਸੀਂ ਪਾਬੰਦੀਆਂ ਪੇਸ਼ ਨਹੀਂ ਕਰਦੇ ਹਾਂ।

ਸਿੱਟਾ

ਵਿਕਸਤ ਕੀਤੇ ਜਾ ਰਹੇ ਸੁਰੱਖਿਆ ਹੱਲਾਂ ਦਾ ਟੀਚਾ ਉਪਭੋਗਤਾ ਅਤੇ ਉਸਦੇ ਡੇਟਾ ਦੀ ਸੁਰੱਖਿਆ ਦੇ ਪੱਧਰ ਨੂੰ ਵਧਾਉਣਾ ਹੈ। ਇੱਕ ਪਾਸੇ, ਇਹ ਟੀਚਾ ਐਕ੍ਰੋਨਿਸ ਸੌਫਟਵੇਅਰ ਉਤਪਾਦ ਦੇ ਵਿਕਾਸ ਦੁਆਰਾ ਪ੍ਰਾਪਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਜੋ ਉਹਨਾਂ ਕਮਜ਼ੋਰੀਆਂ ਨੂੰ ਬੰਦ ਕਰਦਾ ਹੈ ਜਿੱਥੇ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਖੁਦ "ਕਮਜ਼ੋਰ" ਹੈ। ਦੂਜੇ ਪਾਸੇ, ਸਾਨੂੰ ਉਹਨਾਂ ਸੁਰੱਖਿਆ ਪਹਿਲੂਆਂ ਨੂੰ ਮਜ਼ਬੂਤ ​​ਕਰਨ ਦੀ ਅਣਦੇਖੀ ਨਹੀਂ ਕਰਨੀ ਚਾਹੀਦੀ ਜੋ OS ਵਾਲੇ ਪਾਸੇ ਸੁਧਾਰੇ ਜਾ ਸਕਦੇ ਹਨ, ਖਾਸ ਕਰਕੇ ਕਿਉਂਕਿ ਅਜਿਹੀਆਂ ਕਮਜ਼ੋਰੀਆਂ ਨੂੰ ਬੰਦ ਕਰਨ ਨਾਲ ਉਤਪਾਦ ਦੇ ਤੌਰ 'ਤੇ ਸਾਡੀ ਆਪਣੀ ਸਥਿਰਤਾ ਵਧਦੀ ਹੈ। ਕਮਜ਼ੋਰੀ ਦੀ ਰਿਪੋਰਟ Apple ਉਤਪਾਦ ਸੁਰੱਖਿਆ ਟੀਮ ਨੂੰ ਦਿੱਤੀ ਗਈ ਸੀ ਅਤੇ macOS 10.14.5 (https://support.apple.com/en-gb/HT210119) ਵਿੱਚ ਹੱਲ ਕੀਤਾ ਗਿਆ ਹੈ।

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

ਸਰੋਤ: www.habr.com