Por que mount exige privilégios de root?


54

Por que o Linux exige que um usuário seja root / usando o sudo / especificamente autorizado por montagem para montar algo? Parece que a decisão de permitir que um usuário monte algo deve basear-se em seus direitos de acesso ao volume de origem / compartilhamento de rede e ao ponto de montagem. Alguns usos para montagem não raiz são montar imagens do sistema de arquivos em uma direção de propriedade do usuário e montar um compartilhamento de rede em um diretório de propriedade do usuário. Parece que se o usuário tiver controle sobre os dois lados da equação de montagem, tudo deve ser legal.

Esclarecimento da restrição de acesso:

Eu acho que devo montar tudo o que o usuário teria acesso a um ponto de montagem do qual o usuário é proprietário.

Por exemplo, no meu computador, o / dev / sda1 pertence ao usuário root e ao disco do grupo com permissões brw-rw----. Portanto, usuários não-root não podem mexer com / dev / sda1 e montar claramente não devem permitir que eles o montem. No entanto, se o usuário possui /home/my_user/my_imagefile.img e ponto de montagem / home / my_user / my_image / por que eles não podem montar esse arquivo de imagem nesse ponto de montagem com:

mount /home/my_user/my_imagefile.img /home/my_user/my_image/ -o loop

Como o kormac apontou, há um grande problema. Portanto, algumas restrições teriam que ser adicionadas para evitar que o suid fosse um problema, bem como potencialmente alguns outros problemas. Talvez uma maneira de fazer isso seja fazer o sistema operacional tratar todos os arquivos como pertencentes ao usuário que fez a montagem. No entanto, para simples leitura / gravação / execução, não vejo por que isso seria um problema.

Caso de uso:

Eu tenho uma conta em um laboratório em que meu espaço doméstico é restrito a 8 GB. Isso é minúsculo e muito, muito chato. Gostaria de montar um volume nfs do meu servidor pessoal para aumentar essencialmente a quantidade de espaço que tenho. No entanto, como o Linux não permite tais coisas, estou preso aos arquivos scp'ing para frente e para trás para ficar abaixo do limite de 8 GB.


4
Parece que o problema não é tanto que "o linux não permite tais coisas", como você não tem permissão para fazer essas coisas em seu laboratório, pois o sistema pode ser configurado para permitir que você faça isso. Você pode discutir esse problema com as pessoas que administram o sistema; se eles não são amigáveis, então é sobre política e não computadores;)
Goldilocks

É possível montar pontos de montagem arbitrários aos quais se tem acesso normal? Parece que o administrador teria que adicionar uma linha explícita ao fstab para o meu nfs mount para permitir isso. Por sua vez, isso provavelmente criaria um precedente no qual eles teriam que fazer isso também para todos os que pediram, o que eu entendo que seria insustentável. Daí a pergunta sobre por que o Linux não permite montar coisas arbitrárias que seriam seguras (de alguma maneira restrita).
27613 CrazyCasta

10
Você já tentou sshfs? Ele montará um diretório remoto, através de ssh, como você, sem a necessidade de acesso root. Ele só precisa da instalação do FUSE (sistema de arquivos no UserSpacE).
Arcege 17/02/2013

11
Você já ouviu falar sobre o problema ruim do disco rígido, etc. Então, eu sei que já disse isso várias vezes, mas a filosofia é que "montar coisas arbitrárias" não pode ser tornado seguro , e é por isso que é definido o caminho é (exceções específicas devem ser organizadas). BTW, se você não tiver o FUSE, sftpé um pouco mais agradável de usar do que scp.
GOLDILOCKS

11
Parece que (uma variação de) isso já foi solicitado aqui antes: Montar um arquivo de loop sem permissão de root?
Daniel Pryden

Respostas:


37

É uma restrição histórica e de segurança.

Historicamente, a maioria das unidades não era removível. Portanto, fazia sentido restringir a montagem a pessoas que tinham acesso físico legítimo, e elas provavelmente teriam acesso à conta raiz. As entradas fstab permitem que os administradores delegem a montagem a outros usuários para unidades removíveis.

Do ponto de vista da segurança, existem três problemas principais ao permitir que usuários arbitrários montem dispositivos de bloco ou imagens de sistema de arquivos arbitrários em locais arbitrários.

  • A montagem em um local não pertencente sombreia os arquivos nesse local. Por exemplo: monte um sistema de arquivos de sua escolha /etc, com uma /etc/shadowsenha raiz que você saiba. Isso é corrigido permitindo que um usuário monte um sistema de arquivos apenas em um diretório que ele possui.
  • Os drivers do sistema de arquivos geralmente não foram testados tão detalhadamente com o sistema de arquivos malformado. Um driver de sistema de arquivos com erros pode permitir que um usuário que fornece um sistema de arquivos mal formado injete código no kernel.
  • A montagem de um sistema de arquivos pode permitir que o montador faça com que alguns arquivos apareçam que ele não teria permissão para criar. Arquivos executáveis ​​e de dispositivos setuid são os exemplos mais óbvios, e são corrigidos pelas opções nosuide nodevque estão implícitas userna entrada /etc/fstab.
    Até agora, impor userquandomountnão é chamado pela raiz é suficiente. Mas, geralmente, a capacidade de criar um arquivo pertencente a outro usuário é problemática: o conteúdo desse arquivo corre o risco de ser atribuído pelo suposto proprietário, em vez do montador. Uma cópia casual de preservação de atributo por raiz para um sistema de arquivos diferente produziria um arquivo pertencente ao proprietário declarado, mas não envolvido. Alguns programas verificam se uma solicitação para usar um arquivo é legítima, verificando se o arquivo pertence a um usuário específico e isso não seria mais seguro (o programa também deve verificar se os diretórios no caminho de acesso pertencem a esse usuário; se a montagem arbitrária fosse permitida, eles também teriam que verificar se nenhum desses diretórios é um ponto de montagem em que a montagem foi criada nem pela raiz nem pelo usuário desejado).

Para fins práticos, atualmente é possível montar um sistema de arquivos sem ser root, através do FUSE . Os drivers do FUSE são executados como o usuário de montagem, portanto não há risco de escalação de privilégios ao explorar um bug no código do kernel. Os sistemas de arquivos do FUSE podem apenas expor arquivos que o usuário tem permissão para criar, o que resolve o último problema acima.


24

Se um usuário tiver acesso direto de gravação a um dispositivo de bloco e puder montá-lo, ele poderá gravar um suid executável no dispositivo de bloco, montá-lo e executar esse arquivo e, assim, obter acesso root ao sistema. É por isso que a montagem é normalmente restrita à raiz.

Agora, o root pode permitir que usuários normais montem com restrições específicas, mas ele precisa garantir que, se o usuário tiver acesso de gravação ao dispositivo de bloco, a montagem desaprove suid e também devnodes, que têm um problema semelhante (o usuário pode criar um devnode que lhes dá acesso de gravação a um dispositivo importante ao qual eles não deveriam ter acesso de gravação).


8

Nem sempre exige super privs. Deman mount

   The non-superuser mounts.
          Normally,  only  the  superuser can mount filesystems.  However,
          when fstab contains the user option on a line, anybody can mount
          the corresponding system.

          Thus, given a line

                 /dev/cdrom  /cd  iso9660  ro,user,noauto,unhide

          any  user  can  mount  the iso9660 filesystem found on his CDROM
          using the command

                 mount /dev/cdrom

          or

                 mount /cd

          For more details, see fstab(5).  Only the user  that  mounted  a
          filesystem  can unmount it again.  If any user should be able to
          unmount, then use users instead of user in the fstab line.   The
          owner option is similar to the user option, with the restriction
          that the user must be the owner of the special file. This may be
          useful e.g. for /dev/fd if a login script makes the console user
          owner of this device.  The group option  is  similar,  with  the
          restriction  that  the  user  must be member of the group of the
          special file.

Sim, você está certo, eu fui um pouco impreciso na minha pergunta. Estou ciente de que um pode ser especificamente autorizado, montagem a montagem. Mas parece que, se o ponto de montagem e o volume pertencerem ao usuário, ele poderá ser montado sem autorização específica.

3
@CrazyCasta: o ponto de montagem pode pertencer ao usuário, mas o nó do dispositivo não. O que as propriedades, etc., estão nos dados da partição é a) incognoscível, b) irrelevante.
GOLDILOCKS

Mas e se o nó do dispositivo pertencer ao usuário.
27630 CrazyCasta

Deve haver uma exceção paralela feita no fstab, pois um nó de dispositivo de propriedade do usuário seria excepcional para começar (tente criar um). Mais uma vez, o princípio é que um sistema seguro é restrito e as pessoas recebem privilégios ... se você não recebeu privilégios, infelizmente está sem sorte. Veja, * nix não vende revistas de alta capacidade no balcão - você precisa de uma permissão.
GOLDILOCKS

Para ser claro, a mount()chamada do sistema sempre requer raiz. Os utilitários suid podem se tornar root e permitir que usuários não root sejam montados, e se o mountcomando estiver instalado suid, ele fará isso com base no sinalizador de usuário no fstab. Outros executáveis ​​suid foram gravados para permitir a montagem dos usuários, como pmount, o que permite que os usuários montem mídia externa e impõe as restrições apropriadas, como nosuid, nodev.
Psusi

5

Kormac e outros indicaram que este não é o dilema que você apresenta como; parece-me que isso se resume à filosofia de conceder explicitamente privilégios aos usuários versus um sistema pelo qual todos os usuários teriam o direito imutável de montar um sistema de arquivos.

Gilles aborda alguns dos problemas de segurança associados à montagem de sistemas de arquivos. Evitarei retroativamente uma discussão pró-ativa e tangencial sobre possíveis problemas técnicos relacionados a isso (ver comentários), mas acho justo que usuários não confiáveis ​​não tenham o direito imutável de montar discos rígidos.

O problema com relação aos sistemas de arquivos virtuais e remotos (ou sistemas de arquivos remotos via sistemas de arquivos virtuais, como o FUSE) é menos significativo, mas isso não resolve a questão de segurança (embora o FUSE possa, e certamente resolveria o seu problema). Também é importante considerar que os dados nesses sistemas de arquivos quase sempre podem ser acessados ​​sem a necessidade de montar um dispositivo, seja através da transferência de arquivos ou de ferramentas extraídas de imagens sem montagem, para que um sistema que não permita a montagem de algo seja necessário. não representa um problema insuperável no que diz respeito ao acesso a dados que você colocou estranhamente em um arquivo de imagem ou (mais compreensivelmente) deseja obter de um sistema remoto. Se você tiver uma situação em que esse não seja o caso, poderá valer a pena perguntar:

  1. O que é exatamente isso que estou tentando fazer?

  2. Onde estou tentando fazer isso?

Se a administração do sistema for justa, o item 2 explica por que o item 1 é impossível para você. Se a administração do sistema não é justa, isso é política . A solução para o problema "Meu administrador de sistemas não é justo" não é redesenhar o sistema operacional para que os administradores de sistemas em todos os lugares não possam restringir os usuários.

O sistema permite que o superusuário restrinja suas atividades, explicitamente ou por omissão ("Nós não fornecemos FUSE", etc). Privilégios são um mecanismo pelo qual isso é realizado. Pode não ser bom saber: "Você não precisa fazer isso", mas se for verdade ... que sera ... você não precisa fazer isso. Use ftp, etc. Se isso não for verdade, você deve incomodar os responsáveis.


Sua resposta é confusa, não são os próprios volumes (por exemplo, / dev / sda1, / dev / sda2, etc.) protegidos contra usuários que os leem / escrevem? Eu estou querendo saber por que um usuário não pode montar algo ao qual ele teria acesso. Para esclarecer, se eu tiver um arquivo de imagem como ext2, eu poderia escrever um aplicativo que me permita ler / gravar de / para a imagem (não como parte do sistema de arquivos do sistema operacional). O aplicativo não seria capaz de ler / gravar as partições em / dev (a menos que essas partições fossem alteradas para permitir ao usuário acesso a elas, o que geralmente não faz sentido).
27630 CrazyCasta

PS: Eu não concordo que os usuários possam montar um sistema de arquivos ao qual eles não teriam acesso sem autorização específica, pois apenas o ato de montá-lo pode causar algum tipo de ação (como verificação do sistema de arquivos) que o root não deseja.
27630 CrazyCasta

A montagem de uma imagem ainda envolve nós do dispositivo (por exemplo, / dev / loop). Você está certo que isso cria um aborrecimento, mas "fazer arranjos" para isso vai variar de sistema para sistema (há um fornecimento finito de dispositivos de loop, por um lado), então, novamente, é por isso que, por padrão , é tudo restrito. Mas esse padrão ainda pode ser substituído, pelo superusuário, em nome de quem quer que seja.
GOLDILOCKS

Esse é um bom argumento sobre o limite de nós de dispositivos de loopback. Não estou muito claro porque é necessário um dispositivo de loopback, parece um pouco redundante. Eu sei que é porque a montagem requer um arquivo em bloco e não um arquivo normal. Eu não entendo por que isso acontece. Você pode oferecer algum insight, como o kernel trata dispositivos de bloco e arquivos regulares de maneira significativamente diferente?
27630 CrazyCasta

11
@ goldilocks: A razão pela qual esta resposta é besteira é porque sua teoria por trás da restrição é muito convincente, mas é totalmente errada, o problema a que você se refere não existe. Permitir a criação de um sistema de arquivos virtual (como o FUSE) não permite que você faça algo que ainda não é possível de maneira mais indireta usando o IPC. Sua observação sobre interrupções em dispositivos é totalmente irrelevante; a única interrupção significativa que está ocorrendo no sistema de arquivos remoto vem da placa de rede, que é totalmente gerenciada pelo kernel.
Lie Ryan

5

FYI: Os kernels mais novos têm suporte para "namespace". Usuários comuns podem criar um espaço para nome e, dentro desse espaço para nome, se tornar root e fazer coisas divertidas, como montar sistemas de arquivos.

Porém, ele não fornece permissões "reais" de superusuário - você só pode fazer o que já está autorizado a fazer (ou seja, você pode montar apenas dispositivos que você já pode ler).

http://lwn.net/Articles/531114/ Veja a seção 4.


Os espaços para nome são mais limitados que isso. Você pode aparecer rootdentro de um espaço para nome de usuário, mas não permite montar tipos normais de sistema de arquivos, mesmo que você possa ler e gravar o dispositivo de bloco. Veja o experimento 2 aqui: unix.stackexchange.com/questions/517317/…
sourcejedi

0

Como os dados no sistema de arquivos que eles pretendem montar podem comprometer a segurança do servidor ou até travá-lo (se intencionalmente construído dessa maneira).


Você poderia elaborar? Não tenho certeza de como "os dados no sistema de arquivos que eles pretendem montar" comprometeriam a segurança. Se você puder ler / gravar o arquivo normalmente, poderá montá-lo (é o meu argumento). Se eu puder ler / escrever um ponto de montagem, devo poder montar tudo o que puder, com exceção de realmente montá-lo em um diretório. Se você não pode lê-lo / gravá-lo ou não pode visualizar o diretório em que está, para ver se ele existe, o mount falharia da mesma maneira que um comando ls ou cat.

Seu argumento é válido se 'você' for o único usuário; lembre-se de que o Linux (e Unix) são sistemas multiusuário, nos quais os usuários não são necessariamente confiáveis.
sendmoreinfo

binários suid podem ser adicionados a um dispositivo, montados na sua caixa e usados ​​para criar uma raiz, e é por isso que, por padrão ownere user(s)definido nosuid. Você não iria querer alguém ser capaz de ignorar que facilmente com o que lhes permite remover manualmente asnosuid
RS

@sendmoreinfo Estou bem ciente de que o Linux é um sistema multiusuário, não há necessidade de ser condescendente. Pergunto-me por que estou impedido de montar compartilhamentos de rede e arquivos de imagem que, de outra forma, tenho acesso suficiente. A resposta do kormoc é esclarecedora, embora eu esteja curioso para saber por que certas bandeiras não puderam ser forçadas a usuários não-root (como nosuid) para corrigir isso. Parece que eu deveria poder montar com o objetivo de ler / gravar simples um arquivo de imagem / compartilhamento de rede ao qual tenho acesso em um ponto de montagem que possuo.
27613 CrazyCasta

11
@CrazyCasta WRT "travando o sistema", certamente é possível montar um hardware defeituoso que explora vulnerabilidades na interface do hardware. Qualquer pessoa que tenha um disco rígido com blocos ruins suficientes pode dizer como isso pode afetar o kernel (e, portanto, todo o sistema) - ele entra em um ciclo intenso e paralisa efetivamente todo o kit e o kaboodle. Presumivelmente, existe uma lógica na raiz daquilo que torna impossível resolver, uma vez que é um problema bem conhecido que existe há muito tempo sem solução.
GOLDILOCKS

0

No GNOME, o gvfs não requer root para montar o sistema de arquivos remoto (ftp ou ssh) e o gnome-mount também não precisa do root para montar o armazenamento externo (unidade USB, CD / DVD, etc.).

A maioria dos sistemas provavelmente não gostaria de ter o GNOME inteiro apenas para montagem remota; então, você pode usar lufs , sshfs ou ftpfs .

gvfs, lufs, sshfs e ftpfs usam o FUSE para permitir que usuários não root montem um sistema de arquivos virtual; e, diferentemente das montagens -o user, o FUSE não exige que o sysadmin organize montagens específicas. Contanto que você tenha o privilégio do diretório de montagem e de quaisquer recursos necessários para construir o sistema de arquivos, é possível criar a montagem do FUSE.

Por que mount exige privilégios de root?

Porque mounté principalmente / originalmente destinado ao sistema de arquivos local, que quase sempre envolve um hardware.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.