Eu criei o seguinte [email protected]serviço para systemd:
[Unit]
Description=Cryptography Setup for '%I'
After=cryptsetup-pre.target
After=dev-mapper-%i.device
Before=cryptsetup.target
Before=umount.target
BindsTo=dev-mapper-%i.device
BindsTo=dev-mapper-%i.luks.device
Conflicts=umount.target
DefaultDependencies=no
IgnoreOnIsolate=true
RequiresMountsFor=/home
[Service]
ExecStart=/usr/lib/systemd/systemd-cryptsetup attach '%I.luks' '/dev/mapper/%I' '%h/%I/secret.key' 'luks,header=%h/%I/header'
ExecStop=/usr/lib/systemd/systemd-cryptsetup detach '%I.luks'
KillMode=none
RemainAfterExit=yes
TimeoutSec=0
Type=oneshot
[Install]
WantedBy=default.target
A ideia é descriptografar determinado xxxdispositivo criptografado por LUKS xxx.luksapenas para um determinado usuário, que habilita o serviço com, por exemplo:
systemctl --user enable luks@xxx
Infelizmente, mesmo testando-o com
systemctl --user start luks@xxx
falha porque sempre retorna com o código de saída 1sem indicar o motivo real. Para mim, ficou claro que o problema provavelmente está nas permissões. Tenho certeza de que, para acionar manualmente cryptsetup luksOpen ..., é necessário elevar o shell, por exemplo, com sudo. Na verdade, se eu emitir
sudo systemctl start luks@xxx
funciona perfeitamente e da mesma forma
sudo systemctl enable luks@xxx
funcionaria para a fase de inicialização.
OBSERVAÇÃO:
Para tal instalação em todo o sistema, é claro que é necessário modificar o serviço, substituindo-%ho pelo diretório inicial real de um usuário fornecedor, o que é feio e, de qualquer maneira, não atende ao propósito final.
Agora, estou ciente de pam_mountque é capaz de fazer montagens semelhantes (que não posso usar porque não suporta cabeçalhos LUKS desanexados e porque na verdade monta dispositivos, algo que não quero) por usuário e, de fato , pam_systemdé iniciado systemctl --user, então definitivamente deve haver uma maneira de obter privilégios durante a inicialização por usuário para executar a descriptografia do dispositivo.
A propósito, os sintomas de falha de
systemctl --user enable luks@xxx
são ainda piores do que aqueles de testá-lo com
systemctl --user start luks@xxx
(que retorna apenas exit code 1). Ou seja, não consigo nem fazer login com o usuário fornecido, pois ele reclama
Failed to create bus connection: No such file or directory
porque XDG_RUNTIME_DIRe DBUS_SESSION_BUS_ADDRESSnão estão mais configurados, enquanto deveriam estar pelo systemd-logind.serviceserviço. Claramente, luks@xxxde alguma forma interrompe todo o processo de inicialização, mas devido à informação insuficiente no diário, não consigo identificar exatamente o porquê. Assim, minha suspeita atual sobre a falta de permissões ainda permanece.
Aguardo propostas educadas. Obrigado.
Responder1
Uma solução alternativa seria editar o sudoersarquivo para adicionar permissões para o usuário em questão executar /usr/lib/systemd/systemd-cryptsetupcom permissões de root com a opção NOPASSWD habilitada.
Você então editaria seu arquivo de serviço (específico do usuário) acima para ler:
ExecStart=/usr/bin/sudo /usr/lib/systemd/systemd-cryptsetup attach '%I.luks' '/dev/mapper/%I' '%h/%I/secret.key' 'luks,header=%h/%I/header'
ExecStop=/usr/bin/sudo /usr/lib/systemd/systemd-cryptsetup detach '%I.luks'
Não tenho certeza se você também teria que ativar!requeridopara que isso funcione
Atualizar:
Para aumentar a segurança em torno disso, especialmente para um sistema com múltiplos usuários, eu recomendo fortemente a criação de alguns scripts para executar as etapas de 'anexar' e 'desanexar' em nome do usuário, em vez de dar acesso ao sudo /usr/lib/systemd/systemd-cryptsetupdiretamente, caso contrário qualquer usuário que tenha acesso para executar esse comando pode interferir potencialmente em outros volumes criptografados.
Responder2
Eu sugeriria criar e ativar um Type=oneshot RemainAfterExit=yesserviço para o usuário que cria um arquivo com sua ExecStartdiretiva e o remove com sua ExecStopdiretiva, por exemplo
ExecStart="/usr/bin/touch %h/.decrypt"
ExecStop="/usr/bin/rm %h/.decrypt"
Você pode então criar e ativar um [email protected]arquivo de unidade para o usuário do sistema com um caminho absoluto:
PathExists="/home/user/.decrypt"
Isso verificaria o caminho criado pelo serviço do usuário acima, ativando a [email protected]unidade quando ela for criada e desativando-a quando for removida, estabelecendo assim uma dependência indireta do serviço do sistema no serviço do usuário.
Observe que para que isso funcione com segurança, o diretório no qual o arquivo é criado deve poder ser gravado apenas pelo usuário, é claro.