LINUX.ORG.RU

Белый список приложений в Linux

 , , , ,


2

4

Доброе времени суток Комрады.

Перейду сразу к примеру. В ОС windows есть оснастки mmc с помощью которой можно задать список исполнимых файлов для конкретного пользователя. После чего все остальное ПО которое будет запускаться из под данного пользователя запускаться не будет. Сама ОС запускается под системной учетной записью и все работает без проблем.

Примерно тоже самое нужно реализовать на «SUSE Linux».

Как я понимаю есть несколько вариантов.

1. На уровне файловой системы разграничить для данного пользователя с помощью ACL. Но тут возникает сложности так как от данного пользователя запускаются не только определенные приложения но и скрипты на bash и pyton. Опять таки ограничить к системному ПО как например «cp» «kill» не получиться.

2. Использовать Apparmor. Но тут сразу вопрос. Возможно ли сделать правило именно белого списка «запретить все, что не разрешено?» кроме того создать для каждого приложения свой профайл как то не реально.

3. SELinux - сложен в настройке. Получиться ли на нем реализовать именно похожий вариант как на windows с mmc?

4. LSM-модуля WhiteEgret - про этот вариант прочитал недавно. Как он реализован и как применить его именно в Suse?

Буду благодарен за любой грамотный совет.

А зачем ограничивать доступ к cp и kill? Он все равно не сможет копировать те файлы, на которых не имеет право чтения, и убивать не свои процессы.

И по поводу скриптов: а что мешает выставить эти права только на файлы нужных скриптов? Зачем убирать возможность использовать основные бинарники питона и bash?

Vsevolod-linuxoid ★★★★★ ()
Ответ на: комментарий от Vsevolod-linuxoid

Зачем убирать возможность использовать основные бинарники питона и bash?

Чтобы не запустили криптомайнер на питоне или еще что-то подобное, наверное.

crutch_master ★★★★★ ()
Ответ на: комментарий от Vsevolod-linuxoid

Ну да, просто у питона всё равно больше возможностей. Шифровальщик там можно какой-нибудь подсунуть. Если сделать на питон chmod -x, а на скрипт с #!/usr/bin/pythoon - chmod +x, скрипт будет работать?

crutch_master ★★★★★ ()
Последнее исправление: crutch_master (всего исправлений: 2)
Ответ на: комментарий от crutch_master

Вроде нет. Но питон многие нормальные проги используют, так что это может вызвать проблемы.

Vsevolod-linuxoid ★★★★★ ()

Не знаю, что там в винде, но под твоё описание подходит SELinux. Для того, чтобы упростить настройку, надо переключиться в пермиссивный режим, собрать логи для всего необходимого софта, на их основе скомпилировать политики и вернуться в строгий режим. Насколько я помню, для этого даже какие-то гуишные утилиты были.

shell-script ★★★★★ ()
Ответ на: комментарий от Vsevolod-linuxoid

Вот по этому поводу ничего наверняка не скажу. Я только с SELinux работал(на RHEL/CentOS). Да и то, несколько лет назад. Подозреваю, что будут и кого-то одного придётся выпиливать.

shell-script ★★★★★ ()
Ответ на: комментарий от shell-script

По сути Apparmor там как то не включен то есть нет бинарников, а есть библиотеки и по сути выключен не работает. Пока задачи для именно контроля ПО которые запускается нет. А есть задача простая. Это пользователю можно запускать только то что в «whitelist» остальное запретить.

ctopmbi4 ()
Ответ на: комментарий от Vsevolod-linuxoid

Нет. Стоит SUSE Linux Enterprise Server. Возвращаюсь к своему 2му вопросу. Возможно ли сделать правило именно белого списка «запретить все, что не разрешено?" с помощью именно Apparmor? Не создавая для каждого ПО, утилиты свой профаил и подгружать его в контроль Apparmor?

ctopmbi4 ()
Ответ на: комментарий от ctopmbi4

Слушай, можешь описать подробно задачу? Я сперва понял это так, как будто нужно на десктопе закрыть доступ к пасьянсам или типа того.

Vsevolod-linuxoid ★★★★★ ()
Ответ на: комментарий от Vsevolod-linuxoid

По сути так и есть. Это Дескоп, но только с него управляются тех. процессы. (АСУТП). Закрыть нужно все что «не в белом списке» требования безопасности предприятия. Пока об контроле того что делает ПО в процессе работы не идет. (То есть мы ему доверяем Безоговорочно). По сути будет крутиться Scada система. Которая запускает разные скрипты в процессе работы на Bash, pyton. В качестве GUI идет KDE на нем реализован функционал по типу kiosk-а но этого недостаточно и нужен именно «whitelist» приложений.

ctopmbi4 ()

2. Использовать Apparmor. Но тут сразу вопрос. Возможно ли сделать правило именно белого списка «запретить все, что не разрешено?» кроме того создать для каждого приложения свой профайл как то не реально.

Смотрите в сторону RBAC. http://wiki.apparmor.net/index.php/RBAC_2_3 Профили надо будет сделать только на процессы использующие аутентификацию пользователя через PAM + собственно настроить сам PAM (добавить PAM-модуль Apparmor) + сделать профили шелов для пользователей (в которых и будет «белый список»).

Важно понимать, что список вам надо будет делать не в 5-10 наименования исполняемых файлов (разрешить которые вы хотите), а в 50-100 (т.е. как минимум придется включать в список все компоненты кде, которые после логина пользователя будут запускаться в сессии пользователя, всякие утилиты из coretools и т. д.).

4. LSM-модуля WhiteEgret - про этот вариант прочитал недавно. Как он реализован и как применить его именно в Suse?

Он был только предложен для обсуждения (RFC), в апстриме его нет.

viewizard ★★ ()
Ответ на: комментарий от crutch_master

если у пользователя есть ssh, то он может установить и запустить любое ПО, собрать свой собственный python из исходников и работать с ним

Ты не можешь запретить пользователю что-то запустить, ты можешь ему запретить доступ к каким-то данным и ресурсам, портам, интерфейсам..

alpha ★★★★★ ()
Ответ на: комментарий от alpha

если у пользователя есть ssh, то он может установить и запустить любое ПО, собрать свой собственный python из исходников и работать с ним

А если ему chmod +x не дать сделать? Или это нельзя ограничить?

crutch_master ★★★★★ ()
Ответ на: комментарий от alpha

Система не будет иметь выход в сеть интернет. SSH будет по ключам и ограничен netfillter-ом для определенных адресов.

ctopmbi4 ()
Ответ на: комментарий от crutch_master

я честно не пойму зачем так извращаться

во-первых, десктоп - это плохой интерфейс для работы в четко ограниченных рамках, он совершенно не предназначен для этой задачи

это выглядит так что в винде мы делали какое-то безобразие с кликаньем мышой по кнопкам и решили сделать также в Linux

В линуксах не принято делать всё через доступ к десктопу, надо использовать протоколы взаимодействия подходящие под задачу: REST, cli, и т.п.

Хочешь ограниченный набор задач - так и сделай его ограниченный изначально.

во-вторых сама постановка задачи безумная. Мы даем права человеку ломать как угодно технологический процесс, но тратим недели на запрет ему запускать пасьянс. Кто у вас в итоге у руля технологического процесса? Человек с тремя классами образования который не понимает в чем его работа? Так его гораздо опаснее допускать к тех.процессу, чем к пасьянсу.

alpha ★★★★★ ()
Ответ на: комментарий от alpha

Видимо вы не знакомы с АСУТП и Scada системами. Система управления крутиться в Scada системе из которой и нужно закрыть все выходы в ОС, чтобы чел находящийся у тех.процесса не мог что либо сделать в самой ОС. А что он сделает в тех.процессе все фиксируется логируется в самой Scada. Чел-оператор знает все о тех. процессе, но обычно очень мало знает об ОС. айти и ИБ. Мы бы сделали все на винде, но у разработчика контроллеров , Scada система только под Linux. Разработчик поставляет Scada систему вместе с ОС. Я понимаю, что он должен был изначально задуматься о безопасности ОС. Но тут приходится подстраиваться под конкретного конечного заказчика у которого свои правила по безопасности которые нужно реализовать.

На винде все выглядит понятно. Оснастки не дают выйти в ОС. а встроенный ограниченный список ПО (настраиваемый в 2 клика) блокирует если все же каким то образом чел. смог найти выход в ОС.

ctopmbi4 ()
Ответ на: комментарий от ctopmbi4

Потому что я работал только с SELinux. :) В теории в AppArmor тоже есть политика белого списка, но я не знаю подробностей её рализации. Беглый поиск показывает, что надо читать.

shell-script ★★★★★ ()
Ответ на: комментарий от ctopmbi4

Не подскажу, как работает apparmor, так как не сталкивался, но не буду орать «ненужно», как некоторые участники. Задача интересная. Я думаю, сначала нужно разобраться, как ограничить список разрешенных exec() для конкретного бинарника. Затем эту политику можно расширить на всего пользователя, чтобы усилить защиту.

В качестве GUI идет KDE на нем реализован функционал по типу kiosk-а но этого недостаточно и нужен именно «whitelist» приложений.

Почему именно не достаточно?

Которая запускает разные скрипты в процессе работы на Bash, pyton.

Потенциальная проблема в этом. Пользователь имеет возможность через интерфейс приложения указать на произвольный файл для запуска в баше или питоне?

Deleted ()
Последнее исправление: Deleted (всего исправлений: 2)
Ответ на: комментарий от crutch_master

В теории можно держать /home/ и /tmp/ на отдельных разделах и монтировать с noexec. В другие разделы системы у пользователя нет прав на запись. C /home/ не проверял, а вот с /tmp/ могут быть проблемы - например, в debian'е при обновлении системы dpkg запускает оттуда pre-install/post-install скрипты. Правда, на время обновления можно просто делать mount -o remount /tmp.

shell-script ★★★★★ ()
Ответ на: комментарий от shell-script

Из вашей ссылки как я понял. Apparmor может ограничивать только по profile's так же поиск в гугле не дал результата. Политика по умолчанию для всех приложений которые вне списка не контролируется Apparmor.

ctopmbi4 ()
Ответ на: комментарий от ctopmbi4

В терминах Apparmor, искомый вами «белый список» для пользователя — это confined user, ограниченный пользователь, подразумевающий полный контроль запускаемых пользователем процессов и доступ к ресурсам. Как правило, в системе нужно сделать 2 типа пользователей — unconfined user (неограниченный, для root и администраторов) и confined user (ограниченный). Делается это через перевод Apparmor в режим RBAC...

viewizard ★★ ()
Ответ на: комментарий от viewizard

Инфа довольная скудная. Реальных примеров не нашел. Как я понял данный режим, реализуется через pam_apparmor.so 1. Не совсем понятно как и где создавать пользователей. 2. Как применить профиль по умолчанию к приложениям для которых отсутствуют профили. 3. pam_apparmor.so прикрутить к /etc/pam.d/xdm для GUI? И нужно ли прикрутить для login? 4. Что передается в этой строке? session optional pam_apparmor.so order=group,default

Если есть время, прошу подсказать куда копать дальше?

ctopmbi4 ()
Ответ на: комментарий от ctopmbi4

Реальных примеров не нашел.

И вряд ли найдете. Возможность переключения режима работы Apparmor в RBAC очень скудно освещена. О ней мало кто знает, а еще меньшее кол-во людей реально использует.

Как я понял данный режим, реализуется через pam_apparmor.so

Да, вы поняли правильно.

1. Не совсем понятно как и где создавать пользователей.

В режиме RBAC, Apparmor работает с существующими пользователями системы. Для работы используется стандартный механизм аутентификации — PAM. Дополнительных действий по созданию пользователей не требуется.

2. Как применить профиль по умолчанию к приложениям для которых отсутствуют профили.

Не совсем понял, что вы подразумеваете под «профиль по умолчанию».

3. pam_apparmor.so прикрутить к /etc/pam.d/xdm для GUI? И нужно ли прикрутить для login?

Я прикручиваю в /etc/pam.d/system-auth, чтобы работало везде. На самом деле, можно ставить туда, куда вы считаете нужным, но следует помнить, что данный процесс должен иметь профиль Apparmor с hat для переключения пользователей.

4. Что передается в этой строке? session optional pam_apparmor.so order=group,default

«order=group,default» — поиск hat по основной группе пользователя, если такой hat не найден, использовать hat по умолчанию. Обратите внимание, что «group» — это поиск только по основной группе пользователя, не по всем группам, в которых состоит пользователь.

viewizard ★★ ()
Ответ на: комментарий от ctopmbi4

Делаешь это неверно. Делается гостевой режим. После каждого выхода из сессии, запускается новая чистая сессия без изменений. Приложение запускается в контейнере или сhroot, директория для сохранения данных мапится на хост, и только в ней сохраняются изменения.

anonymous_sama ★★★★★ ()
Последнее исправление: anonymous_sama (всего исправлений: 1)
Ответ на: комментарий от viewizard

Как я понял у вас уже работает RBAC. Сможете поделиться примером как перевести в RBAC?

Что скажите по поводу TOMOYO и SELinux? Думаю проще на них реализовать.

ctopmbi4 ()
Ответ на: комментарий от ctopmbi4

Как я понял у вас уже работает RBAC. Сможете поделиться примером как перевести в RBAC?

В /etc/pam.d/system-auth добавлена строка

session		optional	pam_apparmor.so order=user,default

Все, режим RBAC включен, теперь остается только делать профили с hat блоками. Например, sudo:

#include <local/tunables.d/>

profile /usr/bin/sudo {

... доступ к ресурсам до аутентификации (переключения на root)

^root {
  
  ... доступ к ресурсам после аутентификации
  
  }
}

Что скажите по поводу TOMOYO и SELinux? Думаю проще на них реализовать.

В TOMOYO нет возможности работать в режиме RBAC, но, можно попробовать реализовать все через условия с uid/gid процесса. На SELinux сделать будет не так просто как на Apparmor, но сделать можно... хотя, делать «белый список» запускаемых программ на SELinux — это явный оверкил (имхо, конечно).

Если вы хорошо знаете TOMOYO или SELinux, то, вероятно, вам будет проще реализовать на них.

viewizard ★★ ()
Ответ на: комментарий от viewizard

Получается в этом режиме так же нужно для каждого приложения составлять файл с правилами? Или как то можно подсунуть по default определенный профайл с запретом?

ctopmbi4 ()
Ответ на: комментарий от ctopmbi4

В вашем случае, достаточно создать профили только для программ с аутентификацией. Нет смысла создавать профили для всех программ, если цель — создание белого списка. Вы же не ставите задачу как «создание белого списка и ограничение доступа к ресурсам программ из белого списка».

Если немного переработать предыдущий мой пример, реализация белого списка будет выглядеть примерно так:

profile /программа_с_аутентификацией {

... доступ к ресурсам до аутентификации

^имя_пользователя {
  # разрешаем доступ ко всем ресурсам, кроме доступа к файлам:
  ptrace,
  signal,
  unix,
  dbus,
  mount,
  umount,
  network,

  # доступ к файлами (разрешаем все, кроме запуска):
  /** rwklm,

  # собственно, белый список (разрешение на запуск):
  /программа1 Pix,
  /программа2 Pix,
  /программа3 Pix,
  }
}

Pix - запуск с использованием профиля программы (Px), если его нет, запускать с наследованием текущего профиля (ix). Вероятно, у вас установлены базовые профили программ из пакета Apparmor и вы захотите их использовать. Если нет, можно сразу использовать только запуск с наследованием текущего профиля:

  /программа1 ix,
  /программа2 ix,
  /программа3 ix,

Как я уже писал выше, белый список — это совокупность всех программ (включая, например, элементы DE) и утилит (например: mv, cp, ln,...), запускаемых в сеансе пользователя.

Для примера, черный список (разрешаем запускать все, кроме явно запрещенного), будет выглядеть примерно так:

profile /программа_с_аутентификацией {

... доступ к ресурсам до аутентификации

^имя_пользователя {
  # разрешаем доступ ко всем ресурсам:
  ptrace,
  signal,
  unix,
  dbus,
  mount,
  umount,
  network,
  file,

  # собственно, черный список (запрещаем запуск и фиксируем в системном журнале попытки запуска):
  audit deny /программа1 x,
  audit deny /программа2 x,
  audit deny /программа3 x,
  }
}

viewizard ★★ ()
Ответ на: комментарий от ctopmbi4

Оснастки не дают выйти в ОС

Куда? Может всё таки на «рабочий стол»?

Сделай отдельный конфиг для пользователя scada где не запускается DE, а сразу запускается scada система. Если он как-то сумеет её закрыть или уронить, то просто вывалится обратно в sddm (или что там у тебя). А там можно по таймеру перезагружать снова этот же профиль.

И да, тебе не нужен apparmor, тебе нужно запускать пользователя в контейнере (chroot).

no-such-file ★★★★★ ()
Ответ на: комментарий от ctopmbi4

Это пользователю можно запускать только то что в «whitelist» остальное запретить.

Древний вариант(не идеальный): chmod og-x на всё не нужное в /usr/bin, /bin и т.д.(и хук на пакетный менеджер, чтоб при обновлении не слетело), все ФС доступные пользователю на запись монтировать с noexec(есть если автомонтирование - с этим придётся повозится).

А вообще плюсую мандатную систему контроля доступа(SELinux или AppArmor - без разницы, что проще будет настраивать - то и настраивай).

Pinkbyte ★★★★★ ()
Ответ на: комментарий от alpha

если у пользователя есть ssh, то он может установить и запустить любое ПО

с noexec на /home и /tmp и запрещенным запуском компилятора? Как, кроме трюка с ld-linux.so(который ЕМНИП таки можно забанить через SELinux)?

Pinkbyte ★★★★★ ()
Ответ на: комментарий от ctopmbi4

Вам не обязательно запускать десктопное окружение, потому что иксы и десктопное окружение две зависимые, но самостоятельные сущности.

Настройте иксы так, чтобы они при начале сессии запускали не десктоп, а вашу Scada систему как оболочку и всё.

Или вообще не пользуйтесь иксами, а скомпилируйте свою Scada для работы через фреймбуфер.
Может просто напишите свою версию интерфейса.

но у разработчика контроллеров , Scada система только под Linux. Разработчик поставляет Scada систему вместе с ОС.

Эта Scada у разработчика опенсорсный проект?
Если да то свяжитесь с ним и предложите совместную работу над нужными вам улучшениями.
Конечно основную работу придётся делать вам, но зато какую-то часть изменений могут принять в основной проект.

В общем Linux это не винда и разрадотчик может с самого начала предполагать тесное с ним взаимодействие, не бесплатное конечно.

torvn77 ★★★★★ ()
Последнее исправление: torvn77 (всего исправлений: 2)
Ответ на: комментарий от torvn77

Ещё можно убрать «кнопку „Пуск“» с панели и сменив пользователя для некоторых файлов и каталогов сделать не возможными отмену этих изменений.

Или просто найти где в /usr находится глобальное меню и повыкидывать из него не нужные ярлыки программ.

Ещё можно поменять пользователя для ./Desktop чем не дать создать новые ярлыки для запуска программ, правда с KDE это не поможет, там десктоп функционирует иначе.

torvn77 ★★★★★ ()
Последнее исправление: torvn77 (всего исправлений: 1)
Ответ на: комментарий от viewizard

Благодарю. Получилось настроить через rbac. Но появился вопрос: Как можно выгрузить загруженный профайл? Манипуляции с выгрузкой модуля

 apparmor_parser -R /etc/apparmor.d/app_profile 
Удалил из дир.apparmor.d сам профайл. При загрузке apparmor подгружает его откуда с другого места.

Нашел что можно выгрузить все профайлы через скрипт с опцией teardown.

"/etc/init.d/apparmor teardown"
Но в скрипте этого нет. Буду благодарен за любую помощь.

ctopmbi4 ()
Ответ на: комментарий от anonymous

выгрузил

 apparmor_parser -R /etc/apparmor.d/app_profile 
из загруженных пропал.

загружаю заново

 apparmor_parser -a /etc/apparmor.d/app_profile 

выдает

Skipping profile in /etc/apparmor.d/app_profile

запускаю

apparmor start

профайл подгружается заново

/usr/bin/kdm
хотя там его нет. Как понимаю он его добавляет куда в ядро?

ctopmbi4 ()
Ответ на: комментарий от ctopmbi4

Удалил из дир.apparmor.d сам профайл. При загрузке apparmor подгружает его откуда с другого места.

В вашем случае, во время первой загрузки или загрузки измененного профиля при старте сервиса (/etc/init.d/apparmor), создается бинарный кэш. Файлы бинарных кэшей расположены в /etc/apparmor.d/cache/ и имеют такое же имя файла, как и исходный профиль в /etc/apparmor.d/.

По факту, профиль в текстовом виде — «исходный код», а бинарный кэш — «скомпилированный» из «исходного кода» блок данных, загружаемый в модуль ядра. Профили («исходный код») в ядро не загружаются, а используются исключительно утилитой apparmor_parser для создания бинарного кэша и его загрузки в модуль ядра. Для ускорения загрузки, apparmor_parser может сохранять бинарный кэш на диске (что и делает /etc/init.d/apparmor, вызывая apparmor_parser с ключем -W, полагаю).

viewizard ★★ ()
Ответ на: комментарий от no-such-file

Сделай отдельный конфиг для пользователя scada где не запускается DE, а сразу запускается scada система. Если он как-то сумеет её закрыть или уронить, то просто вывалится обратно в sddm (или что там у тебя). А там можно по таймеру перезагружать снова этот же профиль.

+1, и выключить все TTY кроме иксового

И да, тебе не нужен apparmor, тебе нужно запускать пользователя в контейнере (chroot).

Ему не нужен чрут, у него система используется строго под одну задачу

annulen ★★★★★ ()

О чём идёт разговор?

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

А если разговор о некой средней рабочей станции в вакууме на которой надо запретить некие подозрительные действия опять же внимание вопрос - ctopmbi4 тебе в таком случае чего нужно? Просто запретить или предотвратить и наказать? Но в любом из этих случаев - вочдогс от рута, логируем все процессы и все действия нужного юзера, если процесс не в белом списке делаем нужные действия. Хоть просто убивай процесс по тихому прикидываясь при этом шлангом. Хоть показывай на весь экран «атата». Хоть мыло/смс оправляй. Хоть бригаду добрых мужиков в балаклавах и с демократизаторами на указанный адрес.

init_6 ★★★★★ ()
Ответ на: комментарий от ctopmbi4

каким образом?

Долгим красноглазием.

anonymous ()
Ответ на: комментарий от viewizard

Благодарю, вроде как работает по крайне мере на виртуалке. Пришлось повозиться, понять, что и как запускается. По поводу пред. траблы с подгрузкой профиля. Решение только путем отката по snapshot, больше такой траблы не возникало. Видимо глюки виртуалки) У меня еще вопрос. Как можно задать default hat для пользователей у которых нет hat в текущем profile?

то есть при таком варианте

order=user,default

Конечно можно создать пустые правила для всех пользователей. Но как то не кашерно). Кстати кто-нибудь в курсе, что случилось с apparmor.net? ресурс не доступен с начала этого года.

ctopmbi4 ()
Ответ на: комментарий от ctopmbi4

Как можно задать default hat для пользователей у которых нет hat в текущем profile?

Есть default hat, который так и называется «^DEFAULT». Все пользователи, у которых явно не задан hat, будут использовать его. Но, есть один нюанс — профиль в режиме complain (обучения), всегда будет искать hat пользователя и не будет переходить на «^DEFAULT». Как только вы загрузите профиль в обычном режиме (enforce), все будет работать как надо и пользователи без профиля будут переходить на «^DEFAULT». Т.е. важно понимать, что «^DEFAULT» выступает в роли fallback и в процессе обучения просто не работает.

Кстати кто-нибудь в курсе, что случилось с apparmor.net? ресурс не доступен с начала этого года.

Все переехало на https://gitlab.com/apparmor, вики можно теперь найти тут: https://gitlab.com/apparmor/apparmor/wikis/home

Рекомендую подписаться на лист рассылки https://lists.ubuntu.com/mailman/listinfo/apparmor. В режиме дайджеста по 1 письму в день приходит и всегда знаешь, что происходит. :-)

viewizard ★★ ()
Ответ на: комментарий от viewizard

Столкнулся с проблемой. В KDE есть приложения которые запускаются через kdeinit4. Соответственно запуск самого kdeinit4 требуется для всех пользователей.

Как ограничить запуск определенных приложений через него не понятно. Так как hat работает только для приложений с авторизацией. И профиль от конкретного пользователя не наследуется его в другой профиль без авторизации. Вы как то решили подобную проблему?

ctopmbi4 ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.