10.1. | Onde estão os arquivos que configuram a
inicialização do sistema ? |
| Do FreeBSD 2.0.5R até o 2.2.1R, o arquivo de
configurações primário é o
/etc/sysconfig . Todas as
opções devem ser definidas nesse arquivo ou
então em outros, como o
/etc/rc (veja o manual para o
rc(8)) e o /etc/netstart Dê uma olhada no
/etc/sysconfig e altere as
variáveis de acordo com o que você quer
configurar no seu sistema. O arquivo é repleto de
comentários que auxiliam a correta
definição dos valores a serem
definidos. A partir do 2.2.1 até o 3.0, o
/etc/sysconfig foi renomeado para
rc.conf(5), que é auto-descritivo, e cuja
sintaxe foi melhorada no processo de
substituição. O
/etc/netstart agora se chama
/etc/rc.network , de forma que todos
os arquivos possam ser copiados com um simples comando
como um cp /usr/src/etc/rc* /etc E depois, a partir do FreeBSD 3.1, o
/etc/rc.conf foi alterado para o
/etc/defaults/rc.conf .
Não edite esse arquivo! Ao
invés disso, para todas as entradas que você
queira alterar no
/etc/defaults/rc.conf , basta apenas
copiar a linha relativa à essa entrada para o
/etc/rc.conf e depois modificar seu
valor. Por exemplo, caso deseje iniciar o named, o servidor
DNS disponível no FreeBSD, a partir do FreeBSD 3.1
basta fazer isso: # echo named_enable="YES" >> /etc/rc.conf
Para iniciar serviços locais no FreeBSD 3.1 e
posteriores, basta colocar os scripts shell de
inicialização desses serviços no
diretório /usr/local/etc/rc.d .
Tais shell scripts devem ser executáveis e
terminarem com a extensão .sh. No FreeBSD 3.0 ou
anteriores, o arquivo /etc/rc.local
era a única opção para iniciar
serviços/processos locais automaticamente. O arquivo /etc/rc.serial é
usado para a inicialização de portas seriais
(por exemplo, para definir as características das
portas, e assim por diante). O arquivo /etc/rc.i386 é
usado para configurações específicas
de sistemas Intel e compatíveis, como por exemplo,
emulação iBCS2 ou definições
do sistema de console dos PC. |
10.2. | Como posso adicionar um usuário de forma
simples? |
| Use o comando adduser(8). Caso prefira uma forma
mais complexa (e mais completa), use o comando
pw(8). Para remover o usuário do sistema, use o
comando rmuser(8). Mais uma vez, o pw(8)
também funciona muito bem nesse caso. |
10.3. | Depois de editar o crontab, mensagens como
root: not found ficam aparecendo
sempre. Por que? |
| Normalmente esse é um problema causado ao se
editar o crontab do sistema
(/etc/crontab ) e depois usar o
crontab(1) para instala-lo: # crontab /etc/crontab
Essa não é a forma correta de fazer as
coisas. O crontab do sistema tem um formato distinto do
crontab dos usuários, o qual o crontab(1)
atualiza (o manual do crontab(5) explica tais
diferenças de forma mais detalhada). Caso você tenha cometido esse engano, o novo
crontab é uma simples cópia do
/etc/crontab , ou seja, com um formato
errado. Apague-o com o comando: # crontab -r
Da próxima vez que editar o
/etc/crontab , nenhuma
ação precisa ser tomada para avisar o
cron(8) das alterações. Ele vai
perceber as mudanças automaticamente. Caso queira executar alguma tarefa diária,
semanal ou mensal, é mais indicado adicionar alguns
scripts de shell sob o
/usr/local/etc/periodic e deixar o
programa periodic(8), chamado a partir da tabela cron
do sistema, cuidar das suas tarefas assim como ele faz com
as outras tarefas pertinentes ao sistema. A única razão para esse erro é
que a tabela de cron do sistema tem um campo a mais, que
especifica o usuário que deve executar o comando.
No crontab do sistema padrão do FreeBSD, esse
usuário é o root , em
todas as entradas. Quando essa crontab é usada
como a tabela de cron do root (que
é diferente da tabela de cron do sistema), o
cron(8) assume que a string root
fosse um primeiro comando, mas esse comando não
existe, por isso ocorre o erro. |
10.4. | Porque o erro you are not in the correct
group to su root ocorre, quando eu tento
virar root com o su ? |
| Essa é uma característica de
segurança do FreeBSD. Para se tornar
root com o su (ou qualquer outro
usuário com privilégios de super
usuário), é preciso fazer parte do grupo
wheel . Sem essa
característica, qualquer usuário com uma
conta válida no sistema que soubesse a senha de
root poderia obter privilégios
de super usuário. Por causa do comportamento
atual, essa afirmação não é
verdadeira, uma vez que o su não vai nem permitir
que o usuário dê a senha de
root , caso ele não esteja no
grupo wheel . Para permitir que algum usuário se torne
root , basta que ele faça parte
do grupo wheel . |
10.5. | Cometi um erro no rc.conf , ou em
algum outro arquivo de inicialização, e
agora não posso corrigir essa
alteração porque o sistema de arquivos
é apenas-leitura. O que devo fazer? |
| Nessa situação, o comportamento esperado
é que o sistema entre em modo monousuário e
peça o caminho completo para o seu interpretador de
comandos (sua shell). Basta confirmar a shell
padrão, que ele oferece, com um simples
ENTER , e depois executar um
mount / para remontar o sistema de
arquivos raiz ( / ) em modo leitura/escrita (rw).
Também pode ser necessário executar um
mount -a -t ufs para montar o sistema
de arquivos onde o seu editor de texto preferido vai estar
disponível. Caso seu editor esteja em um sistema
de arquivos da rede, será necessário
configurar a rede manualmente, ou usar um editor
disponível localmente, como o ed(1). Caso queira usar um editor de tela inteira como o
vi(1) ou emacs(1), será necessário
definir a variável de ambiente TERM como do tipo
cons25, bastando um simples export TERM=cons25, de forma
que tais editores possam carregar as
informações corretas da base de dados do
termcap(5). Depois disso, o /etc/rc.conf pode
ser editado normalmente, e a sintaxe problemática,
corrigida. A mensagem de erro apresentada imediatamente
após o carregamento do
kernel indica o
número da linha e o arquivo onde o erro
aconteceu. |
10.6. | Porque estou tendo problemas ao configurar minha
impressora? |
| Por gentileza, dê uma olhada nas páginas
sobre impressão do Manual do FreeBSD. O
documento deve responder a maioria de suas dúvidas.
Veja a entrada sobre Impressão no
Manual do FreeBSD. Algumas impressoras precisam de um driver local,
baseado em estações, para prover qualquer
tipo de impressão. Essas impressoras são
chamadas de “WinPrinters” e não
são suportadas nativamente pelo FreeBSD. Se sua
impressora não funciona sob DOS ou com Windows NT
4.0, provavelmente ela é uma WinPrinter. A
única esperança de se obter uma impressora
desse tipo funcionando, é verificar se o
port print/pnm2ppa tem suporte para
ela. |
10.7. | Como posso corrigir o mapeamento de teclados do meu
sistema? |
| Por gentileza, refira-se à seção
usando localização
do Manual do FreeBSD, mais precisamente na
parte sobre a configuração
do console. |
10.8. | O que causa mensagens como: unknown:
<PNP0303> can't assign resources na
inicialização do sistema? |
| O trecho a seguir é citação de
uma mensagem enviada na lista freebsd-current. | A mensagem “can't assign resources”
indica que os equipamentos em questão são
do tipo ISA, e que não existem entradas indicando
drivers não-PnP compiladas no
kernel. Esses
equipamentos podem ser controladoras de teclados,
controladora de interrupção
programável e várias outras peças
da infra-estrutura padrão do sistema. Os
recursos não podem ser atribuídos por
já existirem drivers usando tais
endereços. | | | --Garrett Wollman, 24 Abril 2001 |
|
10.9. | Porque eu não consigo fazer as quotas de
usuários funcionarem de forma correta? |
| Não habilite quotas na
/ , Coloque o arquivo de quotas indicando o sistema de
arquivos onde se deseja estabelecer as quotas, por
exemplo:
|
10.10. | O FreeBSD suporta as primitivas de IPC do System
V? |
| Sim, o FreeBSD suporta IPC ao estilo do System V.
Esse suporte inclui compartilhamento de memória,
mensagens e semáforos. É necessário
adicionar as seguintes linhas no arquivo de
configurações do seu
kernel, para ativar o
suporte: options SYSVSHM # habilita memória compartilhada
options SYSVSEM # habilita semáforos
options SYSVMSG # habilita mensagens Nota: No FreeBSD 3.2 e posteriores, tais
opções já fazem parte do
kernel
GENERIC, o que significa que tal
suporte já deve estar compilado no seu
sistema. Recompile e instale o novo
kernel. |
10.11. | Como posso usar o sendmail para entregar mensagens com
UUCP? |
| A configuração do sendmail
disponível por padrão no FreeBSD é
direcionada para sites que estejam conectados à
Internet. Servidores que pretendem entregar suas
mensagens via UUCP devem instalar um novo arquivo de
configurações do sendmail. Alterar o /etc/mail/sendmail.cf
manualmente é considerado tarefa para os mais
puristas. A versão 8 do sendmail tem uma nova
abordagem de arquivos de configuração por
meio de pré processamento com o m4(1), onde os
modelos de configuração são
manipulados em um nível mais alto de
abstração. Use os arquivos de
configuração disponíveis sob
/usr/src/usr.sbin/sendmail/cf. Caso seu sistema não tenha sido instalado com
os fontes, os arquivos de configuração do
sendmail foram divididos em pacotes separados. Assumindo
que você tenha o CDROM do FreeBSD montado,
faça o seguinte: # cd /cdrom/src
# cat scontrib.?? | tar xzf - -C /usr/src contrib/sendmail
Não se desespere, são apenas algumas
centenas de Kilobytes em tamanho. O arquivo README no
diretório cf serve de introdução
básica ao uso do m4. Para entregar mensagens via UUCP, o melhor conselho
é usar o mailtertable . Trata-se
de uma base de dados que o sendmail usa para basear suas
decisões de roteamento de mensagens. Primeiro, é necessário criar seu arquivo
.mc . O diretório
/usr/src/usr.sbin/sendmail/cf/cf
é o diretório home para esse tipo de
arquivo. Dê uma olhada, já existem alguns
exemplos disponíveis por lá. Se assumirmos
que você chamou o arquivo de
foo.mc , para converte-lo para um
arquivo sendmail.cf válido
basta: # cd /usr/src/usr.sbin/sendmail/cf/cf
# make foo.cf
# cp foo.cf /etc/mail/sendmail.cf
Um arquivo .mc típico, se
parece com algo mais ou menos assim: VERSIONID(`Número da sua versão ')
OSTYPE(bsd4.4)
FEATURE(accept_unresolvable_domains)
FEATURE(nocanonify)
FEATURE(mailertable, `hash -o /etc/mail/mailertable')
define(`UUCP_RELAY', your.uucp.relay )
define(`UUCP_MAX_SIZE', 200000)
define(`confDONT_PROBE_INTERFACES')
MAILER(local)
MAILER(smtp)
MAILER(uucp)
Cw your.alias.host.name
Cw youruucpnodename.UUCP As linhas contendo as entradas
accept_unresolvable_domains ,
nocanonify , e
confDONT_PROBE_INTERFACES previnem o
uso do DNS durante a entrega das mensagens. A
cláusula UUCP_RELAY é
necessária por razões bizarras, nem pergunte
quais. Apenas coloque o nome de uma estação
que possa manipular endereços com
pseudo-domínio .UUCP; normalmente o
endereço de relay de e-mail do seu Provedor de
Serviço Internet deve servir. Depois disso, é necessário usar o
arquivo /etc/mail/mailertable . Caso
exista apenas um link para fora, por onde todos os e-mails
são roteados, as seguintes definições
são o bastante: #
# makemap hash /etc/mail/mailertable.db < /etc/mail/mailertable
. uucp-dom:your.uucp.relay Um exemplo mais complexo, se pareceria com: #
# makemap hash /etc/mail/mailertable.db < /etc/mail/mailertable
#
horus.interface-business.de uucp-dom:horus
.interface-business.de uucp-dom:if-bus
interface-business.de uucp-dom:if-bus
.heep.sax.de smtp8:%1
horus.UUCP uucp-dom:horus
if-bus.UUCP uucp-dom:if-bus
. uucp-dom: Como pode-se perceber, se trata de um arquivo usado na
vida real. As primeiras três linhas tratam
situações especiais onde as mensagens
endereçadas aquele domínio não devem
ser roteadas pela saída padrão, mas ao
invés disso, ser entregues para algum servidor UUCP
vizinho, de forma a encurtar o caminho para entrega dos
e-mails. A linha seguinte trata mensagens para rede
Ethernet local, para domínios onde os mails possam
ser entregues via SMTP. Finalmente, os vizinhos UUCP
são mencionados na notação do
pseudo-domínio .UUCP, que permite um
uucp-neighbor!recipient
sobrescrever as regras padrão. A última
linha é sempre um ponto, que indica que todos os
e-mails que não foram tratados pelas entradas
anteriores cuja entrega seja do tipo UUCP, devem ser
tratados por um dos vizinhos UUCP que sirva como gateway
universal com o resto do mundo. Todas as
estações antecedendo a entrada
uucp-dom: devem ser nomes de vizinhos
UUCP válidos, que podem ser checados com o comando
uuname . Para lembrar que esse arquivo precisa ser convertido
em base de dados do tipo DBM, o comando necessário
para tomar essa ação está comentado
no início do arquivo mailertable. Esse comando
deve ser executado sempre que o mailertable for
alterado. Dica final: caso tenha dúvidas se uma rota de
e-mail em particular irá funcionar, lembre-se que a
opção -bt do sendmail
permite que ele seja iniciado em modo de testes de
endereço; simplesmente digite
3,0 seguido do endereço que
você quer testar o roteamento de mensagens. A
última linha irá indicar o agente de
transferência interno que foi usado, a
estação de destino com a qual esse agente de
entrega irá se comunicar, e o seu endereço.
Para sair desse modo, digite Control-D. % sendmail -bt
ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
Enter <ruleset> <address>
> 3,0 foo@example.com
canonify input: foo @ example . com
...
parse returns: $# uucp-dom $@ your.uucp.relay $: foo < @ example . com . >
> ^D
|
10.12. | Como eu configuro e-mail em uma conexão dialup
com a rede? |
| Se a sua conexão discada lhe atribui um
endereço IP estático, não é
necessário configurar nenhuma opção
extra. Ajuste o nome da sua estação para o
nome que a identifica na Internet, e o sendmail
fará o resto. Mas se a conexão PPP lhe atribui
endereços dinâmicos, provavelmente o seu
Provedor de Serviço Internet oferece uma conta de
correio eletrônico em seus servidores. Vamos
assumir que o nome do domínio do seu provedor
é example.net , e
que o nome do seu usuário é
user . Vamos assumir também
que o nome da sua estação seja bsd.home e que o Provedor de
Serviço Internet defina que o endereço
relay.example.net deva ser
usado para relay de mensagens eletrônicas. Para acessar as mensagens da sua caixa de correio,
é necessário usar um agente de busca. O
Fetchmail é uma boa
escolha, já que ele suporta vários
protocolos distintos. Normalmente o provedor em
questão oferece serviço de POP3. Caso sua
conexão PPP seja estabelecida à nível
de usuário (user-PPP), para acessar suas mensagens
automaticamente ao estabelecer-se uma conexão com a
rede, basta adicionar a seguinte entrada no arquivo
/etc/ppp/ppp/linkup : MYADDR:
!bg su user -c fetchmail Caso esteja usando o
sendmail (como foi descrito
anteriormente) para entregar suas mensagens para
endereços não-locais, insira o
comando: !bg su user -c "sendmail -q" depois da entrada apresentada anteriormente. Esse
comando irá forçar o
sendmail a processar sua fila
de e-mail tão logo uma conexão com a
rede seja estabelecida. Assumindo que exista uma conta para o
user na máquina bsd.home . No diretório home
do user na estação
bsd.home , crie um arquivo
.fetchmailrc com o seguinte
conteúdo: poll example.net protocol pop3 fetchall pass MySecret Esse arquivo não deve ter permissão de
leitura para nenhum outro usuário, a não ser
o user já que ele
contém a sua senha . Para garantir que o cabeçalho
from: esteja sempre correto, é
necessário indicar ao
sendmail que o endereço
user@example.net deve ser usado ao
invés de user@bsd.home .
Também é interessante configurar o
sendmail para entregar suas
mensagens via relay.example.net , permitindo
transmissão de mensagens de forma mais
rápida. O seguinte arquivo .mc deve ser o
bastante: VERSIONID(`bsd.home.mc version 1.0')
OSTYPE(bsd4.4)dnl
FEATURE(nouucp)dnl
MAILER(local)dnl
MAILER(smtp)dnl
Cwlocalhost
Cwbsd.home
MASQUERADE_AS(`example.net')dnl
FEATURE(allmasquerade)dnl
FEATURE(masquerade_envelope)dnl
FEATURE(nocanonify)dnl
FEATURE(nodns)dnl
define(`SMART_HOST', `relay.example.net')
Dmbsd.home
define(`confDOMAIN_NAME',`bsd.home')dnl
define(`confDELIVERY_MODE',`deferred')dnl Por gentileza, refira-se à seção
anterior para obter detalhes sobre como transformar esse
arquivo .mc em um arquivo
sendmail.cf . Não se
esqueça também de reiniciar o
sendmail depois de alterar o
sendmail.cf . |
10.13. | Que outros servidores de correio eletrônico
posso usar no lugar do Sendmail? |
| O Sendmail é
o programa servidor de correio eletrônico
padrão no FreeBSD, mas ele pode ser facilmente
substituído por qualquer outro MTA (por
instância, um MTA instalado a partir do
ports ). Existem vários MTA's que servem de alternativa
ao Sendmail na Coleção de
Ports do FreeBSD, sendo o mail/exim, mail/postfix, mail/qmail, mail/zmailer, os mais
populares. A diversidade é sempre uma boa
indicação, e o fato de ter vários
servidores de e-mail disponíveis é
ótimo. Conteúdo, evite perguntas como
“O Sendmail é melhor que o Qmail?” nas
listas de discussão. Se você realmente quer
saber, procure no histórico das listas. As
vantagens e desvantagens de cada MTA já foram
discutidas inúmeras vezes. |
10.14. | Esqueci a senha de root! O que eu faço? |
| Em primeiro lugar, não entre em pânico!
Reinicie o seu FreeBSD, digite boot
-s na tela do Boot: (ou apenas
-s para as versões
anteriores à 3.2 do FreeBSD) para entrar e modo
monousuário. Quando o sistema perguntar sobre que
shell usar, aperte ENTER. Você estará em uma
prompt de comandos; digite mount -u /
para montar o sistema de arquivos raiz com
leitura/escrita, e depois mount -a para
remontar todos os seus sistemas de arquivos. Execute o
comando passwd root para modificar a
senha de root do sistema, e depois digite exit(1)
para continuar a inicialização em modo
multiusuário. |
10.15. | Como posso evitar que a seqüência de teclas
Control+Alt+Delete
reinicie o sistema? |
| Caso esteja usando o syscons (o driver padrão
para o console) em um sistema FreeBSD 2.2.7 ou posterior,
construa e instale um novo
kernel com a
opção: options SC_DISABLE_REBOOT Caso use o driver de console PCVT em um FreeBSD 2.2.5
ou posterior, use a seguinte linha: options PCVT_CTRL_ALT_DEL Em versões anteriores às citadas, edite
o mapeamento do seu teclado, usado para o console, e
substitua a palavra boot por
nop . O mapeamento de teclado
padrão está em
/usr/share/syscons/keymaps/us.iso.kbd .
O /etc/rc.conf deve ser
instruído de forma que esse arquivo seja lido. Se
você estiver usando um outro mapa específico
para o seu país, edite esse mapa ao invés do
padrão. |
10.16. | Como posso converter arquivos de texto do DOS para o
formato do Unix? |
| Use esse comando do perl: % perl -i.bak -npe 's/\r\n/\n/g' file...
onde file indica o arquivo ou
arquivos a serem processados. As
modificações são feitas no
próprio arquivo e o original é salvo com a
extensão .bak. O comando tr(1) também pode ser
usado: % tr -d '\r' < dos-text-file > unix-file
Onde dos-text-file é
o arquivo com o texto em formato DOS, enquanto o
unix-file armazenará a
saída convertida. Usar o tr(1) é um
pouco mais rápido do que usar o perl. |
10.17. | Como eu mato processos pelo seu nome? |
| Use o comando killall(1). |
10.18. | Por que motivos o su está me atazanando pelo
fato de não pertencer à ACL do
root ? |
| Esse erro é proveniente do sistema de
autenticação da distrição do
Kerberos. O problema não é uma
perturbação fatal. Basta executar o su com
a opção -K ou então desinstalar o
Kerberos, como será descrito na próxima
questão. |
10.19. | Como eu desinstalo o Kerberos? |
| Para remover o Kerberos do sistema, reinstale a
distribuição bin da
versão que está sendo usada. Caso tenha o
CDROM do FreeBSD, monte-o (vamos assumir, em /cdrom) e
execute os comandos: # cd /cdrom/bin
# ./install.sh
Ou então, apague todas as opções
“MAKE_KERBEROS” do
/etc/make.conf e recompile todo o
sistema com um build world. |
10.20. | Como posso adicionar pseudo-terminais ao
sistema? |
| Caso tenha inúmeras conexões telnet,
ssh, X, ou tela de usuário, é
provável que você atingirá o limite
dos seus pseudo-terminais. Aqui estão as
instruções de como adicionar mais
pseudo-terminais: Construa e instale um novo
kernel com a
linha pseudo-device pty 256 em seu arquivo de
configurações. Execute os comandos # cd /dev
# sh MAKEDEV pty{1,2,3,4,5,6,7}
de forma a criar 256 novos devices para os novos
terminais. Edite o /etc/ttys e adicione
uma linha para cada um dos 256 terminais. Tais
entradas devem ter o formato correspondente às
entradas já existentes, por exemplo: ttyqc none network A ordem de definição das letras
é expressa como
tty[pqrsPQRS][0-9a-v] , ao
ilustrarmos em expressões regulares. Reinicie o sistema com o novo
kernel, e
pronto.
|
10.21. | Por que motivo não consigo criar a device
snd0? |
| Simples, porque não existe a device
snd . Esse nome é usado
para identificar o conjunto de devices que compõem
os drivers de som do FreeBSD, como as devices
mixer ,
sequencer , e
dsp . Para criar tais devices, basta executar: # cd /dev
# sh MAKEDEV snd0
|
10.22. | Como posso reler o /etc/rc.conf e
reiniciar o /etc/rc sem rebootar o
sistema? |
| Vá para o modo monousuário e volte para
o modo multiusuário. É simples; no console, faça: # shutdown now
(Note: without -r or -h)
# return
# exit
|
10.23. | O que é uma sandbox? |
| “Sandbox” é um jargão usado
em discussões pertinentes à segurança
de sistemas. Pode significar duas coisas: Um processo enquadrado em um conjunto de paredes
virtuais que são criadas para prevenir que
algum usuário, ao explorar alguma
inconformidade do processo, possa também
explorar e obter privilégios no sistema
operacional como um todo. O processo deve conseguir “rodar”
dentro dessas paredes, ou seja, nada que o processo
possa fazer ao executar seu código, pode ser
capaz de violar tais paredes. Dessa forma não
é necessária uma auditoria detalhada do
código e das ações do processo
para que se possa realizar algumas
afirmações pertinentes à
segurança de tal sistema. Tais paredes podem ser a
identificação de um usuário
(userid), por exemplo. Essa é a
definição de sandbox usada nas
páginas de manuais do named e de
security. Observe o serviço ntalk ,
como exemplo (veja o /etc/inetd.conf). Esse
serviço costumava ser executado com userid do
root . Hoje em dia o processo
roda com o userid do tty . O
usuário tty , portanto,
é uma sandbox criada para dificultar qualquer
atividade de um usuário malicioso que por
ventura consiga acesso ao sistema por meio do ntalk.
Com essa sandbox, uma violação de
segurança bem sucedida via
ntalk dificultaria qualquer
ação tomada além das
possíveis com o userid do
tty . Um processo criado dentro de um ambiente de
simulação. Essa é uma
situação mais complexa. Basicamente
implica que qualquer pessoa má intencionada que
consiga explorar tal processo, acreditará que
pode obter acesso à todo o ambiente, nas na
verdade, estará apenas acessando um sistema de
simulação, não alterando nenhum
dado real. A forma mais comum de conseguir criar um ambiente
simulado como esse, é criando um
subdiretório à partir de onde o processo
consiga acessar (uma cópia de) qualquer arquivo
do sistema que por ventura ele precise, e executar
esse processo simulando um diretório raiz (ou
seja, para o processo, o /
será o subdiretório determinado, e
não o verdadeiro / do
sistema). Outra situação comum é montar
um sistema de arquivos base com apenas
permissão de leitura, e depois criar um outro
sistema de arquivos em uma camada superior, com acesso
de escrita/leitura, dando ao processo a
impressão de poder ler/escrever em todo o
sistema de arquivos. Apenas o processo em
questão percebe esse ambiente, enquanto os
outros não são necessariamente
ludibriados. A intenção é que tais sandbox
sejam tão transparentes que qualquer
usuário (ou hacker) não consiga perceber
que está dentro de uma.
Os sistemas Unix costumam implementar esses dois
principais tipos de sandbox, um em nível de
processo e o outro, muito comum, em nível de
userid. Cada processo Unix é completamente separado dos
outros, por meio de algum tipo de parede de
segurança. Um processo nunca modifica o
espaço de endereçamento de outro, diferente
do ambiente Windows onde cada processo pode facilmente
sobrescrever endereços de outros processos, fazendo
o sistema travar. Cada processo Unix é de propriedade de um
userid em particular. Caso o userid não seja do
root , ele serve de parede de
segurança em relação aos processos
pertencentes a outros usuários. Os userid
também são usados para proteger dados
armazenados em disco. |
10.24. | O que é securelevel
(nível de segurança do sistema)? |
| securelevel (nível de
segurança do sistema) é um mecanismo de
segurança implementado no
kernel do FreeBSD.
Basicamente, quando o securelevel
é positivo, o kernel
restringe algumas tarefas do sistema; nem mesmo o
superusuário (por exemplo, o
root ) tem permissão de
realizar tais tarefas. Na data que este
FAQ foi escrito, o mecanismo de
securelevel do FreeBSD era capaz de,
entre outras coisas, limitar as habilidades de:
retirar algumas flags de arquivos, como a
schg (flag de imutabilidade do
sistema), escrever na memória do
kernel por meio do
/dev/mem e
/dev/kmem , carregar módulos do
kernel, e alterar regras de Firewall do
ipfirewall(4).
Para verificar o estado do
securelevel (nível de
segurança do sistema) em um sistema em funcionando,
simplesmente execute o seguinte comando: # sysctl kern.securelevel
A saída apresentará o nome da
variável do sysctl(8) (nesse caso,
kern.securelevel ) e um número.
Esse último será o valor atual do
nível de segurança do
kernel do FreeBSD. Caso
esse valor seja positivo (maior que 0), ao menos algumas
das características dos níveis de
segurança estarão habilitadas. Os níveis de segurança não podem
ser diminuídos em um sistema que está
funcionando se isso fosse possível o
securelevel (nível de
segurança do sistema) perderia sua funcionalidade.
Caso seja necessário executar alguma tarefa que
necessite que o nível de segurança seja
não-positivo (por exemplo, um
installworld ou alterar a data do
sistema) será preciso alterar as
definições de securelevel
(nível de segurança do sistema) no
/etc/rc.conf (mais precisamente, as
variáveis kern_securelevel e
kern_securelevel_enable ) e reiniciar o
sistema. Para obter mais informações quanto aos
níveis de segurança e sobre as
funções específicas de cada
nível, por gentileza, consulte a página de
manual do init(8). Atenção: O securelevel (nível de
segurança do sistema) não é uma
bala de prata; ele tem várias deficiências
óbvias. A mais frequênte é provocar
uma falsa sensação de
segurança. Um dos maiores problemas, e portanto que deve ser
bem observada pelo administrador do sistema, é
que, para que o securelevel
(nível de segurança do sistema) se torne
efetivo, todos os arquivos usados pelo processo de
inicialização até que os
níveis de segurança se tornem positivos,
devem estar seguros. Se um usuário que deseja
atacar o sistema, conseguir que seu código seja
executado antes que o nível de segurança
seja definido (o que ocorre pouco depois do processo de
inicialização, visto que algumas
funções que o sistema precisa realizar,
não podem ser iniciadas com um nível
elevado de segurança), a proteção
do securelevel (nível de
segurança do sistema) será invalidada.
Por outro lado, a tarefa de assegurar que todos os
arquivos necessários pelo processo de
inicialização estejam em conformidade,
não é tecnicamente impossível, mas,
O processo de manutenção de um ambiente em
tais condições se tornaria um pesadelo,
visto que seria necessário baixar o sistema, no
mínimo para modo monousuário sempre que
fosse necessário modificar os arquivos de
configuração do mesmo. Esse e outros pontos são freqüentemente
discutidos nas listas do FreeBSD, em especial na
freebsd-security. Por gentileza, queira fazer uma busca
no histórico da lista, clicando
aqui, para uma discussão extensa sobre
o assunto. Algumas pessoas estão
esperançosas de que o securelevel logo
será afastado, em favor de um mecanismo de
segurança mais refinado, mas as coisas ainda
estão confusas a este respeito. Considere-se advertido. |
10.25. | Tentei atualizar meu sistema para o último
-STABLE, mas ele se tornou -RC ou -PRERELEASE! O que
está havendo? |
| A resposta mais curta: É só um nome, RC
é um acrônimo para “Release
Candidate”. Significa que uma nova versão
está eminente. No FreeBSD, -PRERELEASE é
tipicamente um sinonimo de código congelado antes
de uma nova versão. (Em algumas versões, o
título -BETA foi usado sob as mesmas
circunstâncias em que o -PRERELEASE seria). A resposta longa: O FreeBSD normalmente deriva suas
versões de duas fontes de origem. As
versões principais, ponto-zero, como o 3.0-RELEASE
e o 4.0-RELEASE que são marcadas inicialmente como
o topo da cadeia de desenvolvimento, normalmente chamados
de -CURRENT. As
versões menores (como 3.1-RELEASE ou 4.2-RELEASE),
são criados a partir do
snapshot mais recente da
ramificação ativa marcada como -STABLE. A partir do
4.3-RELEASE, cada versão conta também com
sua própria ramificação, que pode ser
acessada por usuários que queiram apenas um
nível extremamente conservador de desenvolvimento
(tipicamente, apenas consultores de
segurança). Quando uma versão está para ser criada,
a ramificação de onde ela se derivará
deve passar por um certo processo. Parte desse processo
é o congelamento do código. Quando o
processo de congelamento do código se inicia, o
nome desta ramificação é alterado
para indicar que ela está para se tornar uma
versão. Por exemplo, se a
ramificação usada chamava-se 4.5-STABLE, ela
passa a se chamar 4.6-PRERELEASE para indicar que o
código está congelado, e indicar que testes
extras, pré versão, estão
acontecendo. Durante esse período
alterações pertinentes a
correções de problemas são
realizadas. Quando o novo código está
pronto para ser lançado, ele passa a ser chamado de
-RC (nesse exemplo, 4.6-RC), indicando que provavelmente a
nova versão será criada a partir do
código atual. Nesse estágio, apenas os
problemas mais sérios são corrigidos.
Depois que a versão é finalmente
lançado (4.6-RELEASE nesse exemplo) e a nova
ramificação com o nome dessa versão
foi criada, ela passa a se chamar -STABLE; 4.6-STABLE no
nosso exemplo. Para obter mais informações sobre a
numeração das versões e sobre as
várias ramificações CVS, por
gentileza, refira-se ao artigo sobre a Engenharia de
Releases. |
10.26. | Tentei instalar um novo
kernel, mas a rotina de
chflags falhou. O que posso fazer? |
| A resposta curta: provavelmente você está
com o securelevel (nível de
segurança do sistema) acima do 0. Reinicie o
sistema em modo mono usuário e instale o
kernel. A resposta mais completa: O FreeBSD não permite
que as flags do sistema sejam alteradas caso o
securelevel (nível de
segurança do sistema) seja maior que 0. O
nível atual do securelevel
(nível de segurança do sistema) pode ser
verificado com o comando: # sysctl kern.securelevel
O securelevel (nível de
segurança do sistema) não pode ser
diminuído; é necessário iniciar o
sistema em modo mono usuário, ou alterar o
nível de segurança em
/etc/rc.conf , depois reiniciar. Veja
a página de manual do init(8) para obter
informações mais detalhadas sobre o
securelevel (nível de
segurança do sistema), e veja também o
/etc/defaults/rc.conf e a
página de manual do rc.conf(5) para obter mais
informações quanto ao rc.conf. |
10.27. | Não consigo alterar mais de um segundo na hora
no meu sistema. O que posso fazer? |
| A resposta curta: provavelmente o sistema está
com securelevel (nível de
segurança do sistema) acima do 1. Reinicie o
sistema em modo mono usuário e altere a
data. A resposta mais completa: O FreeBSD não permite
que a hora do sistema seja alterada por mais de um segundo
quando o securelevel (nível de
segurança do sistema) do
kernel é maior que
1. O nível atual do securelevel
(nível de segurança do sistema) pode ser
verificado com o comando: # sysctl kern.securelevel
O securelevel (nível de
segurança do sistema) não pode ser
diminuído; é necessário iniciar o
sistema em modo mono usuário, ou alterar o
nível de segurança em
/etc/rc.conf , depois reiniciar. Veja
a página de manual do init(8) para obter
informações mais detalhadas sobre o
securelevel (nível de
segurança do sistema), e veja também o
/etc/defaults/rc.conf e a
página de manual do rc.conf(5) para obter mais
informações quanto ao rc.conf. |
10.28. | Por que motivo o rpc.statd
está usando 256 megabytes de memória? |
| Não, mão existe nenhuma falha no uso da
memória, e ele nã é usando 256MB de
RAM. Ele simplesmente gosta de (ele sempre faz isso)
mapear uma quantia obscena de memória em seu
endereçamento, simplesmente por conveniência.
Não existe nada terrivelmente errado com esse
comportamento, de um ponto de vista técnico; a
única questão é que assim o
top(1) e o ps(1) ficam completamente
perdidos. O rpc.statd(8) mapeia seu arquivo de status
(localizado sob o /var ) no seu
endereçamento para economiza
preocupações sobre esse remapeamento em um
segundo momento, quando o arquivo precisa crescer. O
mapeamento é feito a um valor enorme. Analisando o
código fonte, podemos evidenciar que o tamanho do
argumento do mmap(2) é
0x10000000 , ou exatos 256MB em sistemas
de arquitetura IA32. |
10.29. | Por que eu não posso retirar a flag
schg dos arquivos? |
| O sistema está sendo executado em um
nível de segurança elevado (maior que 0).
Diminua o nível de segurança e tente
novamente. Para obter mais informações, por
gentileza, refira-se à seção sobre
securelevel
(nível de segurança do sistema) do
FAQ , e à página de manual
do init(8) |
10.30. | Por que a autenticação do SSH via
.shosts não funciona por
padrão nas versões recentes do
FreeBSD? |
| O motivo é simples. A
autenticação via
.shosts não funciona mais por
padrão porque o ssh(1) não está
instalado com suid de root por padrão.
Razões óbvias de segurança. Para
“corrigir” isto, pode-se fazer o
seguinte: Para uma alteração permanente,
defina ENABLE_SUID_SSH como
true no arquivo
/etc/make.conf e recompile o ssh
(ou execute um make world). Uma correção temporária pode
ser mudar os modos de permissão do
/usr/bin/ssh para
4555 simplesmente executando o
comando chmod 4555 /usr/bin/ssh
logado como root . Depois, defina
ENABLE_SUID_SSH= true no
/etc/make.conf para que as
alterações tenham efeito todas as vezes
que um make world for feito.
|
10.31. | O que é o vnlru ? |
| O vnlru limpa e libera os vnodes
quando o sistema atinge o limite do
kern.maxvnodes . Essa thread do
kernel se mantém
inativa a maior parte do tempo, e só se inicia caso
exista uma grande quantidade de memória RAM, e o
sistema esteja acessando dezenas de milhares de arquivos
pequenos. |