Bug 41306

Summary:

[FR] Групповые политики. Включить разрешение для запуска приложения любым пользователем, затем отменить разрешение -> Приложение доступно для запуска. Не очевиден эффект после применения состояния "политика Отключена"

Product:

Branch p10

Reporter:

Vera Blagoveschenskaya <vercha>

Component:

gpupdate

Assignee:

Valery Sinelnikov <greh>

Status:

NEW ---

QA Contact:

qa-p10 <qa-p10>

Severity:

normal

Priority:

CC:

august, sa, shevchenkodyu, sin, sova, v.karpunin

Version:

не указана

Hardware:

x86_64

OS:

Linux

Attachments:

Description	Flags
gpupdate.log	none
screen	none

Description

Vera Blagoveschenskaya 2021-11-09 11:59:28 MSK

Created attachment 9917 [details]
gpupdate.log

Конфигурация стендов:
dc p9 server x86_64
dc2 p9 server x86_64
Клиенты: p9 education x86_64 / i596, p9 workstation x86_64
Win7 + RSAT

# rpm -qa | grep gpupdate
alterator-gpupdate-1.3-alt1.i586
oddjob-gpupdate-0.2.0-alt1.i586
gpupdate-0.9.2-alt1.noarch
1) На сервере установить пакет admx-basealt
# apt-get install admx-basealt
# samba-tool gpo admxload -U Administrator
2) На Windows машине зайти под администратором домена и подключиться к серверу через оснастку Управление групповой политикой:
Панель управления - Администрирование - Управление групповой политикой.
На имени домена ПКМ - Создать объект групповой политики
Имя TestAltGPO
3) ПКМ на политике TestAltGPO - изменить.
Конфигурация копьютера - Политики - Административные шаблоны - Система ALT.
Изменить параметры нескольких политик Система ALT:
Например,
Безопасность - Разрешение для /bin/su:
Включить - Любой пользователь может запускать /bin/su
Сетевые приложения - Разрешение на использование /usr/bin/mtr:
Включить - Любой пользователь
4) На клиенте выполнить команды
# gpupdate
# gpoa --loglevel 0
5) Под доменным пользователем и проверить изменения.
Все применилось, запуск su и mtr возможен = ОК.
6) Отменить Разрешение на использование /usr/bin/mtr:
Сетевые приложения - Разрешение на использование /usr/bin/mtr:
Не задана
7) На клиенте выполнить команды
# gpupdate
# gpoa --loglevel 0
8) Перезагрузка клиента, вход пользователями:
- тем же, что на шаге 5
- новым, свежесозданным

Результат: запуск mtr возможен 
Аналогично, для другой политики, разрешение su-

Ожидаемый результат: после шагов 6 и 7 запуск mtr обычным пользователем невозможен

Дополнительно: ошибка найдена при тестировании версии gpupdate-0.9.8-alt1, но воспроизводится и на версии gpupdate-0.9.2-alt1

Comment 1

Vera Blagoveschenskaya 2021-11-09 12:26:09 MSK

Еще исследования:
- если выставить политику в Отключить и применить на клиенте. то поведение аналогичное, mtr разрешен для запуска доменному пользователю (в том числе и новому на этом клиенте!)
- если ввести новую машину в домен, то политики отрабатывают корректно (mtr запустить нельзя), но ситуация повторяется, если еще раз включить-отключить разрешение

Comment 2

Vera Blagoveschenskaya 2021-11-09 17:10:29 MSK

Created attachment 9920 [details]
screen

Comment 3

Vera Blagoveschenskaya 2022-12-02 10:36:06 MSK

Наткнулась на данную ошибку и в p10

# rpm -qa | grep gpupdate
oddjob-gpupdate-0.2.0-alt1.x86_64
gpupdate-0.9.11.2-alt1.noarch
alterator-gpupdate-1.3-alt1.x86_64
# rpm -qa | grep samba
samba-dc-4.16.6-alt2.x86_64
admx-samba-4.16.6-alt2.noarch
task-samba-dc-4.16.6-alt2.noarch
samba-common-client-4.16.6-alt2.noarch
samba-libs-4.16.6-alt2.x86_64
samba-dc-libs-4.16.6-alt2.x86_64
samba-winbind-4.16.6-alt2.x86_64
samba-dc-client-4.16.6-alt2.x86_64
samba-doc-4.16.6-alt2.noarch
samba-pidl-4.16.6-alt2.noarch
samba-4.16.6-alt2.x86_64
samba-winbind-common-4.16.6-alt2.x86_64
samba-common-4.16.6-alt2.noarch
samba-dc-common-4.16.6-alt2.noarch
samba-common-libs-4.16.6-alt2.x86_64
samba-client-4.16.6-alt2.x86_64
samba-common-tools-4.16.6-alt2.x86_64
python3-module-samba-4.16.6-alt2.x86_64
samba-winbind-clients-4.16.6-alt2.x86_64

Включение политик проверялось через gpui.

Аналогично описанию, после удаления политики и перезагрузки, политика актуальна (проверялось на создании ярдыков на рабочем столе).

Для нового пользователя на машине, уже введенной в домен - актуально.

Политики не применяются только на новой машине, введенной в домен.

Comment 4

Vera Blagoveschenskaya 2023-09-21 15:52:57 MSK

Все еще актуально.
Наткнулась при тестировании разрешения для postqueue

Версии:
gpui-0.2.34-alt1
gpupdate-0.9.12.6-alt1

Comment 5

Valentin Sokolov 2023-11-22 13:13:46 MSK

(Ответ для Vera Blagoveschenskaya на комментарий #4)
> Все еще актуально.
> Наткнулась при тестировании разрешения для postqueue
> 
> Версии:
> gpui-0.2.34-alt1
> gpupdate-0.9.12.6-alt1

Вера, здравствуйте. Политика "Разрешение на использование /usr/bin/mtr" управляет утилитой control для mtr.

----

# control |grep mtr
mtr             netadmin        (public netadmin restricted)

----

В политике присутствует выпадающий список, включающий в себя все 3 состояния. Если Вы ВКЛЮЧАЕТЕ политику, выставив одно из состояний, control перейдёт в заданное состояние. 
Если Вы переводите политику в состояние ОТКЛЮЧЕНО/НЕ СКОНФИГУРИРОВАНО, состояние самого control в системе никак не изменится, а останется именно таким, каким было до этого. Аналогично и для политики "Разрешения для /bin/su." Не вижу ошибки в данном случае. Политика гибко управляет контролом в зависимости от заданного состояния. 

Возможно, стоит добавить пояснения в сами admx шаблоны о таком поведении всех политик, связанных с control.

Comment 6

Valentin Sokolov 2023-11-22 14:16:16 MSK

(Ответ для Vera Blagoveschenskaya на комментарий #4)
> Все еще актуально.
> Наткнулась при тестировании разрешения для postqueue
> 
> Версии:
> gpui-0.2.34-alt1
> gpupdate-0.9.12.6-alt1

Вера, здравствуйте. Политика "Разрешение на использование /usr/bin/mtr" управляет утилитой control для mtr.

----

# control |grep mtr
mtr             netadmin        (public netadmin restricted)

----

В политике присутствует выпадающий список, включающий в себя все 3 состояния. Если Вы ВКЛЮЧАЕТЕ политику, выставив одно из состояний, control перейдёт в заданное состояние. 
Если Вы переводите политику в состояние ОТКЛЮЧЕНО/НЕ СКОНФИГУРИРОВАНО, состояние самого control в системе никак не изменится, а останется именно таким, каким было до этого. Аналогично и для политики "Разрешения для /bin/su." Не вижу ошибки в данном случае. Политика гибко управляет контролом в зависимости от заданного состояния. 

Возможно, стоит добавить пояснения в сами admx шаблоны о таком поведении всех политик, связанных с control.

Comment 7

Vera Blagoveschenskaya 2023-11-24 10:55:07 MSK

(Ответ для SoVa на комментарий #6)
> В политике присутствует выпадающий список, включающий в себя все 3
> состояния. Если Вы ВКЛЮЧАЕТЕ политику, выставив одно из состояний, control
> перейдёт в заданное состояние. 
> Если Вы переводите политику в состояние ОТКЛЮЧЕНО/НЕ СКОНФИГУРИРОВАНО,
> состояние самого control в системе никак не изменится, а останется именно
> таким, каким было до этого. Аналогично и для политики "Разрешения для
> /bin/su." Не вижу ошибки в данном случае. Политика гибко управляет контролом
> в зависимости от заданного состояния. 
> 

Добрый день.

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

Также не понятно, чем в таком случае отличаются состояния "Отключено" и "Не сконфигурировано".

> Возможно, стоит добавить пояснения в сами admx шаблоны о таком поведении
> всех политик, связанных с control.

Это значительно бы упростило понимание.

Comment 8

Valery Sinelnikov 2023-11-24 11:10:09 MSK

(Ответ для Vera Blagoveschenskaya на комментарий #7)
> (Ответ для SoVa на комментарий #6)
> > В политике присутствует выпадающий список, включающий в себя все 3
> > состояния. Если Вы ВКЛЮЧАЕТЕ политику, выставив одно из состояний, control
> > перейдёт в заданное состояние. 
> > Если Вы переводите политику в состояние ОТКЛЮЧЕНО/НЕ СКОНФИГУРИРОВАНО,
> > состояние самого control в системе никак не изменится, а останется именно
> > таким, каким было до этого. Аналогично и для политики "Разрешения для
> > /bin/su." Не вижу ошибки в данном случае. Политика гибко управляет контролом
> > в зависимости от заданного состояния. 
> > 
> 
> Добрый день.
> 
> Прошу сопровождающего пакета gpupdate прокомментировать ситуацию.
> На мой взгляд, состояние "Отключено" предполагает перевод того, что было
> включено, в обратное состояние.
> 
> Также не понятно, чем в таком случае отличаются состояния "Отключено" и "Не
> сконфигурировано".
> 
> > Возможно, стоит добавить пояснения в сами admx шаблоны о таком поведении
> > всех политик, связанных с control.
> 
> Это значительно бы упростило понимание.

Добрый день.

 Я согласен с вами по поводу того, что состояние "Отключено" обычно ассоциируется с переходом из активного состояния в неактивное. Возможно, в данной ситуации это можно уточнить в документации или шаблонах admx, чтобы избежать путаницы. Предложение добавить пояснения к шаблонам звучит разумно и могло бы значительно облегчить понимание.

Comment 9

Vera Blagoveschenskaya 2023-11-24 11:50:56 MSK

(Ответ для Valery Sinelnikov на комментарий #8)
> Добрый день.
> 
>  Я согласен с вами по поводу того, что состояние "Отключено" обычно
> ассоциируется с переходом из активного состояния в неактивное. Возможно, в
> данной ситуации это можно уточнить в документации или шаблонах admx, чтобы
> избежать путаницы. Предложение добавить пояснения к шаблонам звучит разумно
> и могло бы значительно облегчить понимание.

Благодарю за пояснения.

А что насчет двух вариантов состояний "ОТКЛЮЧЕНО/НЕ СКОНФИГУРИРОВАНО" с внешне "одинаковым" эффектом?

"НЕ сконфигурировано" означает, что в файле Registry.pol отсутствует запись о политике.
"Отключено" означает, что в файле Registry.pol запись о политике есть, но политика выключена. При перезагрузке компьютера происходит зачитывание этой по сути ненужной записи.

Что , если оставить только два состояния:
- Включено (с вариантами)
- НЕ сконфигурировано 
?

Тогда вопросов от пользователей по функционалу ГП будет в разы меньше.

Переквалифицирую данную задачу как Feature Request.