Como permitir que não-superusuários montem qualquer sistema de arquivos?

41

É possível permitir que alguns usuários (por exemplo, membros de um grupo) montem qualquer sistema de arquivos sem privilégios de superusuário no Linux?

Outra pergunta poderia ter sido "de que maneira um usuário pode prejudicar um sistema montando sistemas de arquivos?"

    

7 respostas

38

Existem algumas abordagens, algumas delas mais seguras, outras não.

O caminho inseguro

Deixe qualquer uso executar mount , por exemplo, através do sudo. Você também pode dar-lhes raiz; é a mesma coisa. O usuário poderia montar um sistema de arquivos com uma cópia raiz suid de bash —running que dá instantaneamente root (provavelmente sem qualquer registro, além do fato de que mount foi executado).

Como alternativa, um usuário pode montar seu próprio sistema de arquivos em cima de /etc , contendo sua própria cópia de /etc/shadow ou /etc/sudoers , depois obter raiz com su ou sudo . Ou possivelmente bind-mount ( mount --bind ) sobre um desses dois arquivos. Ou um novo arquivo em /etc/sudoers.d .

Ataques semelhantes podem ser obtidos em /etc/pam.d e muitos outros lugares.

Lembre-se de que sistemas de arquivos nem precisam estar em um dispositivo, -o loop montará um arquivo que é de propriedade (e portanto modificável) pelo usuário.

A maneira mais segura: udisk ou similar

Os vários ambientes de desktop já criaram soluções para isso, para permitir que os usuários montem mídia removível. Eles trabalham montando em um subdiretório de /media e desativando o suporte set-user / group-id via opções do kernel. As opções aqui incluem udisks , udisks2 , pmount , usbmount ,

Se precisar, você pode escrever seu próprio script para fazer algo semelhante e invocá-lo através do sudo - mas você precisa ter muito cuidado ao escrever este script para não deixar explorações de root. Se você não quer que seus usuários tenham que se lembrar do sudo, você pode fazer algo assim em um script:

#!/bin/bash
if [ $UID -ne 0 ]; then       # or 'id -u'
    exec sudo -- "$0" "$@"
fi

# rest of script goes here 

O caminho será um dia seguro: namespaces de usuário

A partir do Linux 3.10, o suporte a namespaces é basicamente completo, aparentemente faltando a maior parte do suporte no XFS (um sistema de arquivos). Namespaces são uma forma muito leve de virtualização (containers, para ser mais específico). Em particular, com namespaces de usuário, qualquer usuário do sistema pode criar seu próprio ambiente no qual ele é root e, portanto, pode montar sistemas de arquivos.

Muitos kernels de distribuição, no entanto, desativaram o recurso (ex: Debian ) devido ao conflito XFS e preocupações com segurança; na verdade, houve uma exploração de raiz descoberta no início deste ano ( CVE-2013-1858 ). Você pode precisar recompilar o kernel com CONFIG_USER_NS=y .

A melhor documentação que eu sei sobre namespaces de usuário é um artigo do LWN Namespaces em operação, parte 5: Espaços de nomes do usuário .

    
por 18.10.2013 / 18:01
11

Você pode fazer isso, mas precisa modificar a entrada em /etc/fstab correspondente ao sistema de arquivos que deseja montar, adicionando o sinalizador user a essa entrada. Os usuários sem privilégios poderiam então montá-lo.

Veja man mount para mais detalhes.

    
por 18.10.2013 / 16:30
6

Aqui é o wiki para configurar as regras do polkit para udisks / udisks2 para montar partições por grupos não-root (por exemplo, usuários).

Salve o código abaixo para /etc/polkit-1/rules.d/50-udisks.rules

polkit.addRule(function(action, subject) {
  var YES = polkit.Result.YES;
  var permission = {
    // only required for udisks1:
    "org.freedesktop.udisks.filesystem-mount": YES,
    "org.freedesktop.udisks.filesystem-mount-system-internal": YES,
    "org.freedesktop.udisks.luks-unlock": YES,
    "org.freedesktop.udisks.drive-eject": YES,
    "org.freedesktop.udisks.drive-detach": YES,
    // only required for udisks2:
    "org.freedesktop.udisks2.filesystem-mount": YES,
    "org.freedesktop.udisks2.filesystem-mount-system": YES,
    "org.freedesktop.udisks2.encrypted-unlock": YES,
    "org.freedesktop.udisks2.eject-media": YES,
    "org.freedesktop.udisks2.power-off-drive": YES,
    // required for udisks2 if using udiskie from another seat (e.g. systemd):
    "org.freedesktop.udisks2.filesystem-mount-other-seat": YES,
    "org.freedesktop.udisks2.encrypted-unlock-other-seat": YES,
    "org.freedesktop.udisks2.eject-media-other-seat": YES,
    "org.freedesktop.udisks2.power-off-drive-other-seat": YES
  };
  if (subject.isInGroup("users")) {
    return permission[action.id];
  }
});

Suponha que você esteja no grupo "users", usando o seguinte comando para montar uma partição (não é necessário sudo).

# udisks2
udisksctl mount --block-device /dev/sda1

# udisks
udisks --mount /dev/sda1
    
por 05.06.2015 / 03:26
3

Você pode configurar sudo para permitir que um conjunto de usuários execute o comando mount .

Atualização : como você pode danificar um sistema por montagem? Por exemplo, você pode criar um shell de raiz setuid em um sistema de arquivos que você pode montar e executar para obter privilégios de root.

    
por 18.10.2013 / 16:28
3

1 Veja onde funciona

No Xubuntu funciona imediatamente para montar e ejetar armazenamento em massa USB, partições de disco rígido, CD / DVDs e provavelmente mais.

Vamos supor que a solução que o Ubuntu escolheu, usando o policyKit, seja segura o suficiente.

2 Escolha a parte relevante

No XFCE no Debian 8.3 eu precisava permitir que o usuário montasse e ejetasse sistemas de arquivos do Thunar sem senha. O que funcionou para mim é escolher um arquivo de permissão do Ubuntu.

Adicionar as linhas abaixo como raiz a um arquivo chamado /var/lib/polkit-1/localauthority/10-vendor.d/com.ubuntu.desktop.pkla deve funcionar:

[Mounting, checking, etc. of internal drives]
Identity=unix-group:admin;unix-group:sudo
Action=org.freedesktop.udisks.filesystem-*;org.freedesktop.udisks.drive-ata-smart*;org.freedesktop.udisks2.filesystem-mount-system;org.freedesktop.udisks2.encrypted-unlock-system;org.freedesktop.udisks2.filesystem-fstab;
ResultActive=yes

3 Lucro!

(O que eu fiz na verdade foi pegar um pouco mais do arquivo com o mesmo nome no Ubuntu 16.04 e funcionou para mim. Se você precisar, parece que o conteúdo de link )

    
por 18.03.2016 / 18:23
0

Para responder à sua pergunta entre parênteses, uma vez que um sistema de arquivos é um espaço reservado para arquivos, então um usuário pode potencialmente realizar operações prejudiciais nesse sistema de arquivos, como excluir arquivos.

Resumindo as outras duas perguntas, direi isso:

  • fstab é ótimo para montagem em armazenamento de inicialização tempo permanente . Não é tão bom quando você deseja conectar unidades USB ou montar ocasionalmente alguns compartilhamentos de rede.

  • sudo mount também é bom se você estiver em sistemas ubuntu *. Você ainda precisará digitar uma senha.

  • O udev cuidará da montagem de coisas como pen drives, câmeras e cartões flash em sistemas Ubuntu * (mas não em menos distros amigáveis, como debian, slackware, etc)

Acrescentarei que, historicamente, a maneira unix de dar autoridade a alguns usuários (ou grupos) para fazer coisas é através do arquivo sudoers .

Existem MUITOS guias para usá-lo lá fora, por isso não vou sugerir nenhum em particular. Eu vou dizer que usei o site do projeto de documentação do Linux para aprender sobre isso.

O que é mais com sudoers é que você pode montar dispositivos e compartilhamentos de forma transparente - mesmo sem fornecer uma senha, se você optar por fazê-lo (tenha muito cuidado com isso).

O que geralmente faço em um ambiente de controle é usar sudoers file para permitir que usuários de determinado grupo montem compartilhamentos de rede de forma transparente. Então, adiciono os comandos mount.nfs e mount.cifs no arquivo sudoers que permitem operações como "montar a pasta base do usuário a partir de um servidor de arquivos de rede, quando o usuário faz logon em um terminal de cliente" e aprender assim. / p>     

por 18.10.2013 / 18:09
0

guestmount libguestfs truques

sudo apt-get install libguestfs-tools

# Workarounds for Ubuntu 18.04 bugs.
# https://serverfault.com/questions/246835/convert-directory-to-qemu-kvm-virtual-disk-image/916697#916697
sudo rm -rf /var/cache/.guestfs-*
echo dash | sudo tee /usr/lib/x86_64-linux-gnu/guestfs/supermin.d/zz-dash-packages
sudo chmod +r /boot/vmlinuz-*

# Create a test image.
mkdir sysroot
dd if=/dev/urandom of=sysroot/myfile bs=1024 count=1024
virt-make-fs --format=raw --type=ext2 sysroot sysroot.ext2

# Mount it, have fun, unmount!
mkdir -p mnt
# /dev/sda becuase we have a raw filesystem.
guestmount -a sysroot.ext2.qcow2 -m /dev/sda mnt
cmp sysroot/myfile mnt/myfile
guestunmount mnt

Depende de:

  • implementação userland dos sistemas de arquivos
  • FUSE

Documentos: link

Testado no Ubuntu 18.04, libguestfs-tools 1: 1.36.13-1ubuntu3.

    
por 17.06.2018 / 15:33