Bug 28277
| Summary: | Нельзя снять блокировку экрана e17 | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Sisyphus | Reporter: | AEN <aen> | ||||||||
| Component: | e17 | Assignee: | Yuri N. Sedunov <aris> | ||||||||
| Status: | CLOSED FIXED | QA Contact: | qa-sisyphus | ||||||||
| Severity: | normal | ||||||||||
| Priority: | P3 | CC: | ldv, led, manowar, mike, rider, sbolshakov, vladimir.didenko | ||||||||
| Version: | unstable | ||||||||||
| Hardware: | all | ||||||||||
| OS: | Linux | ||||||||||
| Bug Depends on: | |||||||||||
| Bug Blocks: | 27685 | ||||||||||
| Attachments: |
|
||||||||||
(В ответ на комментарий №0)
> После включения блокировки из нее удается выйти, сообщается о неверном пароле.
> Этот эффект сейчас только для e17.
не удается, конечно
workaround. Установив xscreensaver и задав в настройках e17 команду /usr/bin/xscreenlock для блокировки экрана, получим работающую блокировку. Непонятно, есть ли собственный умалчиваемый хранитель экрана у e17 и как он вызывается. Бага остается открытой, но major->normal . (In reply to comment #2) > workaround. > Установив xscreensaver и задав в настройках e17 команду /usr/bin/xscreenlock > для блокировки экрана, получим работающую блокировку. > Непонятно, есть ли собственный умалчиваемый хранитель экрана у e17 и как он > вызывается. Собственный встроен в /usr/bin/enlightenment, и с нашим pam_tcb, разумеется, не работает. (В ответ на комментарий №3) > (In reply to comment #2) > > workaround. > > Установив xscreensaver и задав в настройках e17 команду /usr/bin/xscreenlock > > для блокировки экрана, получим работающую блокировку. > > Непонятно, есть ли собственный умалчиваемый хранитель экрана у e17 и как он > > вызывается. > > Собственный встроен в /usr/bin/enlightenment, и с нашим pam_tcb, разумеется, не > работает. Я вижу два варианта: 1. Исправить встроенный, чтобы он работал с pam_tcb. Замечу, что _все_ остальные скринсейверы из Сизифа уже работают с ним. 2. Изменить умолчания. (In reply to comment #4) > (В ответ на комментарий №3) > > (In reply to comment #2) > > > workaround. > > > Установив xscreensaver и задав в настройках e17 команду /usr/bin/xscreenlock > > > для блокировки экрана, получим работающую блокировку. > > > Непонятно, есть ли собственный умалчиваемый хранитель экрана у e17 и как он > > > вызывается. > > > > Собственный встроен в /usr/bin/enlightenment, и с нашим pam_tcb, разумеется, не > > работает. > > Я вижу два варианта: > 1. Исправить встроенный, чтобы он работал с pam_tcb. Замечу, что _все_ > остальные скринсейверы из Сизифа уже работают с ним. > 2. Изменить умолчания. Со временем, что-нибудь сделается. Попутно еще надо разобраться с тремя суидными бинарниками в составе e17, с помощью которых он выполняет системные действия. (В ответ на комментарий №5) > Попутно еще надо разобраться с тремя > суидными бинарниками в составе e17, с помощью которых он выполняет системные > действия. Да, спасибо, это важно. https://bugzilla.altlinux.org/show_bug.cgi?id=28291
29.01.2013 20:58, Dmitry V. Levin пишет:
>>> > > 434 ptrace(PT_TRACE_ME, 0, NULL, NULL);
> Занавес.
>
> Попробуй запускать enlightenment_start с ключом
> -i-really-know-what-i-am-doing-and-accept-full-responsibility-for-it
---
Есть идея запускать enlightenment_start без всяких опций, но пропускать выполнение ptrace в том случае, если на /usr/bin/enlightenment установлен setgid-бит.
При попытке обратиться к dbus получает отлуп: "Unable to autolaunch when setuid". Видимо, это вот этот коммит: http://git.altlinux.org/gears/d/dbus.git?p=dbus.git;a=commitdiff;h=a52319bc294d05445fd8aa8f4a7f759c34558b5d Мне он не нравится хотя бы потому, что одновременно запрещает использовать адрес из окружения ($DBUS_SESSION_BUS_ADDRESS) и запускать новую шину (autolaunch). Получается, что setuid/setgid программы вообще не могут использовать dbus. Обобщённая формулировка текущей проблемы: проверка пароля в Альт требует дополнительных привилегий для программы, но никакие дополнительные привилегии не совместимы с libdbus.
Сейчас подумал, что самым корректным способом обойти эту проблему было бы добавить в libdbus возможность явным образом задать адрес для соединения, т.е. содержимое bus_connection_addresses[i]. Тогда привилегированная программа могла бы прописать туда доверенный адрес, выполнив перед этим все необходимые проверки.
И зацепка такая есть:
/* So it's not in the environment - let's try a platform-specific method.
* On MacOS, this involves asking launchd. On Windows (not specified yet)
* we might do a COM lookup.
* Ignore errors - if we failed, fall back to autolaunch. */
retval = _dbus_lookup_session_address (&supported, &addr, &error);
Можно попробовать добавить такой "platform-specific method" для нашей расчудесной платформы. :)
Created attachment 5736 [details]
Добавляет в libdbus функцию для явного указания адреса шины
Я нарисовал такой патч к libdbus: наверное простой функции для задания адреса будет достаточно?
Created attachment 5737 [details]
Явно выставляет адрес шины
Ответная часть в enlightenment пока очень простая: нужно ещё будет добавить проверку на то, чтобы адрес был сокетом.
(In reply to comment #8) > При попытке обратиться к dbus получает отлуп: "Unable to autolaunch when > setuid". Видимо, это вот этот коммит: > > http://git.altlinux.org/gears/d/dbus.git?p=dbus.git;a=commitdiff;h=a52319bc294d05445fd8aa8f4a7f759c34558b5d > > Мне он не нравится хотя бы потому, что одновременно запрещает использовать > адрес из окружения ($DBUS_SESSION_BUS_ADDRESS) и запускать новую шину > (autolaunch). Получается, что setuid/setgid программы вообще не могут > использовать dbus. Я считаю, что проверка в libdbus неоправданно жесткая. Cуть _dbus_check_setuid() заключается в том, чтобы выяснить, является ли процесс настолько привилегированным, чтобы это давало возможность использовать libdbus таким образом, чтобы добиться чего-то недоступного обычному процессу. Я не вижу, каким образом значение saved set-group-ID может повлиять на поведение libdbus, следовательно, проверка saved set-group-ID не нужна. (In reply to comment #12) > Created an attachment (id=5737) [details] > Явно выставляет адрес шины > > > Ответная часть в enlightenment пока очень простая: нужно ещё будет добавить > проверку на то, чтобы адрес был сокетом. Фактически, это будет дублированием кода из libdbus? (В ответ на комментарий №13) > (In reply to comment #8) > > При попытке обратиться к dbus получает отлуп: "Unable to autolaunch when > > setuid". Видимо, это вот этот коммит: > > > > http://git.altlinux.org/gears/d/dbus.git?p=dbus.git;a=commitdiff;h=a52319bc294d05445fd8aa8f4a7f759c34558b5d > > > > Мне он не нравится хотя бы потому, что одновременно запрещает использовать > > адрес из окружения ($DBUS_SESSION_BUS_ADDRESS) и запускать новую шину > > (autolaunch). Получается, что setuid/setgid программы вообще не могут > > использовать dbus. > > Я считаю, что проверка в libdbus неоправданно жесткая. Cуть > _dbus_check_setuid() заключается в том, чтобы выяснить, является ли процесс > настолько привилегированным, чтобы это давало возможность использовать libdbus > таким образом, чтобы добиться чего-то недоступного обычному процессу. Я не > вижу, каким образом значение saved set-group-ID может повлиять на поведение > libdbus, следовательно, проверка saved set-group-ID не нужна. А saved set-user-ID ? (In reply to comment #15) > (В ответ на комментарий №13) > > (In reply to comment #8) > > > При попытке обратиться к dbus получает отлуп: "Unable to autolaunch when > > > setuid". Видимо, это вот этот коммит: > > > > > > http://git.altlinux.org/gears/d/dbus.git?p=dbus.git;a=commitdiff;h=a52319bc294d05445fd8aa8f4a7f759c34558b5d > > > > > > Мне он не нравится хотя бы потому, что одновременно запрещает использовать > > > адрес из окружения ($DBUS_SESSION_BUS_ADDRESS) и запускать новую шину > > > (autolaunch). Получается, что setuid/setgid программы вообще не могут > > > использовать dbus. > > > > Я считаю, что проверка в libdbus неоправданно жесткая. Cуть > > _dbus_check_setuid() заключается в том, чтобы выяснить, является ли процесс > > настолько привилегированным, чтобы это давало возможность использовать libdbus > > таким образом, чтобы добиться чего-то недоступного обычному процессу. Я не > > вижу, каким образом значение saved set-group-ID может повлиять на поведение > > libdbus, следовательно, проверка saved set-group-ID не нужна. > > А saved set-user-ID ? Тоже не нужна, в принципе, но у нас таких приложений нет. OK. Я тогда нарисую такой патчик и зашлю его на freedesktop.org. Посмотрим, что они мне ответят на этот раз. (In reply to comment #17) > OK. Я тогда нарисую такой патчик и зашлю его на freedesktop.org. Посмотрим, > что они мне ответят на этот раз. fc3a5d62dde8314177106e32fb4029cf794e91d3 у меня в dbus.git (В ответ на комментарий №18) > (In reply to comment #17) > > OK. Я тогда нарисую такой патчик и зашлю его на freedesktop.org. Посмотрим, > > что они мне ответят на этот раз. > > fc3a5d62dde8314177106e32fb4029cf794e91d3 у меня в dbus.git Ага. Подожди собирать: апстрим вроде бы идёт на контакт — пусть посмотрят. Дима, с freedesktop'а ответили. Посмотри, пожалуйста. И вот по поводу подгружаемых модулей e17, получающих chkpwd за просто так, тоже важное замечание: https://bugs.freedesktop.org/show_bug.cgi?id=60667#c7 Может быть мы пойдём другим путём? :) ... GNOME 3 in non-fallback mode integrates the screensaver into GNOME Shell rather than using an external gnome-screensaver... А вот это уже очень интересно, поскольку в gnome3 залочка снимается без проблем. Выходит, есть способ. (In reply to comment #22) > И вот по поводу подгружаемых модулей e17, получающих chkpwd за просто так, тоже > важное замечание: > > https://bugs.freedesktop.org/show_bug.cgi?id=60667#c7 > > > Может быть мы пойдём другим путём? :) Если есть возможность пойти другим путем и не делать весь e17 привилегированным, то почему мы еще не пошли этим путем? С другой стороны, если e17, не будучи привилегированным, сможет проверять пароль, то что помешает кому попало делать то же самое? (В ответ на комментарий №24) > (In reply to comment #22) > > И вот по поводу подгружаемых модулей e17, получающих chkpwd за просто так, тоже > > важное замечание: > > > > https://bugs.freedesktop.org/show_bug.cgi?id=60667#c7 > > > > > > Может быть мы пойдём другим путём? :) > > Если есть возможность пойти другим путем и не делать весь e17 > привилегированным, то почему мы еще не пошли этим путем? Так его нужно сперва найти, этот путь. ;) В одном Саймон, кажется, прав: пользователь может легко написать модуль взлома пароля и подключить его к e17. Нельзя ставить динамически расширяемым программам suid/sgid. :( > С другой стороны, если e17, не будучи привилегированным, сможет проверять > пароль, то что помешает кому попало делать то же самое? Нужно пристально взглянуть как это происходит в GNOME Shell. Потому как там: а) локер выглядит интегрированным, б) он проверяет успешно пароль. Насколько я сумел разобраться, gnome-shell использует интерфейс Gdm.UserVerifier [1] для проверки пароля, причём как в хранителе экрана, так и в окне входа в систему (последнее теперь тоже отображается через gnome-shell). Однако как в точности всё это работает и может ли обычный пользователь/программа воспользоваться этим сервисом я пока не понял. --- [1] http://www.roojs.org/seed/gir-1.2-gtk-3.0/seed/Gdm.UserVerifier.html (В ответ на комментарий №25)
> > > Может быть мы пойдём другим путём? :)
> >
> > Если есть возможность пойти другим путем и не делать весь e17
> > привилегированным, то почему мы еще не пошли этим путем?
>
> Так его нужно сперва найти, этот путь. ;)
А существует ли надёжный способ опознать программу на другом конце stdin? Если так, то давайте сделаем небольшой sgid хелпер, который будет соглашаться проверять пароль только если он 1) получает stdin от родителя; 2) этим родителем является /usr/bin/enlightenment.
(In reply to comment #27) > (В ответ на комментарий №25) > > > > Может быть мы пойдём другим путём? :) > > > > > > Если есть возможность пойти другим путем и не делать весь e17 > > > привилегированным, то почему мы еще не пошли этим путем? > > > > Так его нужно сперва найти, этот путь. ;) > > А существует ли надёжный способ опознать программу на другом конце stdin? Если это AF_UNIX socket, то можно узнать pid и euid процесса, создавшего этот сокет, и сравнить с parent'ом. Зная $pid, можно смотреть на /proc/$pid/exe и /proc/$pid/cmdline. См. напр. http://git.altlinux.org/people/ldv/packages/?p=openssh.git;a=blob;f=openssh/openbsd-compat/getpeerproc.c Но у tcb_chkpwd stdin не socket а pipe. > Если так, то давайте сделаем небольшой sgid хелпер, который будет соглашаться > проверять пароль только если он 1) получает stdin от родителя; 2) этим > родителем является /usr/bin/enlightenment. Насколько я понимаю, проблема именно в монолитности /usr/bin/enlightenment. (В ответ на комментарий №28) > > Если так, то давайте сделаем небольшой sgid хелпер, который будет соглашаться > > проверять пароль только если он 1) получает stdin от родителя; 2) этим > > родителем является /usr/bin/enlightenment. > > Насколько я понимаю, проблема именно в монолитности /usr/bin/enlightenment. Совсем не хочется выпиливать весь desklock хотя бы потому, что у интегрированного потенциально появляется больше интересных для пользователя возможностей, не говоря уже об огромном разломе с апстримом, который появится в результате такого выпиливания. А вот заменить прямой вызов pam_*() на какой либо опосредованный IPC проблемы нет — я готов. Весь вопрос в том, как не сделать хелпер "для всех". (In reply to comment #29) > (В ответ на комментарий №28) > > > > Если так, то давайте сделаем небольшой sgid хелпер, который будет соглашаться > > > проверять пароль только если он 1) получает stdin от родителя; 2) этим > > > родителем является /usr/bin/enlightenment. > > > > Насколько я понимаю, проблема именно в монолитности /usr/bin/enlightenment. > > Совсем не хочется выпиливать весь desklock хотя бы потому, что у > интегрированного потенциально появляется больше интересных для пользователя > возможностей, не говоря уже об огромном разломе с апстримом, который появится в > результате такого выпиливания. А вот заменить прямой вызов pam_*() на какой > либо опосредованный IPC проблемы нет — я готов. Весь вопрос в том, как не > сделать хелпер "для всех". Как ты можешь заменить вызов pam_authenticate(), если ты не знаешь, что он спросит у пользователя во время работы? (В ответ на комментарий №30) > Как ты можешь заменить вызов pam_authenticate(), если ты не знаешь, что он > спросит у пользователя во время работы? Так из входных данных у меня только пароль. Соответственно только его и скармливаю в хелпер. Остальное хелпер должен сделать сам и ответить мне, снимать блокировку экрана или нет. (In reply to comment #31) > (В ответ на комментарий №30) > > > Как ты можешь заменить вызов pam_authenticate(), если ты не знаешь, что он > > спросит у пользователя во время работы? > > Так из входных данных у меня только пароль. pam_authenticate() может спрашивать не только tcb'шный пароль, но и вообще что угодно. Например, если используется авторизация смарт-картой, то это будет совсем другой пароль, проверяемый без участия tcb_chkpwd. То, что (В ответ на комментарий №32) > (In reply to comment #31) > > (В ответ на комментарий №30) > > > > > Как ты можешь заменить вызов pam_authenticate(), если ты не знаешь, что он > > > спросит у пользователя во время работы? > > > > Так из входных данных у меня только пароль. > > pam_authenticate() может спрашивать не только tcb'шный пароль, но и вообще что > угодно. Судя по _desklock_auth_pam_conv() [1] e17 умеет отвечать только заранее заготовленными именем пользователя и паролем. Передавать пользователю интерактивно какие-то специфичные вопросы от PAM он не умеет. --- [1] http://git.altlinux.org/people/manowar/packages/e17.git?p=e17.git;a=blob;f=enlightenment/src/bin/e_desklock.c;h=f28179039ee82e69c092020abb24a921f578794d;hb=0e845b49daf4e118e50134e70a0e760b58c0069f#l1123 Created attachment 5796 [details]
Поддержка PAM-хелпера
Приложенный патч добавляет поддержку проверки пароля в блокировщике экрана с помощью хелпера chkpwd-pam.
При сборке неоходимо добавит ключ для %configure --with-pam-helper=/usr/libexec/chkpwd-pam
(В ответ на комментарий №34) > Created an attachment (id=5796) [details] > Поддержка PAM-хелпера > > Приложенный патч добавляет поддержку проверки пароля в блокировщике экрана с > помощью хелпера chkpwd-pam. > При сборке неоходимо добавит ключ для %configure > --with-pam-helper=/usr/libexec/chkpwd-pam О! 2led@: Спасибо! А можно собрать такой e17 test-only? 2aris@: прошу содействия, в частности хорошо бы проверить для e18 (не срочно, но важно). (В ответ на комментарий №34) > Created an attachment (id=5796) [details] > Поддержка PAM-хелпера > > Приложенный патч добавляет поддержку проверки пароля в блокировщике экрана с > помощью хелпера chkpwd-pam. 2all: Вот он в Сизифе: http://packages.altlinux.org/en/Sisyphus/srpms/chkpwd-pam Может быть я что-то упустил в пакете chkpwd-pam, но когда я обсуждал с ldv@ возможность такого решения, то он ответил, что проще просто убрать требование наличия группы chkpwd, чем использовать доступный пользователю хелпер. Скажите, пожалуйста, что теперь, когда пакет "chkpwd-pam" находится в Сизифе, мешает пользователю, не входящему в группу chkpwd, запускать chkpwd-pam и заниматься подбором пароля? (In reply to comment #37) > Скажите, пожалуйста, что теперь, когда пакет "chkpwd-pam" находится в Сизифе, > мешает пользователю, не входящему в группу chkpwd, запускать chkpwd-pam и > заниматься подбором пароля? Предполагается встроить в chkpwd-pam средства, ограничивающие доступ и затрудняющие подбор. Давайте, пока не поздно, поменяем /usr/libexec/chkpwd-pam на /usr/libexec/chkpwd-pam/chkpwd-pam. (В ответ на комментарий №38) > Давайте, пока не поздно, поменяем > /usr/libexec/chkpwd-pam на /usr/libexec/chkpwd-pam/chkpwd-pam. Зачем? Только для того, чтобы каталог /usr/libexec/chkpwd-pam/ был "root:$GROUP 2710", где $GROUP равен, например xgrp? (In reply to comment #39) > (В ответ на комментарий №38) > > Давайте, пока не поздно, поменяем > > /usr/libexec/chkpwd-pam на /usr/libexec/chkpwd-pam/chkpwd-pam. > > Зачем? Только для того, чтобы каталог /usr/libexec/chkpwd-pam/ был "root:$GROUP > 2710", где $GROUP равен, например xgrp? Да, для будущего ограничения доступа, не обязательно xgrp. (В ответ на комментарий №40) > (In reply to comment #39) > > (В ответ на комментарий №38) > > > Давайте, пока не поздно, поменяем > > > /usr/libexec/chkpwd-pam на /usr/libexec/chkpwd-pam/chkpwd-pam. > > > > Зачем? Только для того, чтобы каталог /usr/libexec/chkpwd-pam/ был "root:$GROUP > > 2710", где $GROUP равен, например xgrp? > > Да, для будущего ограничения доступа, не обязательно xgrp. Сделано в chkpwd-pam-0.1.0-alt2: /usr/libexec/chkpwd-pam/chkpwd-pam В тестовой сборке 93678 блокировка успешно снимается. в P6 тоже отправьте, пожалуйста. e17-1:0.17.1-alt2 -> sisyphus: * Wed Apr 03 2013 Led <led@altlinux> 1:0.17.1-alt2 - with pam helper (ALT#28277) Эээ... у меня пока не получается подтвердить, что исправлено; на своём ноутбуке с 1:0.17.1-alt2 и на http://nightly.altlinux.org/sisyphus/snapshots/20130409/regular-e17-20130409-i586.iso с 1:0.17.1-alt3 зайти после блокирования экрана встроенным локером не получается (номер для SMS при этом не предлагает). Ой. При попытке показать ldv@ удалось зайти как со своим, так и с заведомо неправильным паролем, при этом в /var/log/auth/all и на tty12 никаких сообщений от pam не поступило (точно помню, что при предыдущей проверке pam.*enlightenment было). (В ответ на комментарий №46)
> pam.*enlightenment
Точнее, хелпер. Хотя надо бы перепроверить, вопрос -- как...
chkpwd-pam-0.1.1.1-alt1 * Tue Apr 09 2013 Led <led@altlinux.ru> 0.1.1.1-alt1 - chkpwd-pam.c: fixed lockdir path |
Description
AEN 2012-12-26 13:11:13 MSK