Объем процесса

Объем процесса (KAUTH_SCOPE_PROCESS, который является "com.apple.kauth.process") является самым простым понять. Это определяет всего два действия.

• KAUTH_PROCESS_CANTRACE — Авторизовывает, может ли текущий процесс проследить целевой процесс. arg0 (типа proc_t) прослеживаемый процесс. arg1 (типа (int *)) указатель на код ошибки errno-стиля; если слушатель отклоняет запрос, он должен установить это значение в ненулевое значение.

• KAUTH_PROCESS_CANSIGNAL — Авторизовывает, может ли текущий процесс сигнализировать целевой процесс. arg0 (типа proc_t) процесс, который будет сообщен. arg1 (типа int) сигнал, который это отправляется.

Ядро также экспортирует a kauth_authorize_action обертка для этого объема, а именно, kauth_authorize_process.

Перечисление 7  kauth_authorize_process

extern int kauth_authorize_process(
    kauth_cred_t   credential, 
    kauth_action_t action,
    proc_t         process, 
    uintptr_t      arg1, 
    uintptr_t      arg2, 
    uintptr_t      arg3
);

Эта обертка вокруг kauth_authorize_action делает две полезных вещи:

1. Это предоставляет надлежащий параметр объема.

2. Это избавляет от необходимости бросать process (типа proc_t) к arg0 (типа uintptr_t).

Обычно это не полезно для сторонних разработчиков.

Универсальный объем

Универсальный объем (KAUTH_SCOPE_GENERIC, который является "com.apple.kauth.generic") имеет единственное действие, KAUTH_GENERIC_ISSUSER, который ядро запрашивает протестировать, имеет ли агент полномочия суперпользователя. Ни один из универсальных параметров (arg0 через arg3) являются значительными.

Ядро также экспортирует a kauth_authorize_action обертка для этого объема, а именно, kauth_authorize_generic.

Перечисление 8  kauth_authorize_generic

extern int kauth_authorize_generic(     kauth_cred_t   credential,      kauth_action_t action );

Обычно это не полезно для сторонних разработчиков.

Объем работы файла

Объем работы файла (KAUTH_SCOPE_FILEOP, который является "com.apple.kauth.fileop") отличается от других объемов, в которых это не используется для фактической авторизации работы; скорее система использует этот объем для уведомления слушателей значительных операций файловой системы. Это может использоваться для реализации программы сканирования антивируса, как описано в Антивирусном Сканере.

KAUTH_SCOPE_FILEOP определяет следующие действия.

• KAUTH_FILEOP_OPEN — Уведомляет, что был открыт объект файловой системы (файл или каталог). arg0 (типа vnode_t) vnode ссылка. arg1 (типа (const char *)) указатель на полный путь объекта.

• KAUTH_FILEOP_CLOSE — Уведомляет, что объект файловой системы собирается быть закрытым. arg0 (типа vnode_t) vnode ссылка. arg1 (типа (const char *)) указатель на полный путь объекта. arg2 (типа int) ряд битовых флагов; единственный флаг, в настоящее время определяемый, KAUTH_FILEOP_CLOSE_MODIFIED, если измененный файл закрывается, который установлен.

• KAUTH_FILEOP_RENAME — Уведомляет, что был переименован объект файловой системы. arg0 (типа (const char *)) указатель на предыдущий полный путь объекта. arg1 (типа (const char *)) указатель на новый полный путь объекта.

• KAUTH_FILEOP_EXCHANGE — Уведомляет, что двумя файлами обменялись (через exchangedata). arg0 (типа (const char *)) указатель на полный путь первого файла. arg1 (типа (const char *)) указатель на полный путь второго файла.

• KAUTH_FILEOP_LINK — Уведомляет, что новая жесткая ссылка была добавлена к файлу (через системный вызов ссылки). arg0 (типа (const char *)) указатель на полный путь исходного файла. arg1 (типа (const char *)) указатель на полный путь недавно создаваемой ссылки.

• KAUTH_FILEOP_EXEC — Уведомляет, что программа была выполнена (через execve системный вызов). arg0 (типа vnode_t) vnode ссылка выполняемой программы (для Мужественных исполнимых программ, это - фактическая исполнимая программа; для приложений CFM это будет всегда ссылаться LaunchCFMApp; для интерпретируемых сценариев, таких как оболочка или perl сценарии, это - сценарий, не интерпретатор). arg1 (типа (const char *)) указатель на полный путь программного файла.

При установке слушателя в этом объеме его вызовут для уведомления Вас относительно этих событий. Ядро игнорирует возвращаемое значение Вашего слушателя, несмотря на то, что мы рекомендуем всегда возвращаться KAUTH_RESULT_DEFER.

Эта проблема была решена в Mac OS X 10.5.

Ядро также экспортирует a kauth_authorize_action обертка для этого объема, а именно, kauth_authorize_fileop.

Перечисление 9  kauth_authorize_fileop

extern int kauth_authorize_fileop(     kauth_cred_t   credential,      kauth_action_t action,     uintptr_t      arg0,      uintptr_t      arg1 );

Обычно kauth_authorize_fileop не полезно для сторонних разработчиков. Однако при вызове его примите во внимание следующее неочевидное поведение. arg0 параметр kauth_authorize_fileop a vnode_t. kauth_authorize_fileop передачи это vnode_t к arg0 параметр слушателя. Это также получает путь к этому vnode и передачи это к arg1 параметр слушателя. Наконец, для KAUTH_FILEOP_CLOSE действие, kauth_authorize_fileop передачи arg1 параметр к arg2 параметр слушателя.

Объем Vnode

Объем vnode (KAUTH_SCOPE_VNODE, который является "com.apple.kauth.vnode") самый сложный объем, в настоящее время определяемый. Первая вещь отметить состоит в том, что в объеме vnode действия не являются перечислениями, а скорее битовыми полями. Таким образом совершенно разумно объединить действия осуществлением операции ИЛИ их вместе. Например, действие KAUTH_VNODE_READ_DATA | KAUTH_VNODE_EXECUTE указывает, что агент хочет и считать и выполнить файл.

Для авторизации действия в объеме vnode Вы вызвали бы vnode_authorize.

Перечисление 10  vnode_authorize

extern int vnode_authorize(     vnode_t        vp,      vnode_t        dvp,      kauth_action_t action,      vfs_context_t  context );

Параметры следующие:

• vp vnode, на котором выполняется действие.

• dvp vnode родительского каталога. Во многих случаях это NULL, указание, что родитель неизвестен или не важен.

• action выполняемая работа; это обсуждено подробно ниже.

• context контекст VFS, связанный с агентом. Это - непрозрачная структура данных, это глубоко связывается к реализации VFS. Большинство точек входа VFS передается этот контекст. Кроме того, существуют многочисленные подпрограммы контекста VFS, определенные в <sys/vnode.h>.

vnode_authorize довольно простая обертка вокруг kauth_authorize_action. Это выполняет две полезных функции:

1. Это собирает корректные параметры слушателя объема (arg0 через arg3). Они обсуждены ниже.

2. Это гарантирует, что код ошибки корректен. В частности это переводит EPERM ошибка, возвращенная kauth_authorize_action в EACCES (который является надлежащей ошибкой для функций файловой системы). Кроме того, если слушатель отклоняет запрос и обеспечивает определенный код ошибки (через arg3, посмотрите ниже), это возвращает ту ошибку.

Параметры слушателя объема за объем vnode следующие:

• arg0, из типа vfs_context_t, context — Контекст VFS, описанный выше.

• arg1, из типа vnode_t, vp — Сам vnode.

• arg2, из типа vnode_t, dvp — Родитель vnode, при наличии. Это может быть NULL.

• arg3, из типа (int *), errPtr — Указатель на ошибку errno-стиля. Если Ваш обратный вызов отклоняет запрос, он может установить это значение для указания ошибки возвратиться к клиенту. Если Вы не устанавливаете это, клиент добирается EACCES.

В объеме vnode определяются следующие стандартные действия.

• KAUTH_VNODE_READ_DATA (также KAUTH_VNODE_LIST_DIRECTORY) — Если vnode является каталогом, разрешает агента перечислять содержание того каталога. Иначе, разрешает агента читать содержание файла.

• KAUTH_VNODE_WRITE_DATA (также KAUTH_VNODE_ADD_FILE) — Если vnode является каталогом, разрешает агента добавлять файл к тому каталогу. vp каталог, к которому добавляется файл; dvp NULL. Иначе, разрешает агента писать содержание файла.

• KAUTH_VNODE_EXECUTE (также KAUTH_VNODE_SEARCH) — Если vnode является каталогом, разрешает агента зондировать для существования элемента в каталоге как часть поиска пути. Иначе, разрешает агента выполнять содержание файла.

• KAUTH_VNODE_DELETE — Разрешает агента удалять элемент из каталога. vp элемент, который будет удален и dvp каталог, из которого это удаляется.

• KAUTH_VNODE_APPEND_DATA (также KAUTH_VNODE_ADD_SUBDIRECTORY) — Если vnode является каталогом, разрешает агента добавлять каталог к нему. Иначе, это действие предназначается, чтобы разрешить агента добавлять данные к содержанию файла; однако, этот аспект в настоящее время не реализуется.

• KAUTH_VNODE_DELETE_CHILD — Когда используется в ACL каталога, это разрешение управляет, может ли агент удалить элемент из каталога. Т.е. для агента, чтобы быть в состоянии удалить элемент, они должны иметь KAUTH_VNODE_DELETE разрешение на элементе и KAUTH_VNODE_DELETE_CHILD разрешение на родительском каталоге элемента.

  Слушатель Kauth, однако, редко видит это действие. Когда агент удаляет элемент, ядро просто авторизовывает KAUTH_VNODE_DELETE действие с самим элементом; это не авторизовывает отдельное KAUTH_VNODE_DELETE_CHILD действие с родительским каталогом. Скорее слушатель по умолчанию для объема vnode проверит KAUTH_VNODE_DELETE_CHILD разрешение на родительском каталоге непосредственно, без другого проходят через Kauth. Это улучшает производительность и избегает потенциального состояния состязания.

  С другой стороны, a KAUTH_VNODE_DELETE_CHILD действие сгенерировано в ответ на системный вызов доступа с _RMFILE_OK флаг.

• KAUTH_VNODE_READ_ATTRIBUTES — Разрешает агента читать стандартные атрибуты vnode (такие как метки времени).

• KAUTH_VNODE_WRITE_ATTRIBUTES — Разрешает агента изменять стандартные атрибуты vnode (такие как метки времени).

• KAUTH_VNODE_READ_EXTATTRIBUTES — Разрешает агента читать расширенные атрибуты vnode (те, через которых получают доступ getxattr, включая ветвь ресурсов).

• KAUTH_VNODE_WRITE_EXTATTRIBUTES — Разрешает агента изменяться (или добавлять) расширенные атрибуты vnode (те, через которых получают доступ getxattr, включая ветвь ресурсов).

• KAUTH_VNODE_READ_SECURITY — Разрешает агента читать ACL vnode.

• KAUTH_VNODE_WRITE_SECURITY — Разрешает агента изменять ACL vnode.

• KAUTH_VNODE_TAKE_OWNERSHIP — Разрешает агента изменять владение vnode.

• KAUTH_VNODE_SYNCHRONIZE — Это представляет разрешение ACL, определяющееся для совместимости с другими платформами. Это сохраняется, но не тестируется Mac OS X. Следовательно, это никогда не используется в качестве действия Kauth.

• KAUTH_VNODE_LINKTARGET — Разрешает агента делать новую жесткую ссылку на vnode.

• KAUTH_VNODE_CHECKIMMUTABLE — Разрешает агента изменять файл (в SF_IMMUTABLE смысл; см. chflags). Этот флаг установлен, если другие проверки были уже осуществлены, чтобы проверить, что файл может измененным, но модификация должна все еще перестать работать для неизменных файлов.

• KAUTH_VNODE_ACCESS — Это - специальный флаг. Если этот флаг установлен, запрос авторизации является консультацией (например, для удовлетворения системного вызова доступа), а не авторитетный. Слушатель может использовать это, чтобы избежать выполнять дополнительную работу в консультативном случае.

• KAUTH_VNODE_NOIMMUTABLE — Это - специальный флаг. Это передается слушателю вместе с KAUTH_VNODE_WRITE_SECURITY бит (и никакие другие), чтобы указать, что агент хочет измениться один или больше неизменных флагов, и что состояние этих флагов нельзя рассмотреть при авторизации запроса.

Контекст

В большинстве случаев Вашего слушателя вызовет поток пользователя. Т.е. пользовательский поток сделал системный вызов, заставивший его вводить ядро для выполнения работы, инициировавшей запрос Kauth. Так, возможно получить информацию об агенте на основе текущего потока или процесса. Например, можно вызвать proc_self получить ссылку на текущий процесс и затем извлечь полезную информацию из этого.

Однако необходимо попытаться избежать делать это. Скорее Ваш слушатель должен принять его решение на основе учетных данных агента (как передано ему в credentials параметр) и, если Вы слушаете в объеме vnode, контексте VFS.

Существует две причины этой рекомендации.

• Насколько полный проект ядра затронут, это более чисто для Вашего слушателя для принятия решений на основе его входных параметров, а не на неявных параметрах как текущий поток.

• В некоторых случаях для работы ядра возможно быть выполненным другим потоком от имени пользователя. Этот вид вещи уже происходит для асинхронного I/O, где ядро поддерживает пул асинхронных потоков I/O, выполняющих асинхронные запросы к файловой системе. В настоящее время эти потоки фактически не делают запросы авторизации, но долгосрочное направление ясно.

Отклонение отладчика

Можно использовать Kauth для реализации расширения ядра, предотвращающего пользователей, присоединяющих к процессам с отладчиком. Все, что необходимо сделать, зарегистрировать слушателя для KAUTH_SCOPE_PROCESS определите объем и ищите KAUTH_PROCESS_CANTRACE действие. Перечисление 11 показывает слушателю в качестве примера, отрицающему отлаживать для всех кроме корня. Можно использовать подобный метод для предотвращения присоединения отладчика к определенным процессам.

Перечисление 11  , Отклоняющее отладчик

static int KauthDenyDebugListener(
    kauth_cred_t    credential,
    void *          idata,
    kauth_action_t  action,
    uintptr_t       arg0,
    uintptr_t       arg1,
    uintptr_t       arg2,
    uintptr_t       arg3
)
    // We register this listener for the KAUTH_SCOPE_PROCESS scope. 
    // The system calls this listener whenever it needs to authorize 
    // an action within that scope. We look for 
    // KAUTH_PROCESS_CANTRACE action and deny it if the requesting 
    // user is not root.
{
    int     result;

    result = KAUTH_RESULT_DEFER;

    switch (action) {
        case KAUTH_PROCESS_CANTRACE:
            {
                proc_t  targetProc;
                int *   errPtr;

                targetProc = (proc_t) arg0;
                errPtr     = (int *) arg1;

                if (kauth_cred_getuid(credential) != 0) {
                    printf(
                        "Denied P_TRACE from %d to %d by %d.\n", 
                        proc_selfpid(),
                        proc_pid(targetProc),
                        kauth_cred_getuid(credential)
                    );
                    *errPtr = EPERM;
                    result = KAUTH_RESULT_DENY;
                }
            }
            break;
        default:
            // do nothing
            break;
    }

    return result;
}

Антивирусный сканер

Kauth позволяет Вам реализовывать антивирусную программу, поддерживающую и «на доступе» и «сканировании файла» модификации сообщения. Последний прост: все, что необходимо сделать, зарегистрировать слушателя для KAUTH_SCOPE_FILEOP объем и часы для KAUTH_FILEOP_CLOSE действие. Если Вы видите, что измененный файл закрывается, можно передать тот файл демону пространства пользователя для сканирования. Поскольку сканирование продолжается асинхронно в фоновом режиме, не должно быть никаких проблем с мертвой блокировкой.

При реализации «на доступе» сканирование более сложно. Ваш подход зависит от того, можно ли всегда фиксировать файл. Если это так, можно прислушаться KAUTH_FILEOP_OPEN (в KAUTH_SCOPE_FILEOP) и отсканируйте файл сразу после того, как он будет открыт. Однако результат Вашего слушателя всегда игнорируется, таким образом, нет никакого способа запретить доступа агента к тому файлу.

Если Вы не можете всегда фиксировать файл, и таким образом можно хотеть запретить доступа агента к файлу, необходимо прислушаться к надлежащим мерам в KAUTH_SCOPE_VNODE объем. Если Вы сканируете файл, обнаруживаете, что он заражен и не может фиксировать его, необходимо возвратиться KAUTH_RESULT_DENY препятствовать тому, чтобы агент использовал его.

Трудность с обоими из них «на доступе» подходы избегает мертвой блокировки. Посмотрите Реализацию Слушателя для детального обсуждения этой проблемы.

Новая подсистема ядра

При реализации полностью новой подсистемы ядра (например, сложный стек протоколов), можно решить реализовать использование авторизации Kauth. Существует семь шагов к этому:

1. Выберите имя объема. Необходимо использовать обратное имя стиля DNS, как проиллюстрировано встроенными объемами, описанными в этом документе.

2. Выберите ряд действий. Можно принять решение использовать любого перечисление (как сделано объемом операций файла) или битовая маска (как используется объемом vnode).

3. Для каждого действия необходимо решить что специфичные для запроса параметры (типа arg0 через arg3) являются подходящими для того действия. Является самым простым, если параметрами является то же для всех действий в Вашем объеме, но это не требуется.

4. Запишите слушателю по умолчанию для Вашего объема. Этот слушатель должен быть в состоянии сделать решения об авторизации на основе:

   • идентификационные данные агента (как представлено слушателем credentials параметр)

   • требуемое действие

   • специфичные для запроса параметры

   Ваш слушатель может извлечь информацию из учетных данных с помощью функций, определяемых средства доступа в <sys/kauth.h>.

5. Создайте свой объем и зарегистрируйте своего слушателя как слушателя по умолчанию, с помощью kauth_register_scope.

6. Создайте специфичную для объема функцию обертки для kauth_authorize_action это:

   • предоставляет ссылку на объем, создаваемый на предыдущем шаге

   • бросает Ваши специфичные для объема параметры универсальным параметрам (arg0 через arg3) используемый kauth_authorize_action

7. Вызовите свою специфичную для объема функцию обертки для авторизации определенных действий в надлежащих местах в подсистеме ядра.