Авторизация флешкой. Как сделать без PAM

24.02.2017 19:24 #420822

Вот задался целью организовать на нескольких машинах "железную" авторизацию.
И для того даже ~~существует~~ существовал модуль pam_usb
Но, по всей видимости, он уже умер, ибо на гите он висит в состоянии "[UNMAINTAINED] ", с последним обновлением почти годичной давности.
Ну это кагбЭ и не страшно, но оно хочет UDisks, а актуальный и используемый на всех машинах, где я эт хочу прикрутить, UDisks2
Вот тут и затык((( Прикручивать с home-реп или собирать руками старый udisks особо желания нету...

Вот и встал вопрос: Есть ли что-то еще в природе, кроме pam_usb, для авторизации по флЮшкам??

Вообще конечная идея следующая:
Имеем несколько машин, настроеных абсолютно аналогично и хомяки пользователей на флешках
Втыкаем флешку => монтируется хомяк => авторизация этого пользователя.

24.02.2017 21:25 #420825

С

"DiabloPC" написал:
Втыкаем флешку => монтируется хомя

все вроде бы несложно. В fstab имеем UUID флешки (флешек), и ее (их) точк(у,и) монтирования. Хомяк(,и) зашифрован(,ы), леж(и,а)т на целевых машинах, а в качестве кодовой фразы на флешк(е,ах) лежит открыты(й,е) ключ(и). Флешка втыкается, монтируется, далее по этому событию отрабатывает сценарий, который сканирует флешку на предмет файла-ключа, и скармливает найденный ключ luks-у.

24.02.2017 21:36 #420828

"yars" написал:
лежат на целевых машинах

Та вот тут как раз вся идея в том чтобы хомяк был на флешке, суть не в обеспечении безопасности файлов, а в наличии своих файлов всегда под рукой + наличие всех настроек десктопа\софта.
Т.е. шифрование здесь 100 лет не нужно))
А данные, как раз, на флешке нужны, а не на целевой машине

ЗЫ
Про вариант какогонить сервера можно точно забыть, ибо машины в разных концах города и не у всех даже выход в нэт имеется %))

24.02.2017 21:50 #420830

Тогда задача упрощается. Берем udev и...

text

ACTION=="add", SUBSYSTEM=="usb", ENV{ID_TYPE}=="disk", ENV{ID_PART_TABLE_UUID}=="7599a96e-6b1e-4f46-bf2c-99bc235e55f9", RUN+="exec /bin/login -f $USERNAME"

Это помещаем в /etc/udev/rules.d/ИМЯ_ФАЙЛА.rules.
Как-то так, но quick&dirty, может не работать и/или быть небезопасным решением.
P.S. И да, лучше обернуть вызов /bin/login в сценарий, который бы гарантировал, что домашний каталог пользователя примонтирован. И неплохо бы man login изучить перед экспериментами.

24.02.2017 22:04 #420832

"yars" написал:
Берем udev и...

Хммм, похоже действительно упрощается))

"yars" написал:
обернуть вызов /bin/login в сценарий

Тож об этом подумал, да собственно и монтирование хомяка туда-же можно отправить, вместо fstab

"yars" написал:
И неплохо бы man login изучить

Ага, и man udev до кучи..... Пшел учить

25.02.2017 08:00 #420837

Итак
Начал я копать сначала в сторону удава, чтобы заставить его выполнять хоть что-то по факту втыкания флешки, но травить я его стал не на USB, а на ММС...
Первое что удалось раскопать - это то что на RUN+="exec ololo" удав нагло меня посылал в поле, хотя [highlight=#000]# udevadm test /sys/block/mmcblk0/mmcblk0p1[/highlight] говорил что все впорядке
Ну ок, пробуем без exec - все ок.

Дальше попробовал скормить ему UUID тома - ан нет, не тут то было....
ENV{ID_PART_TABLE_UUID}=="" - при впихивании этого атрибута удав нагло отказывался реагировать на карту((
...более глубокое копание рассказало мне как просмотреть весь список доступных атрибутов - [highlight=#000]# udevadm info -a -n {devname}[/highlight]

"Ну что ж - посмотрим:"

[console=root]udevadm info -a -n mmcblk0p1

Udevadm info starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.

looking at device '/devices/pci0000:00/0000:00:1e.0/0000:38:03.2/mmc_host/mmc0/mmc0:1234/block/mmcblk0/mmcblk0p1':
KERNEL=="mmcblk0p1"
SUBSYSTEM=="block"
DRIVER==""
ATTR{alignment_offset}=="0"
ATTR{discard_alignment}=="3145728"
ATTR{inflight}==" 0 0"
ATTR{make-it-fail}=="0"
ATTR{partition}=="1"
ATTR{ro}=="0"
ATTR{size}=="3852288"
ATTR{start}=="2048"
ATTR{stat}==" 90 0 7240 2444 0 0 0 0 0 1172 2444"

looking at parent device '/devices/pci0000:00/0000:00:1e.0/0000:38:03.2/mmc_host/mmc0/mmc0:1234/block/mmcblk0':
KERNELS=="mmcblk0"
SUBSYSTEMS=="block"
DRIVERS==""
ATTRS{alignment_offset}=="0"
ATTRS{badblocks}==""
ATTRS{capability}=="10"
ATTRS{discard_alignment}=="0"
ATTRS{ext_range}=="8"
ATTRS{force_ro}=="0"
ATTRS{inflight}==" 0 0"
ATTRS{make-it-fail}=="0"
ATTRS{range}=="8"
ATTRS{removable}=="0"
ATTRS{ro}=="0"
ATTRS{size}=="3854336"
ATTRS{stat}==" 104 0 8296 2820 0 0 0 0 0 1352 2820"

looking at parent device '/devices/pci0000:00/0000:00:1e.0/0000:38:03.2/mmc_host/mmc0/mmc0:1234':
KERNELS=="mmc0:1234"
SUBSYSTEMS=="mmc"
DRIVERS=="mmcblk"
ATTRS{cid}=="02544d53413032470521c66cd700ab00"
ATTRS{csd}=="002e00325b5aa3acffffff800a800000"
ATTRS{date}=="11/2010"
ATTRS{erase_size}=="512"
ATTRS{fwrev}=="0x5"
ATTRS{hwrev}=="0x0"
ATTRS{manfid}=="0x000002"
ATTRS{name}=="SA02G"
ATTRS{oemid}=="0x544d"
ATTRS{preferred_erase_size}=="4194304"
ATTRS{scr}=="0225800001000000"
ATTRS{serial}=="0x21c66cd7"
ATTRS{type}=="SD"

looking at parent device '/devices/pci0000:00/0000:00:1e.0/0000:38:03.2/mmc_host/mmc0':
KERNELS=="mmc0"
SUBSYSTEMS=="mmc_host"
DRIVERS==""

looking at parent device '/devices/pci0000:00/0000:00:1e.0/0000:38:03.2':
KERNELS=="0000:38:03.2"
SUBSYSTEMS=="pci"
DRIVERS=="sdhci-pci"
ATTRS{broken_parity_status}=="0"
ATTRS{class}=="0x080501"
ATTRS{consistent_dma_mask_bits}=="32"
ATTRS{d3cold_allowed}=="1"
ATTRS{device}=="0x7120"
ATTRS{dma_mask_bits}=="32"
ATTRS{driver_override}=="(null)"
ATTRS{enable}=="1"
ATTRS{irq}=="17"
ATTRS{local_cpulist}=="0-1"
ATTRS{local_cpus}=="3"
ATTRS{msi_bus}=="1"
ATTRS{numa_node}=="-1"
ATTRS{subsystem_device}=="0x143d"
ATTRS{subsystem_vendor}=="0x10cf"
ATTRS{vendor}=="0x1217"

looking at parent device '/devices/pci0000:00/0000:00:1e.0':
KERNELS=="0000:00:1e.0"
SUBSYSTEMS=="pci"
DRIVERS==""
ATTRS{broken_parity_status}=="0"
ATTRS{class}=="0x060401"
ATTRS{consistent_dma_mask_bits}=="32"
ATTRS{d3cold_allowed}=="0"
ATTRS{device}=="0x2448"
ATTRS{dma_mask_bits}=="32"
ATTRS{driver_override}=="(null)"
ATTRS{enable}=="1"
ATTRS{irq}=="0"
ATTRS{local_cpulist}=="0-1"
ATTRS{local_cpus}=="3"
ATTRS{msi_bus}=="1"
ATTRS{numa_node}=="-1"
ATTRS{subsystem_device}=="0x1468"
ATTRS{subsystem_vendor}=="0x10cf"
ATTRS{vendor}=="0x8086"

looking at parent device '/devices/pci0000:00':
KERNELS=="pci0000:00"
SUBSYSTEMS==""
DRIVERS==""

[/console]

Про ID либо UUID ФС там небыло ни слова (или я плохо смотрел??), но нашлось пару весьма интересных атрибутов в родительском устройстве

text

    ATTRS{cid}=="02544d53413032470521c66cd700ab00"
    ATTRS{csd}=="002e00325b5aa3acffffff800a800000"

~~Опытным путем~~ методом научного втыка выяснилось что они имеют отношение к конкретной карте и, что самое интересное, никаким боком не имеют отношения к данным на самой карте, т.е. снос_таблицы\форматирование эти даные не изменяют, так что получается что карта остается ключoм даже в случае порчи данных на ней и вынужденого форматирования.

В принципе лично меня это устроило даже больше чем привязка к UUID ФС.

В итоге получилось вот такая пара правил:

text

ACTION=="add", KERNEL=="mmcblk0p1", SUBSYSTEM=="block",  ATTRS{cid}=="02544d53413032470521c66cd700ab00", ATTRS{csd}=="002e00325b5aa3acffffff800a800000", RUN+="/login"
ACTION=="remove", KERNEL=="mmcblk0p1", SUBSYSTEM=="block",  ATTRS{cid}=="02544d53413032470521c66cd700ab00", ATTRS{csd}=="002e00325b5aa3acffffff800a800000", RUN+="/logout"

Что ж - осталось только разобраться с login\logout....

Пшел читать дальше)

25.02.2017 09:44 #420838

Ну у меня все задом наперед :D

С loguot разобрался, все оказалось до банальности просто (спасает наличие d-bus)

text

#!/bin/bash
su - $USERNAME --command="DISPLAY=:0 qdbus org.kde.ksmserver /KSMServer org.kde.KSMServerInterface.logout 0 0 0"

А вот с login немного печальнее
Вход в tty - ясноПонятно

text

#!/bin/bash
exec login -f mb < /dev/ttyX > /dev/ttyX 2>&1

А с KDM - темный лес.... Ничерта не могу понять как ему (KDM'y) объяснить что нужно войти под определенным пользователем не задавая лишних вопросов....

Зы
Есть конечно идея организовать это через .bashrc:

text

if [[ `tty` = /dev/tty1 ]] ; then
 killall kdm
  startkde
  logout
fi

...а потом перезапускать его при завершении сесии....

Но, помоему, это уж слишком, каждый раз прибивать kdm...

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

25.02.2017 11:07 #420839

А в деле разве не новомодный sddm? Если он, понятно, пинать надо его.

25.02.2017 11:08 #420840

"yars" написал:
А в деле разве не новомодный sddm

Шото он мне по душе не пришелся, так что только хардкор, только kdm *CRAZY*

На самом деле просто не удалось вывести экранную клавиатуру поверх sddm, тогда как в kdm все чудно работает, поэтому и остался на нем, по старой привычке))

25.02.2017 14:31 #420841

Продолжение копаний в удаве:
как оказалось, правило

text

ACTION=="remove", KERNEL=="mmcblk0p1", SUBSYSTEM=="block",  ATTRS{cid}=="02544d53413032470521c66cd700ab00", ATTRS{csd}=="002e00325b5aa3acffffff800a800000", RUN+="/logout"

напрочь не срабатует
в /[login|logout] оставил пока просто

text

#!/bin/bash
echo [login|logout] `date` >> /login.log

На этом и словил...

Пока в правиле на отключение оставил просто вот такое

text

KERNEL=="mmcblk0", ACTION=="remove", RUN+="/logout"

Так работает

А не работает при наличии одного из либо обеих параметров

text

ATTRS{cid}=="02544d53413032470521c66cd700ab00"
ATTRS{csd}=="002e00325b5aa3acffffff800a800000",

....пока Хз куда смотреть..

25.02.2017 16:39 #420848

С выходом из сеанса есть одна проблема, а именно -- мы выдергиваем флешку, пока она смонтирована. А надо бы разлогиниться, сделать sync, и уже потом размонтировать и только после этого выдергивать. Что же до отключения, насколько я сам понял, udev может только знать, какое именно устройство отключили, и свойства его для udev-a перестают существовать.

25.02.2017 16:44 #420849

"yars" написал:
. А надо бы разлогиниться

Это будет слишком жирно )))))

"yars" написал:
сделать sync

Это конечно небольшой затык, но, надеюсь, небуферизированая запись немного поможет... а все остальное уж положим на "волю случая" *CRAZY*

"yars" написал:
и свойства его для udev-a перестают существовать

хммм.... это немного плохо, буду думать как это обойти, ибо с ММС - проблем меньше - оно одно такое в системе, а вот флешек может и поболее оказаться...

Зы
пока копаюсь с этим - обнаружил в своих владениях, на двух железках, устройства чтения смарткарт o_O
Я и не подозревал об их существовании у меня

27.02.2017 01:11 #420869

"DiabloPC" написал:
А с KDM - темный лес....

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

27.02.2017 01:30 #420870

yars, ну конфиги это конечно вариант, но не радует мысль о постоянных рестартах kdm... некошерно это

А я тут с другой стороны зашел:
Чертов pam ведь как-то авторизуется... Причем что в кдм, что в гдм.... Значит есть какой-то механизм, да еще и универсальный)

Потихоньку читаю исходники libpam'a *CRAZY*

Ну как-то ж он это делает.....

27.02.2017 18:09 #420873

А можно и вообще без PAM, без KDM:

text

cat ~/.xinitrc
userresources=$HOME/.Xresources
usermodmap=$HOME/.Xmodmap
sysresources=/etc/X11/xinit/.Xresources
sysmodmap=/etc/X11/xinit/.Xmodmap
if [ -f $sysresources ]; then
    /usr/bin/xrdb -merge $sysresources
fi
if [ -f $sysmodmap ]; then
    /usr/bin/xmodmap $sysmodmap
fi
if [ -f $userresources ]; then
    /usr/bin/xrdb -merge $userresources
fi
if [ -f $usermodmap ]; then
    /usr/bin/xmodmap $usermodmap
fi
#######################################
##   Start KDE Desktop Environment   ##
#######################################
if [ -z "$DESKTOP_SESSION" -a -x /usr/bin/ck-launch-session ]; then
  exec ck-launch-session dbus-launch --exit-with-session /usr/bin/startkde
else
  exec dbus-launch --exit-with-session /usr/bin/startkde
fi

Как-то так.