Por volta de agosto de 1991, um aluno da Finlândia começou a divulgar no newsgroups comp os minix a seguinte mensagem
Localização dos Arquivos Especiais do CL
Yüklə 1,8 Mb.
|
- Bu səhifədəki naviqasiya:
- Usuários, Grupos e Grupos Privados
- Usuário UID GID Diretório Pessoal
- Grupo GID Membros
- Grupo de Usuário Privativo
- Utilização de Grupos Privados
- Autenticação de Usuário com PAM
- Módulos Há quatro tipos de módulos definidos pelo PAM: módulos de autenticação
- Arquivos de Configuração
- Utilitários de Senhas Sombra
- Construindo um kernel Customizado
- Construindo um kernel Modularizado
Localização dos Arquivos Especiais do CL Além dos arquivos do RPM que estão localizados no /var/lib/rpm (conforme Capítulo 15), há duas áreas de localizações especiais que são reservadas à operação e configuração do Conectiva Linux. O painel de controle e as ferramentas reservadas armazenam uma série de arquivos em /usr/lib/rhs. Provavelmente não há nenhum arquivo aqui a ser editado, sendo constituído basicamente por pequenos programas, imagens e arquivos texto. A outras localização, /etc/sysconfig, armazena informações de configuração. Os maiores usuários deste diretório são os programas que são executados em tempo de inicialização. É possível editar estes arquivos manualmente, mas é mais indicado utilizar a ferramenta adequada na ferramenta de painel de controle. Usuários, Grupos e Grupos Privados O Conectiva Linux tem algumas ferramentas e regras que facilitam o gerenciamento de usuários e grupos. A forma mais simples de gerenciar usuários e grupos é através do Linuxconf (veja o Capítulo 10). De qualquer forma podem ser usadas ainda o Painel de Controle ou o comando de linha adduser .
A tabela a seguir apresenta os padrões no processo de instalação (basicamente o conteúdo do arquivo /etc/passwd). O grupo (GID) na tabela é o grupo primário do usuário. Veja na seção 17.3.2 como grupos são utilizados. Tabela: Usuários Padrão
Grupos Padrão A tabela 17.10.3 apresenta uma lista dos grupos padrão que são criados durante o processo de instalação (basicamente o conteúdo do arquivo /etc/group). Tabela: Grupos Padrão
Grupos Privados O Conectiva Linux utiliza um sistema de grupo privado de usuários (UPG), tornando a administração muito mais simples. O sistema UPG não altera nada do padrão UNIX. Simplesmente oferece uma nova convenção no gerenciamento de grupos. Toda vez que um novo usuário for criado, automaticamente é criado um novo grupo. O sistema funciona da seguinte forma: Grupo de Usuário Privativo: Cada usuário tem o seu próprio grupo, do qual ele é o único membro. umask = 002: A máscara tradicional de usuário do Unix é 022, o que evita que outros usuários e outros membros do grupo modifiquem os arquivos do usuário . Como cada usuário tem o seu próprio grupo, uma umask igual a 002 evita que os usuários modifiquem os arquivos privativos do usuário. A umask reside em /etc/profile. Bit SGID em Diretórios: caso o bit SGID esteja ativo em um diretório (com o comando chmod g+s diretório), os arquivos criados no diretório terão o grupo do dono igual ao do diretório. Muitos administradores preferem criar um grupo para cada projeto e atribuem o GID a cada usuário integrado ao projeto. Gerenciar arquivos da maneira tradicional pode ser bastante cansativo, pois os arquivos quando criados pelos usuários pertencem ao grupo primário do usuário. Quando a mesma pessoa está alocada em diversos projetos cria-se uma dificuldade para o compartilhamento e administração dos arquivos. Com o sistema UPG esta tarefa torna-se mais simples. Digamos que um projeto chamado CL tem várias pessoas trabalhando nele e os arquivos criados são colocados no diretório /desenvolvimento. Pode-se criar um grupo chamado desenv, alterar o grupo do diretório para desenv (chgrp) e adicionar todos os usuários ao grupo desenv. Agora todos os membros do grupo desenv poderão criar arquivos no diretório /desenvolvimento que poderão ser editados pelos demais. Caso haja usuários que participem de vários projetos, basta criar um diretório para o projeto, alterar seu sgid e incluir o usuário no grupo, sem necessidade de alterar o umask de cada usuário. É aconselhável alterar o sgid do diretório pessoal do usuário para a identificação de seu grupo.
Uma vez que trata-se de uma nova sistemática, muitas pessoas têm dúvidas sobre esta sistemática, e porque ela deve ser utilizada. Apresentamos a seguir um roteiro de utilização do esquema UPG:
chown -R root.emacs /usr/lib/emacs/site-lisp
chmod 775 /usr/lib/emacs/site-lisp
chmod 2775 /usr/lib/emacs/site-lisp
Ao chegar neste ponto, tornando a umask padrão como 002 e fornecendo um grupo padrão privativo a cada usuário, pode-se facilmente criar grupos de usuários que compartilhem dados entre si, sem que terceiros não autorizados acessem aquelas informações ou os dados nos diretórios pessoais dos integrantes dos grupos sejam acessíveis a outros que não o dono. Para tanto, basta criar um grupo, adicionar os usuários e executar os comandos chown e chmod nos diretórios dos grupos (veja a página de manual on-line em português dos comandos: man chown e man chmod , em português). Autenticação de Usuário com PAM Programas que dão algum tipo de acesso aos usuários devem primeiramente autenticá-los. Ao acessar o sistema um usuário deve fornecer a identificação e a senha, porém existem outras formas de validação de usuários. PAM, que significa Módulos Anexáveis de Autenticação footnode.html - 7262footnode.html - 7262, é uma forma de permitir que o administrador do sistema defina uma política de autenticação sem ter que recompilar programas. Para tanto basta editar alguns arquivos de configuração. Muitos usuários do Conectiva Linux provavelmente nunca tocarão nestes arquivos de configuração. Ao usar o RPM para instalar programas que necessitem de autenticação, ele automaticamente realiza as mudanças necessárias ao processo de autenticação de senhas. De qualquer forma, caso seja necessário customizar a sua configuração, é importante conhecer o seu conteúdo. Módulos Há quatro tipos de módulos definidos pelo PAM: módulos de autenticação que validam os usuários, provavelmente solicitando e verificando senhas e configurando credenciais como liberando acessos a grupos ou criando tíquetes como no software de segurança Kerberos; módulos de controle que garantem a autenticação (verificam se a conta não expirou, se o usuário pode acessar o sistema em determinados horários, etc...); módulos de senhas, utilizados para a criação e configuração de senhas e módulos de sessão que são utilizados para liberar os recursos necessários para o usuário válido, como a montagem do diretório pessoal, disponibilidade de correio, etc... Estes módulos podem estar separados, podendo ser utilizados de várias maneiras. Como por exemplo o rlogin que normalmente utiliza no mínimo dois métodos de autenticação: caso o rhosts autorize o acesso, a conexão é estabelecida, caso contrário o módulo de autenticação de senhas é utilizado. Novos módulos podem ser adicionados a qualquer tempo e novas aplicações podem utilizar o PAM. Por exemplo, caso se tenha um sistema que calcule uma senha para uso uma única vez, pode-se escrever o módulo para suportar esta funcionalidade (documentação sobre o desenvolvimento de módulos pode ser encontrada com o sistema). Programas que interajam com PAM podem usar o novo módulo sem a necessidade de recompilar ou alterar o novo módulo.
Cada programa que utiliza o PAM define o seu próprio nome de serviço. O programa de login define um serviço chamado login, ftpd possui o serviço ftp, etc... Em geral os nomes dos tipos de serviços levam o nome do programa usado para acessar o serviço e não o programa usado para prover o serviço. Arquivos de Configuração O diretório /etc/pam.d é utilizado para configurar as aplicações que utilizem PAM (em versões anteriores era utilizado o arquivo /etc/pam.conf. Apesar de ainda ser lido caso não esteja presente em /ect/pam.d, seu uso não é recomendado). Cada aplicação (na verdade, cada serviço) tem o seu próprio arquivo. Um arquivo tem um conteúdo similar a: A primeira linha é um comentário (começando por #). As próximas três linhas definem os três módulos que serão usados na autenticação de usuários. A segunda linha garante que o acesso ao sistema como superusuário somente poderá ser realizado através de terminais que estejam listados no arquivo /etc/securetty, caso ele exista. A terceira linha cria a exigência de informação de senha e sua validação para a liberação de acesso ao sistema. A quarta verifica se o arquivo /etc/nologin existe, e caso isso ocorra, mostra o conteúdo do arquivo e permite acesso ao sistema somente para o superusuário (útil para intervalos de manutenção de sistema). Todos os três módulos serão executados, mesmo que o módulo anterior negue o acesso ao sistema. Por questões de segurança, o sistema não avisa ao usuário porque seu acesso foi negado, dificultando um eventual acesso indevido. A quinta linha define os módulos de controle que serão ativados. Por exemplo caso o sistema de senhas sombra esteja ativado, o módulo pam_pwdb.so verificará se a conta ou a senha não estão expiradas, ou se o período entre de troca obrigatória de senhas não foi atingido. A sexta linha submete uma nova senha a uma série de testes para garantir que ela não seja facilmente descoberta, por exemplo, por um programa de quebra de senhas baseado em dicionários. A sétima linha especifica que o programa a ser utilizado na troca de senhas, quando necessário, será o pam_pwdb.so (ele somente será acionado se o módulo auth determinar que a senha deva ser trocada). A última linha especifica que o módulo pam_pwdb.so deve ser usado para gerenciar a sessão. Atualmente este módulo não tem uma função específica, e pode ser substituído por qualquer outro módulo necessário. Note que a ordem das linhas em cada arquivo é importante, ainda que não necessariamente em que ordem os arquivos required sejam chamados, há outros indicadores de controle disponíveis. Já que um módulo optional é raramente usado pelo padrão do Conectiva Linux, sufficient e requisite tornam a ordem das linhas importante. Por exemplo, o arquivo de configuração do comando rlogin tem o seguinte conteúdo: É muito similar ao arquivo de login, porém há uma linha adicional que especifica um módulo extra e a ordem dos módulos é diferente. Inicialmente pam_securetty mantém a proibição de login do superusuário a partir de terminais sem segurança, o que inibe o rlogin para o superusuário footnode.html - 7301footnode.html - 7301. Caso isso seja necessário (apesar de não recomendado) basta remover esta linha. Após, o módulo pam_nologin checa a existência do arquivo /etc/nologin conforme descrito acima. Na terceira linha temos o módulo pam_rhosts_auth.so que autentica o usuário e imediatamente apresenta um retorno positivo ao rlogin sem que a senha seja fornecida. Caso este módulo não autorize o usuário a próxima linha será executada. Finalmente o módulo pam.pwdb.so executará uma autenticação normal, desde que o módulo anterior já não tenha autorizado o usuário. É possível não solicitar uma senha, caso a checagem do módulo pam_securetty.so não autorize o acesso. Para tanto basta alterar o parâmetro required para requisite. Senhas "Sombra" O módulo padrão pam_pwdb.so pode suportar o sistema de senhas sombrafootnode.html - 7312footnode.html - 7312. O módulo automaticamente detectará que o sistema está sendo utilizado e fará os ajustes necessários. Veja a seção 17.4.4 para maiores informações sobre os utilitários que suportam o sistema de "senhas sombra". Mais Informações Esta é apenas uma introdução ao PAM. Maiores informações podem ser encontradas no diretório /usr/doc/pam*, no Guia do Administrador de Sistemas em português, traduzido pela Conectiva Informática, ou no Manual de Desenvolvimento e de Padrões para o PAM, em inglês. Utilitários de Senhas Sombra footnode.html - 7320footnode.html - 7320 Senhas sombra são um método de incrementar a segurança do sistema movendo as senhas encriptadas (normalmente encontradas em /etc/passwd) para outro arquivo mais restritivo nas suas permissões de acesso. O suporte a senhas sombras foi melhorado significativamente no Conectiva Linux 3.0, sendo que o pacote shadow-utils contém diversos utilitários de suporte:
Saliente-se que:
Construindo um kernel Customizado Com a introdução do kernel modularizado no Linux 2.0.x surgiram importantes mudanças na construção de kernels customizados. Antes era necessário compilar o kernel toda vez que se desejasse acessar um hardware ou sistema de arquivos em particular. Para alguns hardwares o tamanho do kernel poderia atingir um certo nível de criticidade. O suporte já embutido no kernel poderia ser uma solução ineficiente sob o ponto de vista de utilização de recursos do sistema. Com as facilidades disponibilizadas no kernel 2.0.x, caso haja algum componente de hardware ou do sistema de arquivos pouco usado, os drivers e módulos são carregados somente quando necessários, melhorando a performance e otimizando a utilização de recursos do sistema. Para informações adicionais sobre módulos do kernel vide a seção 17.4.1. Muitos usuários iniciantes em Linux perguntam por que um kernel customizado deve ser construído. A menos que se tenha uma razão clara e específica para construir um ou você queira obter maiores informações sobre o Linux, pode ir diretamente para a seção 17.6.
Caso não se tenha interesse em utilizar a modularização de kernel, por favor veja a seção 17.5.3 para uma explicação detalhada sobre os aspectos de construção e instalação de um kernel monolítico. Este roteiro assume que todos os headers do kernel e pacotes com os fontes estão localizados no diretório /usr/src/linux. É importante começar a construção do kernel com a árvore de fontes bem conhecida. Para tanto pode-se utilizar o comando make mrproper , o qual removerá todos os arquivos de configuração de reconstruções anteriores que estejam residentes nas árvores de diretórios. Após é necessário criar o arquivo de configuração que irá determinar quais componentes serão incluídos no kernel. Dependendo do hardware e das preferências pessoais, pode-se optar por um dos três métodos disponíveis:
Yüklə 1,8 Mb. Dostları ilə paylaş:
|