DEIVIS F. PIRANI

Este pequeno aplicativo foi escrito como parte de meu trabalho de conclusão do curso de Ciência da Computação em 2005.
Ele intruduz uma forma simplificada de se controlar a quantidade de bits/s que um host IP pode trafegar na rede, utilizando é claro as funcionalidades do kernel Linux equipado com CBQ para tal.
Os scripts são simples e escritos em Bash, podendo ser facilmente alterados e adaptados a qualquer ambiente.

Dentro do pacote .tar, encontra-se um script de instalação, juntamente com arquivos explicativos e exemplos de uso.
Para descomprimir o arquivo utiliza o comando:

[deivis@deivis tmp]$ tar xvf bandctrl-1.0.tar

Para instalar:

[deivis@deivis tmp]$ cd bandctrl-1.0
[deivis@deivis bandctrl-1.0]$ ./install.sh

O arquivo de configuração encontra-se em /etc/bandctrl/users.conf

Dúvidas, sugestões e melhorias, deixe seu comentário ou mail to contato@deivis.eti.br

Donwload do BandCTRL 1.0, clique aqui.
* Caso seja solicitada uma senha de acesso ao FTP, tecle “ENTER”.

Este post tem por objetivo ilustrar uma aplicação cliente / servidor que utiliza IP sobre TCP para enviar e receber bytes.
O exemplo aborda um software cliente e um servidor de echo, que podem ser utilizados por iniciantes na programação em linguagem C para redes.
O cliente se conecta ao servidor e envia bytes, e em resposta o servidor echoa de volta os bytes enviados e mostra um resumo das linhas e bytes recebidos e enviados.
Ao receber os dados echoados pelo servidor, o cliente os imprime para a saída padrão (stdout) e mostra um resumo contendo a quantidade de linhas e bytes enviados e também o tempo de execução no envio dos dados.

A execução do servidor é feita pelo comando:
[deivis@deivis lab3]$ ./server_echo_tcp

A sintaxe de uso do cliente deve seguir o modelo:
cliente_echo_tcp host_servidor

É possível redirecionar dados da entrada padrão para o socket da conexão:
[deivis@deivis lab3]$ ./client_echo_tcp locahost < texto.txt

Neste caso o servidor irá echoar de volta o contúdo do arquivo, e ao final mostrará um resumo das linhas e bytes enviados e recebidos.

Os códigos seguem abaixo:


/*
*
* server_echo_tcp.c
*
* Deivis Fernandes Pirani - contato@deivis.eti.br - http://www.deivis.eti.br
*
*/

#include
#include
#include
#include
#include
#include
#include
#include
#include

#define MYPORT 3490
#define BACKLOG 10
#define MAXDATASIZE 1024

main()
{
int sockfd, new_fd, numbytes;
int qtlinhas, qtchar;
struct sockaddr_in my_addr;
struct sockaddr_in their_addr;
int sin_size;
char buf[MAXDATASIZE];
FILE *rsock, *wsock;

qtlinhas=qtchar=0;

if ((sockfd = socket(AF_INET, SOCK_STREAM, 0)) == -1) {
perror("socket");
exit(1);
}

my_addr.sin_family = AF_INET;
my_addr.sin_port = htons(MYPORT);
my_addr.sin_addr.s_addr = INADDR_ANY;
bzero(&(my_addr.sin_zero), 8);

if (bind(sockfd, (struct sockaddr *)&my_addr, sizeof(struct sockaddr)) == -1) {
perror("bind");
exit(1);
}

if (listen(sockfd, BACKLOG) == -1) {
perror("listen");
exit(1);
}

system("clear");
while(1) {
sin_size = sizeof(struct sockaddr_in);
fprintf(stderr,"\nAguardando envio do cliente.\n");
qtchar=qtlinhas=0;
if ((new_fd = accept(sockfd, (struct sockaddr *)&their_addr, &sin_size)) == -1) {
perror("accept");
continue;
}
rsock=fdopen(new_fd,"r");
wsock=fdopen(new_fd,"w");

fprintf(stderr,"Recebendo.\n");
while((fgets(buf, MAXDATASIZE, rsock)) != NULL)
{
fflush(rsock);
printf("> %s",buf);
if((fputs(buf, wsock)) == -1)
{
perror("send");
exit(1);
}
fflush(wsock);
// Quantidade de caracteres e linhas eviados pelo cliente
qtchar=qtchar+strlen(buf);
qtlinhas++;
}

fprintf(stderr,"\nQuantidade de linhas.........: %d\n", qtlinhas);
fprintf(stderr,"Quantidade de bytes.....: %d\n", qtchar);
}
close(new_fd);
}



*/
* client_echo_tcp.c
*
* Deivis Fernandes Pirani - contato@deivis.eti.br - http://www.deivis.eti.br
*
/*


#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include

#define PORT 3490
#define MAXDATASIZE 1024

int main(int argc, char *argv[])
{
int sockfd, inputbytes, bytessent, bytesrecv;
int qtlinhas, qtchar;
char buf[MAXDATASIZE];
struct hostent *he;
struct sockaddr_in their_addr;
clock_t start, end;
struct tms inicio, fim;
float tempoexec;
FILE *rsock, *wsock;

qtlinhas=qtchar=0;

// Tempo de início
start=times(&inicio);

if (argc != 2) {
fprintf(stderr,"usage: client hostname\n");
exit(1);
}

if ((he=gethostbyname(argv[1])) == NULL) {
perror("gethostbyname");
exit(1);
}

if ((sockfd = socket(AF_INET, SOCK_STREAM, 0)) == -1) {
perror("socket");
exit(1);
}

their_addr.sin_family = AF_INET;
their_addr.sin_port = htons(PORT);
their_addr.sin_addr = *((struct in_addr *)he->h_addr);
bzero(&(their_addr.sin_zero), 8);

if (connect(sockfd, (struct sockaddr *)&their_addr, sizeof(struct sockaddr)) == -1) {
perror("connect");
exit(1);
}
rsock=fdopen(sockfd,"r");
wsock=fdopen(sockfd,"w");

while(1)
{
if((fgets(buf, MAXDATASIZE, stdin)) == NULL)
{
fprintf(stderr,"\nQuantidade de linhas.........: %d\n", qtlinhas);
fprintf(stderr,"Quantidade de bytes.....: %d\n", qtchar);
// Tempo de finalização
end=times(&fim);
// Converte tempo em segundos
tempoexec=(float)(end-start)/sysconf(_SC_CLK_TCK);
fprintf (stderr,"Tempo de execucao: %4.1f\n\n", tempoexec);
exit(0);
}
if((fputs(buf, wsock)) < 0)
{
perror("send");
exit(1);
}
fflush(wsock);
if((fgets(buf, MAXDATASIZE, rsock)) == NULL) {
perror("recv");
exit(1);
}
fflush(rsock);
// Quantidade de caracteres e linhas eviados ao servidor
qtchar=qtchar+strlen(buf);
qtlinhas++;
printf("> %s",buf);
}
close(sockfd);

return 0;
}


1 – INTRODUÇÃO

No contexto das redes de computadores, ou de forma mais ampla no contexto da Internet, o termo segurança está cada vez mais presente, seja por indicar incidentes envolvendo falhas em aplicações ou mesmo por conscientizar usuários e administradores da importância em se adotar medidas preventivas. De forma simplificada a intenção é sempre manter a informação íntegra, em sigilo e disponível quando necessária. A segurança das redes e sistemas ou, então, a insegurança destes influenciam diretamente essas premissas.
De modo geral, as informações encontram-se armazenadas em servidores ou mesmo em estações de trabalho e a segurança destes é fundamental considerando-se que para obter acesso a essas informações seria necessário obter acesso de alguma forma a esses hosts.
Sistemas operacionais de modo geral, sejam eles proprietários ou de código aberto implementam mecanismos para melhorar a segurança no que se diz respeito a acesso controlado a aquivos e programas. A maioria desses mecanismos implementa um modelo conhecido como DAC (Discretionary Access Control) abordada no capítulo 1.2.1 – Discretionary Access Control – DAC.
Em um esforço de incrementar as funcionalidades disponibilizadas pela implementação do DAC em sistemas Linux, a National Security Agency – NSA em conjunto com a comunidade SELinux implementou no kernel Linux uma arquitetura de segurança conhecida como Flask que define um modelo MAC (Mandatory Access Control) de acesso a objetos do sistema.

SUMÁRIO

1 – Introdução
1.1 – Definição
1.2 – Modelo DAC X MAC
1.2.1 – Discretionay Access Control – DAC
1.2.2 – Mandatory Access Control – MAC
1.3 – Arquitetura Flask

2 – Funcionamento
2.1 – Strict Policy
2.2 – Targeted Policy
2.3 – Segurança baseada em contexto
2.3.1 – Identidades
2.3.2 – Papéis
2.3.3 – Tipos
2.3.4 – Nível
2.4 – Permissões de acesso e transição

3 – Aplicando SELinux
3.1 – Políticas
3.2 – Variáveis booleanas
3.3 – Comandos e configurações úteis
3.3.1 – Arquivo principal de configuração SELinux
3.3.2 – Comandos de status
3.3.3 – Comandos de interação

4 – Conclusão

REFERÊNCIAS BIBLIOGRÁFICAS

1.1 – Definição

Security-Enhanced Linux é uma implementação da arquitetura de segurança Flask (Flux Advanced Security Kernel) para controle de acesso mandatório flexível em sistemas operacionais. Foi criado para demonstrar o valor do controle de acesso mandatório flexível e a intensidade de controle adicionado ao sistema operacional [NSA].
De forma simplificada, SELinux pode ser definido como sendo um conjunto de alterações no kernel Linux que juntamente com alguns utilitários disponibiliza uma forte arquitetura de controle de acesso mandatório a objetos do sistema, que podem ser aquivos, diretórios, processos, sistemas de arquivos, etc.

1.2 – Modelo DAC X MAC

Ambos os modelos DAC e MAC podem ser implementados em sistemas operacionais, e é importante mencionar que SELinux não impõe um modelo MAC para substituir o DAC implementado no Linux, mas sim incrementar a segurança disponibilizada pelo primeiro.
Para entender melhor o funcionamento do SELinux é importante entender os conceitos de Discretionary Access Control e Mandatory Access Control, DAC e MAC respectivamente, e uma explicação destes vem a seguir.

1.2.1 – Discretionay Access Control – DAC

DAC define um modelo de acesso aos objetos do sistema baseado no conceito de que os sujeitos (usuários) são os proprietários de determinados objetos, tendo desta forma permissão para executar qualquer tipo de operações sobre eles, como por exemplo editar, apagar, executar ou, então até mesmo delegar essas permissões a outros usuários ou grupos.
Este modelo é amplamente implementado na maioria dos sistemas operacionais existentes, porém apresenta alguns pontos de falha no que se diz respeito a aplicações poderem executar funções fora de seu escopo por falhas em seus códigos (bugs) e conseqüentemente causarem danos ao S.O. que podem comprometer seu funcionamento por completo.
Supondo um servidor web Apache em execução pelo usuário root em um sistema operacional Linux. Se o processo do Apache (httpd) possuir algum bug que permita a um atacante obter acesso a comandos do sistema, como por exemplo o comando rm, através do serviço httpd esses comandos serão executados com as permissões do root. Desta forma o atacante obteria acesso completo aos sistema de arquivos podendo alterar ou mesmo apagar qualquer arquivo.
Considerando-se que bugs em aplicações são comuns, muitas vezes devido ao nível de complexidade destas ou mesmo por irresponsabilidade de desenvolvedores, manter a segurança de um sistema apenas com implementações do modelo DAC pode não ser a melhor opção.

Figura 1 – Atributos de arquivo – DAC

1.2.2 – Mandatory Access Control – MAC

O modelo mandatório, em contrapartida ao modelo discricionário, não permite que usuários modifiquem permissões de objetos do sistema mesmo sendo eles os proprietários desses objetos.
Isso não significa que um usuário não poderá alterar permissões de seus arquivos, mas sim que isso será feito a nível do DAC, tendo posteriormente que se submeter às verificações do que está definido no MAC.
O conceito se resume ao fato de que um usuário comum não é considerado dono de objetos, não podendo também desta forma definir suas permissões, tarefa essa permitida apenas aos administradores do sistema. Esse fato indica também que usuários comuns não podem conceder permissões seja de forma intencional ou acidental e isso impede o acesso a recursos e dados para usuários não autorizados, considerando-se que tais recursos estão protegidos pelas políticas impostas pelo sistema.

Figura 2 – Atributos de arquivo – MAC

1.3 – Arquitetura Flask

A arquitetura Flask surgiu com a evolução de projetos de pesquisa iniciados em 1992 pela National Security Agency (NSA) e Security Computing Corporation (SCC) com o objetivo desenvolver mecanismos flexíveis para controle de acesso a sistemas.
O nome Flask foi dado após a integração da Universidade de Utah no projeto para portar o projeto chamado Distributed Trusted Operating System a um sistema operacional de pesquisas chamado Fluke. Durante a integração DTOS / Fluke, a arquitetura evoluiu para prover suporte a políticas dinâmicas de segurança e depois desta evolução a arquitetura foi nomeada Flask. [Smalley, S. - NSA]

2 – FUNCIONAMENTO

Em síntese, o SELinux tem por objetivo confinar programas de usuário e serviços do sistema operacional em um ambiente de recursos mínimos de privilégios para seu funcionamento, fazendo com que desta forma o risco de comprometimento do sistema operacional por falhas de buffer overflow ou de configurações seja minimizada ou até mesmo eliminadas.
Isso é feito através de uma análise a nível de kernel na qual ações são verificadas tendo como base o que está definido nas políticas, e estas podem ser construídas de maneiras diferentes considerando-se que o SELinux permite configurar o tipo de política a ser utilizada no sistema.
As políticas podem ser de modo geral descritas em três tipos:

2.1 – Strict Policy

Foi uma das primeiras tentativas de implementar SELinux em distribuições como Fedora Linux 2, porém este modelo acabou por criar uma imagem de que o sistema não era funcional e a maioria dos administradores desabilitava seu funcionamento. Isto aconteceu devido ao fato de que a strict policy tem um modelo que proíbe por padrão qualquer atividade no sistema sendo permitido apenas o que foi definido nas políticas.
Esse modelo acabou por colocar imposições no uso do sistema operacional devido às políticas muitas vezes não cobrirem todas as necessidades de uso, o que acabou levando o SELinux a ficar com uma imagem de um sistema complexo e com problemas de funcionamento.

2.2 – Targeted Policy

É o modelo corrente utilizado no Fedora Core Linux e Red Hat Enterprise Linux. Define um forma de prover segurança ao sistema de forma a encapsular o funcionamento de aplicações conforma a necessidade do usuário.
Diferentemente da política estrita (strict policy) a política segmentada define um modelo no qual o confinamento e segurança é feito por domínios a que as aplicações (processos) pertencem. Por exemplo, se é desejável proteger o servidor WEB Apache então utiliza-se para os processos desta aplicação o domínio httpd_t que informa ao sistema de segurança SELinux que esta aplicação está encapsulada às políticas referente ao serviço desejado, desta forma é possível não utilizar uma política referente a determinado serviço, fazendo com que este funcione com domínio unconfined_t, sem as restrições de segurança do SELinux.
Tal mecanismo faz-se mais flexível, pois desta maneira pode-se desabilitar as restrições SELinux para uma determinada aplicação conforme desejar, sem ter que desativar totalmente a proteção do sistema como acontecia nas implementações de strict policy.

2.3 – Segurança baseada em contexto

SELinux utiliza conceitos gramaticais para classificar os elementos em um sistema de segurança, sendo utilizados termos gramaticais comuns como sujeitos, objetos e ações.
Sujeitos de uma forma geral podem ser vistos como sendo os processos de um sistema que executam ações sobre os objetos. Os objetos são compostos por quaisquer elementos que se queira proteger, como por exemplo arquivos, diretórios, sistemas de arquivos, inodes, etc.
As ações como se pode imaginar, são quaisquer operações que um sujeito queira executar sobre um objeto, e estas são relativas ao tipo ou classe que representa o objeto em questão.
Um contexto de segurança SELinux pode ser entendido como a relação entre os componentes do xattr que um sujeito possui para com componentes do xattr dos objetos que ele deseja executar uma ação. Essas componentes em sistemas Linux são conhecidas como atributos extendidos (extended attributes – xattr) conforme mostrado na Figura 2 – Atributos de arquivos – MAC e que são constituídos de: usuário, papel, tipo e nível de segurança.
A Figura 3 – Atributos estendidos ilustra essas propriedades.

Figura 3 – Atributos estendidos

2.3.1 – Identidades

O componente user_u define a identidade (tipo de usuário SELinux) do objeto dentro de um sistema de segurança SELinux, user_u por exemplo na maioria dos casos se refere a usuários comuns e não privilegiados, deamons e processos inicializados pelo sistema terão o campo identidade como sendo system_u em um segundo exemplo.
A identidade pode ser vista como uma forma de agrupar papéis, tendo em vista que os usuários podem assumir vários papéis em um sistema, obviamente definidos na política, como por exemplo um usuário comum (user_u) pode escrever em seu homedir e posteriormente um usuário auditor que por possuir este papel poderá ler as informações contidas no homedir em questão por exemplo.
As políticas padrões que acompanham o SELinux já traz identidades SELinux suficientes para representar os tipos de usuário na maioria dos sistemas (user_u, system_u, unconfined_u, etc).

2.3.2 – Papéis

O campo papel por sua vez pode ser visto como uma forma de agrupar tipos de segurança, que serão discutidos posteriormente. Em um sistema de segurança SELinux as permissões não são dadas aos papéis mas sim aos tipos a que estes papéis possam assumir.
Por exemplo, se um usuário administrador do sistema costuma logar para praticar tarefas de auditoria ele então poderá ter como papel staff_r, porém se ele precisar logar para efetivamente alterar configurações deverá ter o papel sysadm_r.
Quando uma política é definida, o desenvolvedor pode dizer quais papéis terão acessos a quais tipos, e desta maneira dependendo do papel de um objeto ou processo, este poderá assumir diferentes tipos.
Para arquivos de modo geral, o papel será sempre object_r dentro de um contexto de segurança. Isto porque de modo geral um arquivo não executa operações sobre outros objetos, tarefa esta atribuídas aos processos do sistema e estes sim poderão desempenhas papéis diversos.

2.3.3 – Tipos

Conforme mencionado anteriormente os tipos possuem efetivamente as permissões em um sistema de segurança SELinux e são atributos dados a aquivos, processos (normalmente conhecido coo domínio), portas de rede, ou qualquer outro tipo de objeto de um sistema.
Um sistema SELinux, atravéz das políticas, utiliza o atributo tipo como verificação primaria de autorização, daí o termo Type Enforcement. Processos e objetos do mesmo tipo irão possuir uma relação de acesso, por exemplo, um processo do tipo httpd_t poderá executar ações sobre arquivos do tipo httpd_*_t.
Desta forma um processo não poderá acessar objetos que estejam fora de seu domínio (tipo), o que impede que diversos problemas de segurança venham a ocorrer, como por exemplo a escalação de privilégios por parte destes.

2.3.4 – Nível

O quarto campo de um contexto SELinux indica o nível a que o objeto ou sujeito pertencem dentro de um tipo MLS (Multi Layer Security) de política SELinux.
O tipo de política MLS foi foi desenvolvido para compatibilizar sistemas Linux a obter a certificação EAL4/LSPP, onde o sistema operacional estaria a nível de segurança apto a trabalhar em sistemas governamentais e militares.
Não será abordado neste trabalho conceitos de segurança multi-nível pois estes possuem uso mais restrito e fora dos ambientes mais convencionais. Maiores informações sobre o assunto podem ser vistas em [Morris, J.].

2.4 – Permissões de acesso e transição

Em resumo aos conceitos apresentados no capítulo 2.3 – Segurança baseada em contexto, mostram que políticas SELinux baseia-se nos atributos (label) dos sujeitos e objetos para definir as formas com que as ações são efetuadas no sistema.
O atributo mais importante em um sistema de políticas SELinux Type Enforcement é o tipo, que correlaciona objetos e sujeitos de forma a permitir o acesso de determinados sujeitos a objetos do mesmo tipo.
Um sujeito pode ser de vários tipos, ou então vários papéis, o que permite que ele agrupe diferentes tipos e desta forma possa transitar entre eles obtendo outras permissões de acesso a determinados objetos.
Tudo isso é definido na política que pode ser criada pelo administrador, e o que é definido não pode ser alterado por usuários comuns. As políticas, como visto anteriormente podem agir de diversas maneiras conforme a configuração selecionada no arquivo principal de configuração do SELinux (Targeted, Strict, MLS).
Na maioria das distribuições que implementam SELinux as políticas já vem compiladas e prontas pela equipe que mantem o desenvolvimento do SELinux, não sendo necessárias alterações por parte dos administradores a não ser em casos específicos.
Assim basta habilitar o SELinux no sistema, escolher o modo de funcionamento no arquivo principal de configuração e instalar as políticas para as aplicações que se deseja proteger.

3 – APLICANDO SELINUX

Para utilizar efetivamente SELinux no sistema algumas informações, configurações e comandos são importantes e este capítulo tem por objetivo demostrar de forma resumida os principais itens.
Os pacotes instalados e relevantes às demonstrações podem ser vistos na Figura 4 – Pacotes SELinux instalados.

Figura 4 – Pacotes SELinux instalados

3.1 – Políticas

Para ilustrar a teoria apresentada sobre as políticas, como elas trabalham com o contexto dos objetos e sujeitos, e também a complexidade de sua construção, será demonstrado abaixo um trecho do arquivo de políticas que protege o funcionamento do servidor ftpd.
Os trechos destacados mostram respectivamente a construção de segmentos da política na qual é possível observar a definição das permissões para que o processo ftpd possa criar sockets e gerenciar diretórios e aquivos do mesmo tipo (ftpd_*_t).

Figura 5 – Pacotes SELinux instalados

3.2 – Variáveis booleanas

Analisando a Figura 5 – Política SELinux para ftpd é possível observar que as regras que constroem uma política SELinux podem possuir certar complexidade e que alterá-las para que se adéqüem a necessidades específicas do sistema podem não ser uma tarefa fácil.
Para evitar que o administrador tenha que fazer essas alterações e posteriormente recompilar e atualizar as políticas, foram criadas variáveis booleanas para alterar algumas características mais comuns nos serviços protegidos pelas políticas.
Então, variáveis booleanas podem ser “ligadas” e “desligadas” sempre que se desejar alterar algumas dessas características. Por exemplo, por padrão a política SELinux para o serviço ftpd não permite que os usuários FTP leiam ou gravem em seus próprios home_dirs sendo necessário ativar esta característica caso desejada (o que geralmente é feito).
Se não existisse a possibilidade de utilizar variáveis booleanas para alterar o comportamento da política, seria necessário alterar o código fonte da política para promover a permissão desejada. Porém, com o uso do comando setbool -P ftp_home_dir 1 altera-se o comportamente para política para permitir que usuários FTP efetuem operações de leitura e escrita em seu homedir.

3.3 – Comandos e configurações úteis

Alguns comandos e configurações são de primeira necessidade para que se possa começar a utilizar SELinux para melhorar a segurança de um sistema.
O objetivo deste capítulo não é se tornar um manual de comandos SELinux, mas sim citar sua existência e funcionalidades básicas. Para mais opções e funcionalidades de cada comando, a consulta ao manual deve ser feita através do comando man .

3.3.1 – Arquivo principal de configuração SELinux

Primeiramente existe a necessidade de se conhecer o arquivo principal de configuração do SELinux, que apensar de pequeno, diz a maneira com que este irá se comportar e atuar com as políticas. Este arquivo está localizado em /etc/selinux/config e a Figura 5 – Aquivo principal de configuração SELinux mostra seu conteúdo.

Figura 6 – Arquivo principal de configuração SELinux

Neste momento pode-se observar as duas principais variáveis de configuração do SELinux, que controlam o modo de funcionamento e tipo de política a ser utilizado, SELINUX e SELINUXTYPE respectivamente.
A variável SELINUX indica o estado de funcionamento do SELinux no sistema, ou seja, se ele está ou não habilitado, e se sim como ele irá atuar sobre as restrições impostas pelas políticas.
- Enforcing, faz com que o SELinux, além de criar entradas de log bloqueie qualquer operação não previamente permitida na política.
- Permissive, não bloqueia operações de acesso, apenas cria entradas de log das mesmas. Pode ser útil para depurar o funcionamento do SELinux no sistema e providenciar alterações nas políticas antes de bloquear as ações.
- Disabled, desabilita por completo o funcionamento do SELinux no sistema.

3.3.2 – Comandos de status

Alguns comandos podem ser úteis para verificar o funcionamento ou mostrar características de configurações do SELinux.
- sestatus
Útil para coletar informações sobre o sistema rodando SELinux, mostra informações como o estado do SELinux, diretório onde está montado o sistema de arquivos do SELinux, tipo e versão das políticas, etc.
Para listar as variáveis booleanas e seus valores basta utilizar a opção -b com o sestatus.
- semodule -l
Semodule é uma ferramenta utilizada para gerenciar os módulos de políticas do SELinux, com a opção -l lista todos os módulos de políticas carregados pelo sistema.
- selinuxenabled
Este comando pode apresentar comportamento curioso quando simplesmente executado em um terminal, pois não retorna nenhum dado na saída padrão. Porém ao executá-lo ele verifica se o SELinux está ativado e retorna 1 se sim e 0 se não, o que o torna um comando muito útil para ser utilizado em scripts.
- ls -Z
ls não é um comando SELinux, porém possui uma extenção para exibir os labels SELinux dos aquivos (objetos) de um diretório. Isso pode ser muito útil na auditoria de logs ou bloqueios do SELinux.
- ps -Z
A extensão -Z também faz com que o comando ps exiba labels SELinux, porém não de objetos mas sim dos processos (sujeitos) em execução no sistema.

3.3.3 – Comandos de interação

Existem comandos e aplicações que permitem alterar não só o comportamento do SELinux mas também das políticas quando necessário.
O administrador pode querer alterar labels de objetos, editar políticas, carregar ou descarregar novos módulos de políticas, etc. Para isso os comandos a seguir podem ser úteis.
- chcon
Altera o contexto de segurança de um arquivo (objeto), por exemplo, utilizando o chcon é possível alterar a identidade, papel ou tipo do objeto.
A opção -u altera a identidade, “chcon -u user_u /etc/passwd”, -r altera o papel e -t o tipo dentro de um contexto.
- semanage
O semanage é uma ferramenta que tem por finalidade gerenciar políticas de um sistema de segurança SELinux. Com ele é possível alterar certos elementos da política sem a necessidade de modificar ou recompilar a política.
Ao logar no sistema com SELinux, o usuário recebe características referentes aos papéis que ele pode desempenhar no sistema. Isto é feito mapeando os usuários locais do sistema para identidade SELinux. Por exemplo, por padrão todos os usuários diferentes de root são mapeados para user_u que infere o mínimo de privilégios ao usuário.
Supondo que se deseja fazer com que o usuário teste logue no sistema e seja mapeado com identificador staff_u para obter alguns privilégios administrativos, utiliza-se o comando “semanage login -a -s staff_u teste”.
Com o semanage é possível alterar muitas outras características das políticas, o manpage do comando pode ser consultado para demais opções.
- setenforce
É possível mudar em tempo real, sem editar o arquivo principal de configuração do SELinux e sem reiniciar o sistema, a forma com que o SELinux trata as restrições impostas pelas políticas.
Executar “setenforce 0” coloca o SELinux em modo permissivo, apenas gerando logs das restrições, “setenforce 1” muda o tipo do SELinux para enforcing, bloqueando efetivamente as ações.
- setsebool
Como visto em 3.2 – Variáveis booleanas o comando setsebool permite alterar os valores binários de variáveis utilizadas pelas políticas para permitir ou não determinadas ações.

- semodule
Citado em 3.3.2 – Comandos de status semodule é utilizado para gerenciar os módulos de políticas SELinux, desta forma além de listas os módulos carregados, é possível adicionar novas políticas ou então remover módulos indesejáveis.
Para adicionar um novo módulo pode ser utilizado o comando “semodule -i httpd.pp” ou então para remover “semodule -r httpd”.

4 – CONCLUSÃO

Fica claro observar que o modelo de segurança MAC vem complementar as fragilidades que o convencional DAC possui, deixando o sistema mais seguro para ser utilizado principalmente no ambiente da Internet.
Nas primeiras implementações do SELinux, os usuários se deparavam com problemas de funcionamento devido ao modelo de implantação escolhido, onde as políticas eram estritas e dificultavam a utilização do sistema para a maioria.
O problema foi contornado com a alteração do tipo padrão de políticas, fazendo com que seja opcional a proteção de determinadas aplicações e também opcional o uso da política estrita. Se o usuário assim preferir pode alterar o comportamento das políticas para estrito.
Esta primeira atitude foi fundamental para que os administradores pudessem passar a usar o SELinux em seus servidores, e com isso novos artigos e how-tos surgiram facilitando cada vez mais sua implementação.
É fato que criar ou personalizar políticas é uma tarefa árdua, porém os desenvolvedores do SELinux já disponibilizam as políticas necessárias prontas para a maioria dos ambientes. As ferramentas que o acompanham facilitam a depuração e refinamento das políticas, viabilizando seu uso em diversos servidores.
Desta forma, relacionando complexidade / segurança a utilização do SELinux é certamente recomendada quando possível de ser utilizada.

REFERÊNCIAS BIBLIOGRÁFICAS

________Página oficial do SELinux. Disponível em:http://www.nsa.gov/selinux/ Acesso em: 20 de Novembro de 2008.

________Introdução ao SELinux. Disponível em: http://www.ha-mc.org/?q=node/22 Acesso em: 20 de Novembro de 2008.

________Red Hat SELinux Guide. Disponível em: – http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/ Acesso em 20 de Novembro de 2008.

Wikipedia. Discretionary Access Control. Disponível em: http://en.wikipedia.org/wiki/Discretionary_access_control Acesso em: 23 de Novembro de 2008.

Wikipedia. Mandatory Access Control. Disponível em: http://en.wikipedia.org/wiki/Mandatory_access_control Acesso em: 23 de Novembro de 2008.

________, Trusted Computer System Evaluation Criteria (Orange Book). Disponível em: http://www.boran.com/security/tcsec.html#C Acesso em: 30 de Novembro de 2008.

Smalley S. Flux Advanced Security Kernel. Disponível em: http://www.cs.utah.edu/flux/fluke/html/flask.html Acesso em: 5 de Dezembro de 2008.

________, Gentoo SELinux Overview. Disponível em: http://www.gentoo.org/proj/en/hardened/selinux/selinux-handbook.xml?part=3&chap=1#doc_chap1 Acesso em: 5 de Dezembro de 2008.

________, Fedora SELinux Project Pages Disponível em:http://fedoraproject.org/wiki/SELinux Acesso em: 5 de Dezembro de 2008.

Wikipedia, Multilevel Security Disponível em: http://en.wikipedia.org/wiki/Multilevel_security Acesso em: 5 de Dezembro de 2008.

________, Red Hat Enterprise Linux 4 / Fedora Core 4 Selinux Commands Disponível em: http://fedoraproject.org/wiki/SELinux/Commands Acesso em: 10 de Dezembro de 2008.

Os dispositivos wireless de modo geral apresentam configurações diversificadas, que podem muitas vezes ser classificas como básicas em se tratando de SSID, frequência de operação (canal), modo de operação (AP, Station, WDS), etc.
Porém, existem parâmetros que muitas vezes são desconhecidos pelos usuários ou mesmo pelos administradores da rede, e tais parâmetros podem, em alguns casos, solucionar diversos problemas de forma rápida e eficaz.
Aqui serão abordadas as configurações avançadas de maior relevância na solução de problemas que venham a ocorrer em redes wireless, com o objetivo de proporcionar alternativas de fácil acesso, encontradas nos próprios equipamentos instalados, sem ser necessária a adição de novos dispositivos.

VELOCIDADE DE TRANSMISSÃO (TRANSMITION RATE)

Esta opção, também encontrada como transmition rate, txrate ou bitrate indica a velocidade com que os bits serão transmitidos no meio, ou seja, a taxa de transmissão que o equipamento vai operar dentro da rede.
É importante observar que esta configuração não garante a taxa de transmissão efetiva da rede Wireless, ou seja, fatores como quantidade de sinal, interferências, ACK timeout e outros terão influência direta no desempenho da rede.
Na maioria dos casos a velocidade de transmissão é definida em megabits por segundo, podendo ter os valores fixos de 1, 2, 5.5 e 11 Mbps para 802.11b e 6, 9, 12, 18, 24, 36, 48 e 54 Mbps para 802.11g e 802.11a ou também ser configurada de forma automática, onde a velocidade definida será a melhor detectada pelo dispositivo para operar no meio onde está instalado.
Uma dica para configurar este parâmetro é utilizar valores automáticos e garantir que a qualidade de sinal seja suficiente para manter sempre a maior taxa de transmissão possível.
Para enlaces de longa distância, onde oscilações de sinal possam ocorrer com maior intensidade, aconcelha-se utilizar txrate fixos para evitar que o equipamento tenha que negociar novas taxas de transferência em curtos períodos de tempo, causando instabilidade na rede.

POTÊNCIA DE TRANSMISSÃO (TRANSMITION POWER)

Também encontrada como txpower ou power level esta opção permite alterar a potência de saída do equipamento, fazendo desta forma com que o mesmo irradie com mais ou menos intensidade de sinal.
Alterar parâmetros de potência podem influenciar também na sensibilidade do equipamento, que é a capacidade de receber (escutar) sinais irradiados por outros, por isso ao contrário do que muitos imaginam, reduzir a potência pode fazer com que o equipamento se torne menos susceptível a interferências melhorando a qualidade do enlace.
Para esta opção os valores são geralmente definidos em dBm , miliwatts, ou porcentagem.

TEMPO DE ACEITAÇÃO (ACK TIMEOUT)

ACK timeout pode ser definido como o tempo que um nó ou estação vai aguardar para receber pacotes do tipo ACK.
Pacotes ACK indicam que uma determinada transmissão efetuada por um nó A para um nó B foi recebida com sucesso por B, ou seja, se A não receber um ACK de B uma retransmissão irá ocorrer.
Para saber se deve e quando deve retransmitir um dado pacote, A deve aguarda por um tempo determinado um ACK de B. Se o pacote ACK expirar o tempo definido (timeout) a estação A que efetuou a transmissão entenderá que o pacote se perdeu e fará uma retransmissão.
Relacionando isso com o desempenho da rede, definir valores de ACK timeout muito altos fará com que a estação A espere muito tempo até retransmitir uma informação que foi realmente perdida, o que acarreta em perda de desempenho. Porém valores muito baixos podem fazer com que a estação retransmita desnecessariamente pacotes que não foram verdadeiramente perdidos, também afetando o desempenho da rede.

Como definir o ACK timeout ideal?
Alguns equipamentos trazem esta opção como sendo a distância em metros entre os nós, e calcula automaticamente os valores de ACK timeout baseando-se na distância. Outros possuem algorítmos que testam perdas e retransmissões de pacotes por ACK timeout e regulam o tempo de espera por ACKs dinamicamente, sem a necessidade de intervenção do usuário.
Em muitos casos, quando os recursos descritos acima não estão disponíveis ou mesmo na tentativa de refinar os valores de ACK timeout, pode ser interessante a configuração manual, iniciando-se com valores mais altos e reduzindo pouco a pouco, tentando em paralelo o throughput da rede.

INTERVALO DE BEACON (BEACON INTERVAL)

Beacon em redes wi-fi é definido como sendo um tipo de frame de gerenciamento responsável por permitir que estações estabelessam e mantenham conexão com um AP. [Jim Geier – Wi-fi Planet, 2002].
O intervalo de beacons define qual o tempo entre as retransmissões dos beacons. Aumentar o intervalo de beacons irá dimunuir a quantidade de beacons na rede, dimunuir o intervalo de beacons fará com que mais destes estejam em trânsito na rede.
E quais características, na prática, serão influenciadas?
Aumentando o intervalo entre beacons, estações podem demorar para se associarem a um Access Point, pois deverão aguardar um beacon do AP que o identifique. Isso pode não ser desejável em uma rede onde estações façam roaming constantemente.
Reduzindo o intervalo de beacon, mais transmissões de beacons serão efetuadas pelo AP e consequentemente a associação de estações será mais rápida, porém mais recursos de banda serão consumidos influenciando o throughput da rede.
Existe também uma relação dos beacons com o modo de economia de energia dos adaptadores wireless.
Quando o adaptador encontra-se no modo de economia de energia, o AP utiliza os beacons para informar que existem informações em buffer destinadas a esta estação. Neste caso, utilizar intervalos baixos para emissão de beacons refletirá em uma menor economia de energia por parte das estações, pois estas serão “acordadas” com mais frequência para receber dados.

LIMIAR DE FRAGUIMENTAÇÃO (FRAGMENTATION THRESHOLD)

É o tamanho máximo que um pacote pode ter para  que seja transmitido sem ser fraguimentado. Se o pacote for maior que o tamanho definido ele será fraguimentado e transmitido partes.
Esta opção aceita valores em bytes geralmente de 256 a 2346 e é encontrada nos equipamentos como fragmentation threshold, geralmente com o valor padrão de 2346, o que signifca que o recurso de fraguimentação está desativado.

Quando e como usar fraguimentação?
Uma opção para melhorar o desempenho de uma rede wireless é o uso de fraguimentação.
Em redes congestionadas, com muitos clientes, colisões poderão ocorrer em meio as transmissões, e isso consequentemente afetará o desempenho da rede.
Quanto maior for a porção de informações que uma estação esteja transmitindo no momento de uma colisão, maior será o desperdício do meio com dados corrompidos, e neste caso usar o recurso de fraguimentação pode ser uma alternativa para solucionar ou amenizar o problema.
Porém,  antes é importante observar a porcetagem de colisões que estão ocorrendo, tendo em vista que fraguimentar pacotes aumenta o consumo de banda da rede, podendo assim não surtir o efeito esperado.

Se existirem mais do que 5% (cinco por cento) de colisões em sua rede o uso de fraguimentação já pode ser testado. Comece com um valor aproximado de 1000 bytes na configuração fragmentation threshold e vá alterando aos poucos para mais ou menos, afim de conseguir o melhor resultado, sempre observando é claro a porcentagem de colisões e throughput da rede.

RTS / CTS

O padrão 802.11 pode disponibilizar em alguns equipamentos a feature RST/CTS que define um método de controle de acesso ao meio para as estações conectadas em um Access Point, quando estas desejam trasmitir dados.
É sabido que se duas estações tentarem transmitir ao mesmo tempo, uma colisão irá ocorrer e isto tem ação direta no desempenho de uma rede, reduzindo o throughput.
Desta forma o uso do recurso RTS / CTS pode ser uma alternativa para resolver problemas de colisão, inclusive de forma mais eficiente do que o uso de fraguimentação, tendo em vista que o consumo da rede com informações de cabeçalhos é menor.
Um problema comum em redes sem fio é o caso do “nó escondido”, onde duas estações A e B não conseguem detectar a existencia uma da outra, devido a problemas de atenuação de sinal ou mesmo obstáculos, mas ambas conseguem se comunicar com o Access Point.
Neste caso, se A iniciar uma transmissão, B não tomara cohecimento da ação de A e poderá começar a transmitir a qualquer momento, causando uma colisão.
Quanto maior for a quantidade de dados que ambos estiverem transmitindo, maior será o tempo de colisão e consequentemente o desperdício do meio em transmitir informações corrompidas.

E como usar RTS / CTS para este caso?
Habilitando RTS / CTS nas estações, para que a estação A inicie sua transmissão ela enviará uma informação do tipo RTS (Read to send) para o Access Point, que irá responder com um CTS (Clear to send) informando que A pode começar sua transmissão.
O CTS enviado pelo AP para a estação A, contém uma quantidade de tempo aleatório que A poderá permanecer transmitindo e esta mesma informação também será enviada para  B (e para todas as outras estações), fazendo desta forma com que nenhuma outra estação comece a transmitir junto com A.
Como o controle é feito pelo Access Point, lembrando é claro que este deve suportar o recurso RTS / CTS, mesmo que as estações não possuam comunicação direta, impedida pelo problema do “nó escondido”, as colisões serão evitadas.
É importante observar que mesmo sendo mais eficiente para este caso do que o uso de fraguimentação, o uso de RTS / CTS também gera overhead. Por isso é aconcelhável medir o índice de colisão e avaliar a existência do problema do “nó escondido” antes de implementar o recurso.
Na maioria dos equipamentos, a opção para ativar o RTS nas estações é encontrada como RTS threshold, e define a quantidade em bytes que o pacote deve ter para que a estação faça um RTS para o AP solicitando a transmissão.
Os Access Points que suportam o recurso geralmente não precisam ser configurados, respondendo automanticamente a requisições do tipo RTS quando solicitadas pelas estações.

PREÂMBULO (PREAMBLE)

Preamble é pode ser definido como sendo um campo do cabeçalho de camada física do 802.11 (802.11 PHY) responsável por sincronizar transmissões entre os dispositivos, e a grosso modo pode ser visto com um período de tempo que é aguardado antes da transmissão de qualquer frame.
O que é importante saber, é que a implementação do preâmbulo longo (long preamble) o campo referente no cabeçalho é de 128 bits, o que faz com que seu overhead de transmissão seja maior, aumentando o intervalo entre a transmissão dos frames e reduzindo consequentemente o desempenho da rede.
O preâmbulo curto provem de uma implementação mais nova que utiliza um campo menor, de 56 bits, e por este motivo é transmitido mais rapidmente, reduzindo o intervalo de transmissão entre frames e aumentando o desempenho da rede.
O que é importante na configuração do preâmbulo?
Alguns dispositivos e adaptadores wireless mais antigos podem não suportar configurações de preâmbulo curto, e desta forma poderão ocorrer problemas de associação ou transmissão caso o Access Point esteja configurado para usar a configuração de preâmbulo curto.
Redes que contenham dispositivos deste tipo devem ser configuradas para usar preâmbulo longo, para aumentar a compatibilidade.
Em contrapartida o uso de preâmbulo curto em redes onde todos os dispositivos sejam compatívies pode propiciar ganho de desempenho.