• B правой части каждого сообщения есть стрелки и . Не стесняйтесь оценивать ответы. Чтобы автору вопроса закрыть свой тикет, надо выбрать лучший ответ. Просто нажмите значок в правой части сообщения.

  • Курсы Академии Кодебай, стартующие в мае - июне, от команды The Codeby

    1. Цифровая криминалистика и реагирование на инциденты
    2. ОС Linux (DFIR) Старт: 16 мая
    3. Анализ фишинговых атак Старт: 16 мая Устройства для тестирования на проникновение Старт: 16 мая

    Скидки до 10%

    Полный список ближайших курсов ...

Вопрос по доступу в Windows

AbN

One Level
13.06.2020
6
1
BIT
0
Интересует вопрос доступа (а точнее причины его отсутствия) к файлу (папке\диску)
Те на входе мы имеем какой-то путь от пользователя и нам нужно открыть файл (убедившись предварительно что это именно файл), но по множеству разных причин можем получить ошибку и хотелось бы в подробностях показать пользователю в чем проблема. Аналогично при попытке записи, если доступ на чтение есть.

Как я это вижу, есть три основных момента:

  • Права доступа ACL
  • Атрибуты файла
  • Блокировка дескриптора (тут все понятно)

если что-то не учел - дополните список

Итак, по логике нужно было бы сначала проверить атрибуты, что одновременно нам скажет существует ли объект, каков его тип (диск\папка\файл) и размер, однако при запрете через ACL, мы не сможем этого сделать
и получим ошибку "Отказано в доступе". Соответственно получив подобное пробуем проверить наш доступ. На этом моменте возникают вопросы - как проще и корректней это сделать.

Пока вариант такой:
  1. получаем SecurityDescriptor из пути через GetFileSecurity()
  2. получаем собственный ImpersonatedToken через OpenProcessToken()+DuplicateToken()
  3. проверяем права на объект через AccessCheck( SecurityDescriptor, ImpersonatedToken, DesiredAccess...)
вроде как возвращает все правильно
На данном этапе смотрим, если права RW(E), то дело в залоченном дескрипторе, пробуем найти и показать имена процессов, чтобы пользователь сам принял решение что с этим делать (аудитория не домохозяйки, тут все оправдано).

Хотелось бы узнать насколько верен ход моих мыслей, может что-то стоит изменить, или добавить, возможно есть более эффективные альтернативы?
 

igarytsh

Member
10.07.2020
8
0
BIT
0
Странно мутный вопрос. Ты че за программу пишешь? Больше похоже на абстрактное желание поговорить на тему.
 

Balabol

Well-known member
24.06.2020
92
0
BIT
0
Зачем юзеру предоставлять права на доступ к файлу через ImpersonatedToken? Это-же уже типо privelege evelation (UAC bypass и все дела) получается... или я не правильно понял?
 

igarytsh

Member
10.07.2020
8
0
BIT
0
Зачем юзеру предоставлять права на доступ к файлу через ImpersonatedToken? Это-же уже типо privelege evelation (UAC bypass и все дела) получается... или я не правильно понял?
Возможно если ты пишешь сервис который выполняеться от имени системы и тебе нужно взаимодействовать с залогинившимся юзером.
 

AbN

One Level
13.06.2020
6
1
BIT
0
Зачем юзеру предоставлять права на доступ к файлу через ImpersonatedToken
Мы получаем собственный токен
C++:
OpenProcessToken(GetCurrentProcess(), TOKEN_IMPERSONATE|TOKEN_QUERY|TOKEN_DUPLICATE|STANDARD_RIGHTS_READ, &hToken)
потому что нам нужно узнать права доступа к "объекту" текущей исполняющейся программы и без этого "финта" с имперсонализацией ничего не получится.
По аналогии можно еще так:
C++:
ImpersonateSelf(SecurityImpersonation)
OpenThreadToken(GetCurrentThread(), TOKEN_QUERY, 0, &hToken)
но первый вариант мне больше нравится. Вот по данному способу проверки
сервис который выполняеться от имени системы
обычная программа с дебаг привилегиями

Хотя говорят что на новых ОС этот подход может плохо работать (я на 7-ке еще сижу).
В частности еще и поэтому интересно ваше мнение.
 
Последнее редактирование:
Мы в соцсетях:

Обучение наступательной кибербезопасности в игровой форме. Начать игру!