Gregório Patriota Correia...Cada ﬁo de cabelo perdido e também cada novo ﬁo branco que ganhe, cada uma destas marcas mostram o quão loga foi a jornada. Agradeço também a quem

Gregório Patriota Correia

SECURE-COMPAPP: UMA ABORDAGEM PARA APLICAÇÕES

COMPARTIMENTALIZADAS

Dissertação de Mestrado

Universidade Federal de [email protected]

www.cin.ufpe.br/~posgraduacao

RECIFE2016

www.cin.ufpe.br/~posgraduacao


SECURE-COMPAPP: UMA ABORDAGEM PARA APLICAÇÕESCOMPARTIMENTALIZADAS

Trabalho apresentado ao Programa de Pós-graduação em

Ciência da Computação do Centro de Informática da Univer-

sidade Federal de Pernambuco como requisito parcial para

obtenção do grau de Mestre em Ciência da Computação.

Orientador: Djamel Fawzi Hadj Sadok

RECIFE2016

Catalogação na fonteBibliotecário Jefferson Luiz Alves Nazareno CRB 4-1758

C824s Correia, Gregório Patriota. Secure-compapp: uma abordagem para aplicações

compartimentalizadas / Gregório Patriota Correia. – 2016. 81f.: fig., tab.

Orientador: Djamel Fawzi Hadj Sadok. Dissertação (Mestrado) – Universidade Federal de Pernambuco. CIn.

Ciência da Computação, Recife, 2016. Inclui referências e apêndice.

1. Segurança de dados críticos. 2. Controle de acesso. 3.Comunicaçãointerprocesso. I. Sadok, Djamel Fawzi Hadj. (Orientador). II. Titulo.

005.8 CDD (22. ed.) UFPE-MEI 2016-154


Secure-CompApp: Uma Abordagem para Aplicações Compartimentalizadas

Dissertação apresentada ao Programa de Pós-

Graduação em Ciência da Computação da

Universidade Federal de Pernambuco, como

requisito parcial para a obtenção do título de

Mestre em Ciência da Computação.

Aprovado em: 29/07/2016

BANCA EXAMINADORA

__________________________________________________

Prof. Dr. Djamel Fawzi Hadj Sadok

Centro de Informática / UFPE

(Orientador)

___________________________________________________

Prof. Dr. Eduardo Luzeiro Feitosa

Instituto de Computação / UFAM

___________________________________________________

Prof. Dr. Rafael Roque Aschoff

Instituto Federal de Pernambuco / Campus Palmares

I dedicate this dissertation to all my family, friends and

professors who gave me the necessary support to get here.

Agradecimentos

Sou grato por todos esses anos nunca ter tido uma jornada solitário. Sempre alguém a meapoiar, motivar e criticar minhas atitudes. Família, amigos e companheiros, sempre me mostrandoa razão quando eu menos a enxergava. Encontrar a motivação necessária para continuar não éfácil. Mas todos que me cercavam sempre mostraram que a motivação que eu procurava teria devir de dentro de mim: "motivação vem de dentro e inspiração vem de fora". Família, amigos ecompanheiros foram a maior inspiração que precisei.

Agradeço primeiramente a Deus e a minha família: Pai, Mãe e irmãos. Sou muito gratoao meu grupo de trabalho e principalmente as orientações de: Djamel Sadok e Judith Kelner.As equipes com quem trabalhei. Os primeiros passos dados na antiga equipe SEFIN: ThiagoRodrigues, Josias Junior e Rodrigo Melo. A equipe SIRCAM: Ernani Azevedo, Marcos Machadoe Daniel Rosendo. Aos que não que não compartilharam projetos mas tiveram grande influência:Wesley Melo. Cada fio de cabelo perdido e também cada novo fio branco que ganhe, cada umadestas marcas mostram o quão loga foi a jornada.

Agradeço também a quem desde pequeno sempre me estimulou a estudar, minha avó.Jamais esquecerei quando ela me perguntava se "esse negócio de consertar computador dá

dinheiro?". Sou muito grato por todo o suporte que ela me deu e que muito me ensinou.Agradecimentos em memória de Isaura Barros Patriota.

Por fim, agradeço ao Grupo de Pesquisa em Redes e Telecomunicações (GPRT), aoConselho Nacional de Desenvolvimento Científico e Tecnológico (CNPq) e a UniversidadeFederal de Pernambuco (UFPE).

A todos o meu sincero muito obrigado.

"Mas nem sempre a fraqueza que se sente quer dizer que a gente não é forte"

—GABRIEL CONTINO

Resumo

O uso de códigos monolíticos permite com maior facilidade que um atacante consiga escalarprivilégios e a partir de então ter autoridade para executar qualquer tipo de ação maliciosa. OPrincípio da Separação de Privilégios propõem mitigar essas vulnerabilidades transformando aestrutura do código monolítico em uma estrutura distribuída que se comunica através de canaisinterprocessos, desta forma os domínios de cada parte estarão isolados dificultando a escalaçãode privilégios. Entretanto o uso incauto destes canais de comunicação interprocessos tem sidoalvo de novos ataques que exploram tanto as fraquezas dos canais de comunicação quanto asinterfaces mal definidas destes processos particionados. Como proposta de mitigar a escalação deprivilégio proveniente da exploração destes canais de comunicação este trabalho propõem umaferramenta de gerenciamento de processos compartimentalizados e seus canais de comunicaçãointerprocesso. A solução apresentada neste trabalho é chamada de Secure-CompApp. Foiavaliado o impacto da solução sobre a performance das aplicações compartimentalizadas e esteestudo mostra que a diminuição de performance é justificada por maiores garantias de segurançae rastreabilidade oferecida pela solução Secure-CompApp.

Palavras-chave: Segurança de Dados Críticos. Separação de Privilégio. Monitor de Referência.Políticas. Controle de Acesso. Comunicação Interprocesso

Abstract

Application with any kind of bug or any point with memory leak represent an opportunity foran attacker engage. In the case of some applications implemented with monolithic code, thisallows an attacker to escalate privileges of a user easily. The Principle of Least Privilege (PoLP)proposes to mitigate these vulnerabilities transforming the structure of the monolithic code in adistributed structure that communicate through interprocess channels, so the domains of eachpart will be isolated, making it difficult to privilege escalation. However the incautious useof these interprocess communication channels has been the target of new attacks that exploitthe weaknesses of communication channels and the ill-defined interfaces of these partitionedprocesses. As a proposal to mitigate the privilege escalation from the exploitation of thesecommunication channels this paper proposes a management tool for compartmentalized processesand its interprocess communication channels. The Secure-CompApp is a reference monitor forcompartmentalized applications, this is the solution introduced in this paper. The impact of thesolution on the performance of compartmentalized applications was evaluated and this studyshows that the decrease of performance is justified by the greater guarantees of security andtraceability offered by the Secure-CompApp.

Keywords: Critical Safety Data. Privilege Separation. Reference Monitor. Policies. AccessControl. Inter-process Communication

Lista de Figuras

1.1 Total de vulnerabilidades nos principais sistemas operacionais . . . . . . . . . 141.2 Total de Vulnerabilidades x Ganho de Privilégio nos sistemas operacionais Linux 151.3 Total de Vulnerabilidades x Ganho de Privilégio nos sistemas operacionais

Microsoft . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161.4 Aplicação de Principle of Least Privilege (PoLP) a um processo monolítico . . 17

2.1 Esquema de Confinamento de Aplicação com Sandbox . . . . . . . . . . . . . 222.2 Representação do Confused Deputy Attack . . . . . . . . . . . . . . . . . . . . 242.3 Representação do Collusion Attack . . . . . . . . . . . . . . . . . . . . . . . . 252.4 Análise de performance entre os métodos Inter-Process Communication (IPC)

dentro do Kernel Linux 2.2.5-15 ao enviar 5000 mensagens . . . . . . . . . . . 272.5 Diagrama de Classe do padrão Monitor de Referência . . . . . . . . . . . . . . 282.6 Diagrama de Sequência do padrão Monitor de Referência . . . . . . . . . . . . 29

4.1 Proposta de Secure-CompApp . . . . . . . . . . . . . . . . . . . . . . . . . . 414.2 Estrutura do Secure-CompApp . . . . . . . . . . . . . . . . . . . . . . . . . . 424.3 Abstração do Secure-CompApp . . . . . . . . . . . . . . . . . . . . . . . . . 454.4 Máquina de estado do Servidor . . . . . . . . . . . . . . . . . . . . . . . . . . 464.5 Máquina de estado do Cliente . . . . . . . . . . . . . . . . . . . . . . . . . . . 464.6 Formato da mensagem de requisição do processo ao monitor de referência . . . 474.7 Formato da mensagem de resposta do monitor de referência ao processo . . . . 474.8 Formato da mensagem trocada entre os processos . . . . . . . . . . . . . . . . 484.9 Estrutura organizacional do Organization-based Access Control (OrBAC) . . . 50

5.1 Regras criadas na ferramenta MotOrBAC para o cenário 01 . . . . . . . . . . . 575.2 Cenário simples com a solução Secure-CompApp . . . . . . . . . . . . . . . . 575.3 Cenário simples sem a solução Secure-CompApp . . . . . . . . . . . . . . . . 585.4 Cenário extenso com a solução Secure-CompApp . . . . . . . . . . . . . . . . 595.5 Regras criadas na ferramenta MotOrBAC para os cenários estendidos . . . . . 60

6.1 Análise de tempo do protocolo de bootstrap . . . . . . . . . . . . . . . . . . . 626.2 Análise das etapas que compõem o bootstrap . . . . . . . . . . . . . . . . . . 626.3 Análise de tempo do protocolo de handshake . . . . . . . . . . . . . . . . . . 646.4 Análise de delay das mensagens . . . . . . . . . . . . . . . . . . . . . . . . . 656.5 Análise das etapas delay das mensagens . . . . . . . . . . . . . . . . . . . . . 666.6 Arquivo de log com as ocorrências de fluxo não permitido . . . . . . . . . . . 686.7 Arquivo de log com aviso de par de regras que permitem a transitividade . . . . 69

Lista de Tabelas

2.1 Métodos IPCs mais usados . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262.2 Esquemas de Controle de Acesso . . . . . . . . . . . . . . . . . . . . . . . . . 29

5.1 Parâmetros de simulação no cenário da Figura 5.2 . . . . . . . . . . . . . . . 565.2 Parâmetros de simulação para avaliação do delay das mensagens nos cenários

das Figuras 5.2 e 5.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 585.3 Parâmetros de simulação para avaliação da escalabilidade no cenário da Fi-

gura 5.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

6.1 Estatísticas do bootstrap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 616.2 Estatísticas do bootstrap: etapa de geração do par de chaves . . . . . . . . . . 636.3 Estatísticas do bootstrap: etapa do esquema de políticas . . . . . . . . . . . . . 636.4 Estatísticas do bootstrap: etapa de abertura do canal de comunicação . . . . . . 636.5 Estatísticas do protocolo de handshake com Secure-CompApp . . . . . . . . . 646.6 Estatísticas do protocolo de handshake sem Secure-CompApp . . . . . . . . . 646.7 Estatísticas de delay das mensagens com Secure-CompApp . . . . . . . . . . . 656.8 Estatísticas de delay das mensagens sem Secure-CompApp . . . . . . . . . . . 656.9 Taxa média de perda de pacotes em cenários extensos . . . . . . . . . . . . . . 67

Lista de Acrônimos

ACL Access Control List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

AOSP Android Open Source Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34

API Application Program Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

CVE Common Vulnerabilities and Exposures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

DAC Discretionary Access Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .49

DoS Denial of Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

DHCP Dynamic Host Configuration Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

GID Group Identifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

ICC Inter-Component Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

IDS Intrusion Detection System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

IMEI International Mobile Station Equipment Identity . . . . . . . . . . . . . . . . . . . . . . . . . . 35

IPC Inter-Process Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

JNI Java Native Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

JVM Java Virtual Machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

MAC Mandatory Access Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

MACE Mining Access Control Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

MTL Metric Temporal Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

OrBAC Organization-based Access Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

PID Process Identifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

PoLP Principle of Least Privilege . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

RBAC Role-based Access Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

RPC Remote Procedure Call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

RSA Rivest-Shamir-Adleman . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

UID User Identifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

XACML eXtensible Access Control Markup Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

Sumário

1 Introdução 14

2 Conceituação 192.1 Privilégios e a Vulnerabilidade de Ganho de Privilégio . . . . . . . . . . . . . 192.2 Escalação de Privilégios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.2.1 Escalação Vertical de Privilégios . . . . . . . . . . . . . . . . . . . . . 202.2.2 Escalação Horizontal de Privilégios . . . . . . . . . . . . . . . . . . . 20

2.3 Princípio de Privilégios Mínimos . . . . . . . . . . . . . . . . . . . . . . . . . 202.3.1 Paradigmas de Linguagens Object-Capability . . . . . . . . . . . . . . 212.3.2 Confinamento da Aplicação . . . . . . . . . . . . . . . . . . . . . . . 212.3.3 Separação de Privilégios . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.4 Ataques de Escalação de Privilégios . . . . . . . . . . . . . . . . . . . . . . . 232.4.1 Confused Deputy Attacks . . . . . . . . . . . . . . . . . . . . . . . . . 242.4.2 Collusions Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.5 Comunicação entre Processos . . . . . . . . . . . . . . . . . . . . . . . . . . . 252.6 Padrão de Projeto Seguro Monitor de Referência . . . . . . . . . . . . . . . . 272.7 Modelos de Controle de Acesso . . . . . . . . . . . . . . . . . . . . . . . . . 292.8 Recapitulação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3 Estado da Arte 313.1 Trabalhos Relacionados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.1.1 Separação de Privilégio em Web Services . . . . . . . . . . . . . . . . 313.1.2 Separação de Privilégio em Android . . . . . . . . . . . . . . . . . . . 323.1.3 Separação de Privilégio em Desktop . . . . . . . . . . . . . . . . . . . 35

3.2 Discussão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373.3 Recapitulação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4 Proposta 404.1 Estrutura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404.2 Contramedidas aos Ataques . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434.3 Prova de Conceito . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

4.3.1 Módulo Monitor de Referência . . . . . . . . . . . . . . . . . . . . . . 454.3.2 Módulo de Controle de Processos . . . . . . . . . . . . . . . . . . . . 494.3.3 Módulo de Gerenciamento de Políticas de Controle de Acesso . . . . . 494.3.4 Módulo de Criptografia . . . . . . . . . . . . . . . . . . . . . . . . . . 504.3.5 Módulo de Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

13

4.4 Discussão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524.4.1 Vantagens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524.4.2 Desvantagens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

4.5 Recapitulação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

5 Avaliação 545.1 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

5.1.1 Ambiente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 545.1.2 Métricas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

5.1.2.1 Tempo de bootstrap . . . . . . . . . . . . . . . . . . . . . . 555.1.2.2 Tempo de handshake . . . . . . . . . . . . . . . . . . . . . 555.1.2.3 Tempo de delay . . . . . . . . . . . . . . . . . . . . . . . . 555.1.2.4 Escalabilidade . . . . . . . . . . . . . . . . . . . . . . . . . 555.1.2.5 Contramedidas aos Ataques . . . . . . . . . . . . . . . . . . 56

5.1.3 Cenário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

6 Resultados 616.1 Bootstrap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 616.2 Handshake . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 646.3 Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 656.4 Escalabilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 676.5 Redução de ataques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

6.5.1 Confused Deputy Attack . . . . . . . . . . . . . . . . . . . . . . . . . 686.5.2 Collusion Attack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

6.6 Discussão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 696.7 Recapitulação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

7 Conclusão 727.1 Contribuições . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 737.2 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

Referências 75

Apêndice 79

A Dificuldades Encontradas 80A.1 Gerenciamento de Threads . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80A.2 Gerenciamento de canais IPC . . . . . . . . . . . . . . . . . . . . . . . . . . . 80A.3 Modelo de Controle de Acesso . . . . . . . . . . . . . . . . . . . . . . . . . . 81

141414

1Introdução

Atualmente está cada vez mais acessível aos usuários dispositivos compactos com altopoder de processamento. A indústria de hardware tem crescido bastante e com isto alavancandojunto a indústria de software. Esta alta acessibilidade e o alto poder de processamento dosdispositivos deram margem para o desenvolvimento de aplicações mais robustas, provendoassim uma variedade de serviços aos usuários. Entretanto, além das vantagens agregadas,estas aplicações têm estado mais expostas a vulnerabilidades e isto tem levantado grandespreocupações com a segurança destes dispositivos e das suas aplicações.

O Common Vulnerabilities and Exposures (CVE) é um sistema que detém uma basede dados com as ameaças e vulnerabilidades catalogadas. Esta entidade tem apontado paraum aumento significativo das vulnerabilidades que intentam a segurança tanto dos sistemasoperacionais baseado em Microsoft (CVE, 2015a) quanto os sistemas operacionais baseado emLinux (CVE, 2015b).

Figura 1.1: Total de vulnerabilidades nos principais sistemas operacionais

Fonte: Adaptado de CVE (2015b) e CVE (2015a)

A Figura 1.1 nos mostra a quantidade de vulnerabilidades por ano dos dois principaissistemas operacionais lado a lado, estes valores foram coletados de 1999 até Julho de 2016.

15

Através da leitura deste gráfico é possível observar pequenas oscilações nas quantidades devulnerabilidades ao longo dos anos que tem apontado para um crescimento no total de vulnerabi-lidades. Isto é perceptível pelo montante de vulnerabilidades presentes nos primeiros anos (entreos anos de 1999 e 2001) ser inferior ao montante de vulnerabilidades presentes nos últimos anos(entre os anos de 2013 e 2015).

Há um conjunto de ferramentas que visam mitigar estas vulnerabilidades relatadas,ferramentas estas como por exemplo: Intrusion Detection Systems (IDSs), Firewalls e Antivírus.Os Antivírus (Chionis; Nikolopoulos; Polenakis, 2013) e os IDSs (Ashoor; Gore, 2011) possuemum esquema de detecção baseado na assinatura da anomalia, sendo então eficientes para combatermalwares previamente conhecidos nos hospedeiros. Além disto, os IDS também podem combaterestes malwares com base na análise de um comportamento anômalo. Já os Firewalls (Wool,2004) são definidos como o pilar da segurança das intranets corporativa.

Contudo, estas ferramentas citadas não possuem grande eficiência em situações quea falha está dentro da própria aplicação, como por exemplo: bugs e vazamento de memória.A vulnerabilidade de Ganho de Privilégio é proveniente de falhas como estas que permitemo vazamento de informações ou comprometam o funcionamento do resto da aplicação. Estavulnerabilidade permite que seja executado um ataque de escalação de privilégio, onde o atacanteconsegue ter acesso não autorizado a um conjunto de privilégios (Provos; Friedl; Honeyman,2003). No pior dos casos podendo escalar privilégios de administrador do sistema.

O CVE nos mostra também que a vulnerabilidade de ganho de privilégio está semprepresente nos sistemas operacionais Linux (Figura 1.2) e Microsoft (Figura 1.3) ao longo dosanos.

Figura 1.2: Total de Vulnerabilidades x Ganho de Privilégio nos sistemas operacionaisLinux

Fonte: CVE (2015b)

De acordo com a base de dados do CVE as vulnerabilidades de ganho de privilégiocorrespondem a cerca de 10% do total de ameças catalogadas. O ponto mais crítico com relação

16

Figura 1.3: Total de Vulnerabilidades x Ganho de Privilégio nos sistemas operacionaisMicrosoft

Fonte: CVE (2015b)

a esta vulnerabilidade são os danos que ela pode vir a causar, pois um ataque bem sucedido aeste tipo de vulnerabilidade pode comprometer todo o sistema operacional do hospedeiro.

Contra este tipo de vulnerabilidade é aplicado o Principle of Least Privilege (PoLP)(Saltzer; Schroeder, 1975). Este princípio relata que cada ação deve receber o mínimo deprivilégio necessário para que possa ser executado sem comprometer a integridade de qualqueroutra ação que execute no mesmo ambiente. Ele não só aumenta a segurança contra ataques demalwares mas também protege o resto do sistema contra bugs e vazamentos de dados dentro daaplicação.

O PoLP separa os privilégios de uma aplicação dentro de domínios isolados. Assim cadadomínio detém um conjunto reduzido de privilégios que passam a ser interligados via canais decomunicação (Gukda et al., 2012).

Por exemplo (Figura 1.4), há uma aplicação que detém uma estrutura monolítica, ouseja, ela aglomera em uma mesma região de memória todas as ações, recursos e privilégiosda aplicação. Ao aplicar o PoLP os domínios de cada privilégio passam a ficar isolados dasdemais ações, ficando confinados em partes (compartimentos) distintas. A aplicação desteprincípio classifica as partes como: a parte privilegiada e a parte não privilegiada (Provos; Friedl;Honeyman, 2003). É possível aumentar a granularidade da separação e isolar cada vez mais ummenor conjunto de privilégios por mais partes (compartimentos), conforme pode ser visto naFigura 1.4.

Devido a sua importância contra ataques de escalação de privilégios, há muitos trabalhosna literatura que focam em ferramentas automatizadas para a aplicação do PoLP. Como exemplohá uma ferramenta que mostra conseguir minimizar os privilégios de uma aplicação a 22%(Wu et al., 2013). Todavia, alguns autores tem alertado sobre os problemas associados acompartimentalização das aplicações.

17

Figura 1.4: Aplicação de Principle of Least Privilege (PoLP) a um processo monolítico

Fonte: Do autor

Em (Gukda et al., 2012) é exposto que aplicações mais compartimentalizadas (maiornível de granularidade) impõem dificuldades nas fases de desenvolvimento, depuração e manute-nibilidade do software. Além disto, há vulnerabilidades que podem comprometer a aplicaçãodevido ao uso incauto dos canais de comunicação (Trapp; Rossberg; Schaefer, 2015).

O CVE apontou nos últimos anos o surgimento de ataques de escalação de privilégio queocorreram através de canais de comunicação (CVE, 2011a,b, 2013, 2015c). Este uso incauto decanais de comunicação também é salientado por (Bugiel et al., 2012) que apontou dois ataquesdesenhados contra aplicações que implementam o PoLP: Confused Deputy Attack (Hardy, 1988)e Collusion Attack (Marforio et al., 2011). Sendo o Confused Deputy Attack um ataque queexplora falhas nas interfaces de comunicação (interfaces confusas) de aplicações privilegiadas.Enquanto que o Collusion Attack trata-se de ataque onde o encadeamento de várias permissõespossibilita o atacante executar ações além dos seus privilégios individuais. Ambos os ataquesvisam explorar falhas através das interfaces de comunicação.

Ou seja, o PoLP visa mitigar os ataques de escalação de privilégio, entretanto o uso des-cuidado dos canais de comunicação entre as partes acabou gerando outro ponto de falha. Assim,este trabalho tem como foco mitigar os ataques provenientes das interfaces de comunicação.

Esta proposta está caucada no princípio da execução monitorada (Buyens; De Win;

18

Joosen, 2009). Ela foi chamada de Secure-CompApp e constitui um método para estruturaçãode uma aplicação compartimentalizada que visa mitigar os ataques de escalação de privilégiodecorrentes das interfaces de comunicação.

O principal objetivo deste trabalho é mitigar os ataques de escalação de privilégio, ata-ques estes que advém de falhas nos canais de comunicação das aplicações compartimentalizadas.Foi proposto o uso de um elemento intermediário entre os processos de uma aplicação comparti-mentalizada, sendo este elemento capaz de interceptar as interações destes processos e operarcomo um elemento de controle de acesso.

Este elemento centralizado atua como um monitor de referência dedicado à uma aplicaçãocompartimentalizada. Sua principal função é de gerenciar os canais de comunicação estabelecidosentre os processos de uma aplicação, além disto ele também fica incumbido de garantir segurançaàs interfaces, aos dados trocados e aos processos compartimentalizados.

Esta dissertação está estrutura de forma que no Capítulo 2 disserta-se sobre os conceitosda área de pesquisa. O Capítulo 3 traz o estado da arte e em seguida o Capítulo 4 discorre sobrea solução proposta, além de detalhar sobre a ferramenta desenvolvida como prova de conceito daproposta. O Capítulo 5 apresenta a metodologia do trabalho seguido pelos resultados coletadosno Capítulo 6. As considerações finais são apresentadas no Capítulo 7.

191919

2Conceituação

Primeiramente neste capítulo serão descritos os conceitos mais importantes da área deseparação de privilégio, conceitos estes fundamentais para o entendimento da aplicação do PoLP.

Em seguida serão descritos conceitos que fundamentaram a solução Secure-CompApp,conceitos como o do padrão de segurança monitor de referência, modelos de controle de acessoe canais de comunicação inter-processos.

2.1 Privilégios e a Vulnerabilidade de Ganho de Privilégio

Privilégio é definido (Provos; Friedl; Honeyman, 2003) como um atributo de segurançaque é requisitado por alguma operação. Assim, os privilégios concedidos são como limitantes deacesso que um usuário pode ter a arquivos ou códigos, por exemplo. Um privilégio não é algoúnico e pode ser usado por várias entidades.

Já uma vulnerabilidade é definida como a intersecção de três elementos: a falha nosistema, o acesso do atacante a falha e a capacidade do atacante explorar a falha (Chen; Tian,2015). Assim, uma vulnerabilidade de ganho de privilégio é um ponto de falha que permite queum usuário não autêntico tenha acesso de forma não autorizada a um conjunto de privilégios.

2.2 Escalação de Privilégios

Escalação de Privilégio é um tipo de ataque em que o invasor obtém privilégios perten-centes a outro usuário, com o objetivo de adquirir maiores níveis de privilégios. Ele visa obteracesso a recursos que seriam por padrão protegidos de um conjunto de usuários ou aplicações,seja por meio de vulnerabilidades em softwares em execução ou até mesmo no próprio sistemaoperacional.

Há duas possíveis classificações para ataques de escalação de privilégios (Monshizadeh,2014): Escalação Vertical e Escalação Horizontal.

2.3. PRINCÍPIO DE PRIVILÉGIOS MÍNIMOS 20

2.2.1 Escalação Vertical de Privilégios

Também conhecido como Elevação de Privilégio, ocorre quando um usuário (ou processo)de menor privilégio no sistema tem acesso a recursos alocados exclusivamente para um usuário(ou processo) de maior privilégio no sistema. Em um pior cenário o atacante pode escalar osprivilégios de administrador do sistema (root), tendo assim controle total sobre o hospedeiro epodendo instalar rootkits ou até modificar funções de mais baixo nível do sistema.

2.2.2 Escalação Horizontal de Privilégios

Uma escalação horizontal de privilégio ocorre quando um usuário com um dado nívelde privilégio acessa dados e recursos de terceiros, cujo o nível de privilégio é o mesmo. Porexemplo em um cenário com dois usuários com o mesmo nível privilégio: usuário A e usuário B.O usuário A acessa funções e recursos alocados apenas para o usuário B.

2.3 Princípio de Privilégios Mínimos

O Princípio do Menor Privilégio, ou PoLP, é também conhecido como Princípio dePrivilégios Mínimos ou Princípio da Menor Autoridade (Saltzer; Schroeder, 1975). Na primeirapublicação sobre este princípio, Saltzer et al. afirmam que “cada programa e cada usuário

privilegiado do sistema deve operar utilizando o menor conjunto de privilégios para completar

o trabalho”. Em outras palavras, ele fala que para cada usuário, ou ação, ou até mesmo comandodeve receber o mínimo de privilégio necessário para que possa ser executado sem comprometera integridade de qualquer outra ação que execute no mesmo ambiente.

A ideia consiste em aumentar a granularidade dos processos de uma aplicação para quecada ação seja representada por um componente especializado dentro da aplicação, assim cadacomponente especializado irá possuir um nível próprio e mínimo de privilégio para executar asações contidas no componente.

Este princípio minimiza os danos causados por um ataque de escalação de privilégio apartir do momento que a quantidade de privilégios de cada entidade é reduzida. Assim, o PoLPnão só aumenta a segurança contra ataques de malwares mas também protege o resto do sistemacontra bugs e vazamentos de dados dentro da aplicação. Além disto, este princípio aumentaa rastreabilidade (Bittau; Marchenko, 2008) ajudando ao desenvolvedor a auditar o código edescobrir de onde surgiu a falha.

O PoLP propõem-se a prevenir que um usuário não autorizado tenha acesso à funçõese/ou recursos extras. O objetivo é limitar a quantidade de privilégio fornecido a uma determinadaação minimizando assim os possíveis danos causados pela ação de algum malware. Existemalgumas formas de garantir um isolamento seguro de recursos: uso de Linguagens Segurasbaseadas em Capabilities e Confinamento da Aplicação, por exemplo. Porém estas abordagensmostram-se ortogonais à Separação de Privilégios, que é o foco deste trabalho.


2.3.1 Paradigmas de Linguagens Object-Capability

São linguagens desenhadas para provê segurança, pois o seu uso permite que os progra-madores apliquem o PoLP aos programas (Mettler; Close, 2010). Neste paradigma todos osestados de um programa estão contidos dentro de objetos que não podem ser escritos e nem lidosdiretamente, é necessário fazer uso de uma referência para aquele objeto.

Tais referencias criadas são definidas de uma forma que não é possível ignora-las e teracesso direto aos objetos. Há uma gama de linguagens que fazem uso deste paradigma e que sãoutilizadas em sistemas operacionais específicos que também fazem uso deste paradigma.

Seguem os sistemas operacionais que implementam o modelo de object capability:KeyKOS, EROS, Integrity, CapROS, Coyotos, seL4, OKL4 e Fiasco.OC.

Seguem as linguagens que implementam o object capability: Act 1 (1981), Eden (1985),Vulcan (1986), Emerald (1987), Trusty Scheme (1992), W7 (1995), Joule (1996), Original-E(1997), E (1998), J-Kernel (1999), Oz-E (2005), Joe-E (2005), CaPerl (2006), Emily (2006) eCaja (2007).

2.3.2 Confinamento da Aplicação

Um forma de limitar o alcance a recursos por uma aplicação é executa-lo dentro de umambiente isolado, um sandbox. Desta forma os recursos acessíveis estarão sempre contidosnaquela região delimitada (Schreuders; Payne; McGill, 2013). Confinando as aplicações dentrode uma região limitada é possível reduzir os danos causados por um ataque bem sucedido deescalação de privilégio.

Nesta abordagem é relatado que os efeitos de um programa em execução dentro de umsandbox é completamente isolado dos recursos externos, ou seja, tais recursos externos o sandbox

não possuí autoridade para atuar. Assim, aplicações restritas em sandbox mitigam ataques dadoque os privilégios/recursos da aplicação estão limitados a apenas a aquela região de memória.

Um dos problemas relatados pelos autores é que esta abordagem requer uma redundânciasignificante dos recursos contidos em um sandbox. No caso do uso de máquinas virtuais queenvolvem duplicação de todo o sistema operacional, há um grande overhead no gerenciamentodas configurações das máquinas virtuais.

A Figura 2.1 representa esta abordagem de confinamento de aplicações. Na figura, aaplicação A inicia a aplicação B que está confinada dentro de um sandbox. A aplicação B podeacessar os recursos dentro do sandbox, entretanto ela não pode acessar os recursos que estão forado escopo do sandbox. Já as aplicações que não estão contidas dentro do sandbox (aplicação A)não são sujeitas às mesmas regras de controle de acesso, sendo então livres para acessar todos osrecursos fora do escopo, inclusive os recursos do sandbox também.


Figura 2.1: Esquema de Confinamento de Aplicação com Sandbox

Fonte: Adaptada de Schreuders; Payne; McGill (2013)

2.3.3 Separação de Privilégios

A técnica que separação de privilégio é a mais aplicada dentre as citadas anteriormente,por não depender de nenhum tipo de recurso extra para ser aplicado. Esta técnica divide o códigoem duas partes: sendo uma parte detentora de privilégios e outra sem privilégios, respectivamentedefinidas como: Monitor e Escravo (Provos; Friedl; Honeyman, 2003). Podendo estar presentedesde a camada mais baixa em um sistema operacional até no ato de desenvolvimento de umaaplicação de software.

Sua forma mais eficiente é implementada na arquitetura de um sistema operacional,sendo intrínseco no sistema, ao invés de um recurso de software extra (Perrin, 2009). Nossistemas operacionais baseados em Linux as ferramentas setuid() e setgid() são responsáveispela separação de privilégio no ambiente.

No nível da aplicação, uma aplicação que passou pelo processo de separação de privilégioé compartimentalizada em processos independentes. Assim, seus domínios passam a ficarisolados uns dos outros e cada processo passa a conter um conjunto reduzido de privilégios.

Existem duas formas de aplicar a separação de privilégios em uma aplicação, Manualou Automatizada. A classe de mecanismos Automatizados é subdividida em Automáticos deAnálise Estática e Automáticos de Análise Dinâmica.

O método manual de separação de privilégio é aplicado no ato de desenvolvimentodo software. O desenvolvedor fica responsável por estruturar o sistema de forma a isolar osdomínios de cada processo. Há um conjunto de padrões de projeto (Hafiz; Adamczyk; Johnson,2012) que quando bem aplicados garantem processos compartimentalizados com isolamentode domínio (Seção 2.6). Todavia, o uso de métodos manuais de separação de privilégiosdemonstram ser complexos, exigindo do desenvolvedor um alto conhecimento e cuidados no ato

2.4. ATAQUES DE ESCALAÇÃO DE PRIVILÉGIOS 23

do desenvolvimento (Gukda et al., 2012).Já os métodos automáticos são ferramentas com intuito de executar a separação para

o desenvolvedor. O nível de interação com o desenvolvedor é mínimo e a granularidade élimitada a ferramenta. Estes métodos surgiram como forma de diminuir a responsabilidadedo desenvolvedor em executar a separação de privilégios. As ferramentas automáticas sãoclassificadas em dois grupos de acordo com o tipo de análise. No grupo dos analisadoresautomatizados estáticos a ferramenta de separação de privilégio é aplicada ao código fonte.Enquanto o grupo dos analisadores automatizados dinâmicos é executada sobre o sistema emtempo de compilação.

Há uma outra abordagem onde o privilégio de um processo é elevado apenas no instanteem que ele deve executar a ação que requer o dado privilégio e ao fim da ação os privilégios sãorevogados para aquele processo, o Privilege Bracketing é utilizada nos sistemas operacionaisSolaris (Brunette, 2007).

Os exemplos mais conhecidos e bem sucedidos de aplicações que implementam aseparação de privilégio são a implementação do SSH (Lonvick; Ylonen, 2006) o OpenSSH(OpenBSD, 2009) e o navegador Google Chrome (Geneiatakis et al., 2012).

Para se proteger de vulnerabilidades provenientes de suas extensões o Google Chrome(Carlini; Felt; Wagner, 2012) tem em sua estrutura um mecanismo de separação de privilégio quedivide cada extensão entre: content scripts e core extension. Estas duas partes são executadas emprocessos distintos que se comunicam via um canal de comunicação autenticado. A proposta desua arquitetura é proteger a parte privilegiada core extension da parte mais susceptível a ataquese que não necessita de privilégios, o content script.

Já o OpenSSH (Provos; Friedl; Honeyman, 2003) é uma ferramenta que provê acessoremoto seguro através da internet. Algumas de suas etapas necessitam de privilégio de root paraserem executadas, entretanto essas etapas devem estar isoladas de forma que o usuário remotonão tenha acesso direto a elas.

Assim, no OpenSSH para cada nova conexão remota estabelecida é necessário umconjunto processos de privilegiados para: gerenciar os pseudo terminais para o usuário, autenticaro processo de troca de chaves, criar novos processos privilegiados para o usuário autenticado, etc.A estrutura do OpenSSH é dividida em três processos: um processo monitor e dois processosescravos. O processo monitor fica responsável por confinar todos os privilégios da ferramentaenquanto que a interação com o usuário remoto é executada via os dois processos escravos: umgerencia o processo de autenticação e o outro escravo gerencia os pseudo terminais do usuárioautenticado.

2.4 Ataques de Escalação de Privilégios

O PoLP surgiu visando melhorar a segurança dos softwares, entretanto para burlar esteprincípio também surgiram ataques com o intuito unicamente de escalar privilégios das aplicações

2.4. ATAQUES DE ESCALAÇÃO DE PRIVILÉGIOS 24

que passaram pelo processo de separação de privilégios. Trata-se de: Confused Deputy Attacks

(Hardy, 1988) e Collusions Attacks (Marforio et al., 2011).A partir do momento que a aplicação é compartimentalizada e seus domínios são isolados

do resto, são as interfaces de comunicação que passam a ser o novo ponto de falha que podemconceder a escalação de privilégios.

2.4.1 Confused Deputy Attacks

O Confused Deputy Attack refere-se a um ataque que explora falhas nas interfacesde comunicação de aplicações privilegiadas (Bugiel et al., 2012). Recorrente em aplicaçõescompartimentalizadas com interfaces de comunicação mal definidas, onde não há um conjuntode regras e restrições que delimitem o acesso a esta interface de comunicação.

Através de sucessivas requisições, partindo de um elemento não autentico para umprocesso privilegiado, um atacante espera que uma de suas requisições possa vir a ser respondidapelo processo privilegiado com algum tipo de informação ou recurso protegido.

Figura 2.2: Representação do Confused Deputy Attack

Fonte: Do autor

Exemplificando com a Figura 2.2, em um cenário onde uma aplicação detém algunsprivilégios e os demais não, as ações privilegiadas são então delegadas para a aplicação privilegi-ada. Caso as interfaces de comunicação entre o elemento privilegiado e não-privilegiado nãoestejam bem definidas o elemento privilegiado é então denominado de processo confuso. Assimo Confused Deputy Attack ocorre quando uma aplicação maliciosa tenta explorar as interfaces deuma aplicação detentora de privilégios, conforme ilustrado na Figura 2.2.

2.5. COMUNICAÇÃO ENTRE PROCESSOS 25

2.4.2 Collusions Attacks

O Collusions Attack é um ataque malware bastante sofisticado e de difícil detecção(Baraiya; Diwanji, 2015). Este ataque permite que aplicações (ou processos) executem operaçõesindiretamente que eles não deveriam ser capazes de executar com base nas suas permissõesdeclaradas.

Assim, o Collusion Attackt trata-se de ataque onde são encadeadas várias permissões quepossibilitam um atacante executar ações além dos seus privilégios individuais.

Figura 2.3: Representação do Collusion Attack

Fonte: Adaptado de Bugiel et al. (2011)

A Figura 2.3 ilustra um cenário formado por três aplicações com duas ações permitidasdefinidas entre as aplicações. Todavia, há uma ação possível neste cenário que não foi definidacomo uma ação permitida. O conluio das duas ações permitidas acaba possibilitando que aaplicação 01 tenha acesso aos componentes da aplicação 03 através da aplicação 02.

2.5 Comunicação entre Processos

Os ataques anteriormente citados (Seção 2.4), assim como outros citados pelo CVE(CVE, 2011a,b, 2013, 2015c), foram ataques que ocorrem via os canais de comunicação dessasaplicações compartimentalizadas. Esses canais de comunicação entre processos e aplicações sãoconhecidos como Inter-Process Communication (IPC).

IPC é um mecanismo de compartilhamento de dados entre processos, que permite queprocessos isolados possam interagir. Há várias formas de se estabelecer um canal IPC entreas partes, como por exemplo: mensagens, arquivos, região de memória comum, etc. Em geralos IPCs possuem uma aplicabilidade local, ficando restrito ao ambiente de domínio do sistemaoperacional, entretanto, há implementações que garantem interações entre processos que nãoestão alocados no mesmo hospedeiro.

Sendo fundamental para a decomposição de sistemas em domínios distintos e protegidos,as aplicações nas quais o PoLP foi aplicado fazem largo uso deste mecanismo. Desta forma acomunicação entre os processos isolados é garantida.

2.5. COMUNICAÇÃO ENTRE PROCESSOS 26

Tabela 2.1: Métodos IPCs mais usados

Método DescriçãoPipe Estabelece um canal por onde o fluxo de dados irá passar definindo

qual o processo detém o padrão de escrita e qual processo detém opadrão de leitura no canal. Porém, apenas um carácter é lido porvez.

Mensagem A comunicação entre os processos é feita através das filas demensagens do Sistema Operacional. É possível desta forma ainteração entre múltiplos processos sem estar necessariamenteconectados uns aos outros.

Memória Compartilhada Uma determinada região de memória volátil é alocada para quedois ou mais processos tenham permissão de leitura e escrita, istopossibilita a interação entre múltiplos processos.

Socket Provê um canal de comunicação além do mesmo hospedeiro. Ofluxo de dados é enviado através da interface de rede, permitindoassim que os processos estejam alocados no mesmo hospedeiro ouaté em hospedeiros diferentes da rede.

Sinal Sem objetivo de transmitir dados, os sinais constituem um sistemade mensagens enviadas entre processos que transmitem comandosremotos.

Semáforo Meio de sincronização de recursos entre múltiplos processos. Estaestrutura permite compartilhar recursos entre múltiplos processosde forma síncrona.

2.6. PADRÃO DE PROJETO SEGURO MONITOR DE REFERÊNCIA 27

Figura 2.4: Análise de performance entre os métodos IPC dentro do Kernel Linux2.2.5-15 ao enviar 5000 mensagens

Fonte: Adaptado de Immich; Bhagavatula; Pendse (2003)

A Tabela 2.1 dispõem dos métodos mais comuns (Stevens; Fenner; Rudoff, 2004)utilizados nas implementações. Cada um dos métodos possui características diferentes dedesempenho (vide Figura 2.4), porém é relatado que esses mecanismos não possuem por padrãofortes rotinas de segurança (Stevens; Rago, 2013; Lidie; Walsh, 2002).

Tratam-se de rotinas de autenticação entre o lado cliente e o lado servidor onde elestrocam elemento de identificação única. Como no caso do sockes IPC que possui um mecanismopadrão autenticação onde através do canal o cliente envia para um servidor suas credenciais(Kerrisk et al., 2009), uma tupla com identificadores únicos: Process Identifier (PID), User

Identifier (UID) e Group Identifier (GID). Este processo de autenticação ocorre durante a trocada primeira mensagem entre cliente e servidor, porém isto não evita que um atacante forje estesparâmetros e nem impede que qualquer processo consiga obter conexão com o dado servidor.

2.6 Padrão de Projeto Seguro Monitor de Referência

Especificado como um padrão de segurança (Hafiz; Adamczyk; Johnson, 2012), omonitor de referência é um módulo que detém o conhecimento das ações do seu domínio.Idealmente todo o tráfego de pacotes, sinais, chamadas remotas, e etc., deve passar pelo monitor,pois ele é responsável por restringir ou liberar o acesso de processo e/ou usuários à operações dosistema através da aplicação de políticas. Este padrão impõem que um monitor de referênciadeve satisfazer os seguintes requisitos (Rooker, 1993):

� Ser um mecanismo de controle de acesso

� Ser um mecanismo de autorização

� Prover execução controlada

2.6. PADRÃO DE PROJETO SEGURO MONITOR DE REFERÊNCIA 28

O monitor de referência (Jaeger, 2011) também pode ser definido como um mecanismode validação que deve:

� Mediar as ações no sistema

- O monitor deve ser invocado para toda e qualquer operação

� Ser à prova de falsificação

- Um atacante é impossibilitado de burlar as políticas aplicadas

� Ser íntegro nas verificações

- O monitor não deve falhar nas rotinas de teste, verificação e aplicação daspolíticas

O maior exemplo dentre os monitores reais é o Kernel do Linux. Responsável por sero núcleo de todos os sistemas Linux, o Kernel constitui uma das mais importantes aplicaçõesdo padrão Monitor de Referência (Rooker, 1993). O Kernel administra as funções dentro doSistema Operacional sendo responsável por tentar garantir os devidos acessos dos programasaos dados e recursos sem comprometer a integridade do Sistema Operacional. Assim comoo Kernel Linux outros sistemas também fazem largo uso deste padrão, como por exemplo osistema operacional mobile Android.

O Design Patterns do Monitor de Referência (Schumacher et al., 2013) é mostrado emum Diagrama de Classe (Figura 2.5) e um Diagrama de Sequência (Figura 2.6). Eles ilustram aestrutura organizacional e a estrutural comportamental de um monitor de referência.

Figura 2.5: Diagrama de Classe do padrão Monitor de Referência

Fonte: Adaptado de Schumacher et al. (2013)

As regras de autorização, no diagrama de classe, representam um conjunto organizadode regras que tanto pode ser um Access Control List (ACL) ou qualquer outra estrutura organiza-cional, visto na Figura 2.5.

2.7. MODELOS DE CONTROLE DE ACESSO 29

Figura 2.6: Diagrama de Sequência do padrão Monitor de Referência

Fonte: Adaptado de Schumacher et al. (2013)

Quando um processo corrente requisita acesso a um recurso tal requisição deve passarpela análise do Monitor de Referência, vide Figura 2.6. O monitor verifica a existência de umaregra de autorização para aquela requisição, caso exista então a requisição de acesso é autorizadae o processo corrente obtém acesso ao recurso desejado.

2.7 Modelos de Controle de Acesso

No mundo físico controle de acesso é definido por rotinas que a partir de credenciasde identificação é determinado se um indivíduo tem acesso ou não a um recurso. Usado paraaplicar proibições ou permissões, os mecanismos de controle de acesso são muito utilizados nacomputação. Quando pretende-se aplicar restrições quanto ao uso de um recurso do hospedeiro,o mecanismo de controle de acesso deve intermediar uma requisição de acesso ao recurso eprover como resposta se o acesso é permitido ou proibido (Samarati; Capitani, 2001). A partirdas políticas de controle de acesso é possível classificar os modelos de controle de acesso comodispostos na Tabela 2.2.

Tabela 2.2: Esquemas de Controle de Acesso

Esquema DescriçãoDAC Utiliza a identidade do processo/usuário que requisita a ação como o único

elemento para restringir ou liberar a ação. O termo discricionário diz que ousuário tem a capacidade de transmitir seus privilégios para outro sujeito.

MAC As regras aplicadas baseado em mandatos de uma entidade central para restrin-gir um processo/usuário de operar sobre um determinado objeto/recurso.

RBAC As regras são aplicadas para um grupo de usuários/processos definidos por umafunção/papel dentro da organização. Mais flexível que os modelos anteriores.

OrBAC É uma expansão do modelo anterior, inserindo o conceito de organização alémde agregar politicas aplicadas ao papel/função.

2.8. RECAPITULAÇÃO 30

O controle de acesso baseado em políticas demonstra conceitos poderosos de autenticaçãoe autorização. Quando o modelo possui regras bem formuladas, com uma alta granularidade esem inconsistências, pode prover um sistema pouco susceptível a vulnerabilidades.

2.8 Recapitulação

Os privilégios concedidos a um processo/usuário são como limitantes de acesso a algumrecurso, operando assim como atributos de segurança. Entretanto, vulnerabilidades de ganho deprivilégio permitem que atacantes consigam escalar esses privilégios para si, obtendo assim, deforma não autêntica, acesso a recursos antes protegidos.

O PoLP minimiza os danos causados pelos ataques de escalação de privilégios porreduzir a quantidade de privilégios de cada entidade susceptível a estes ataques. A aplicação doPoLP pode ser executada através técnicas como: Linguagens Seguras baseadas em Capabilities,Confinamento de Aplicações ou Separação de Privilégios.

Como o uso deste princípio mitiga os ataques de escalação de privilégio, foram entãocriadas contramedidas pelos atacantes. Foram desenhados ataques contra aplicações que im-plementam o PoLP para obter vantagens de suas estruturas, são: Confused Deputy Attack eCollusion Attack.

Por fim, neste capítulo também foram introduzido os conceitos do padrão de projetoseguro monitor de referência, os modelos de controle de acesso, além dos conceitos sobre oscanais de comunicação IPCs. Estes são conceitos fundamentais para a proposta deste trabalho(Capítulo 4).

No capítulo seguinte, será dissertado sobre os trabalhos mais recentes que aplicam atécnica do PoLP.

313131

3Estado da Arte

Os trabalhos mais atuais encontrados na área estão dispostos em três grandes ambientes:web, desktop e Android. A seguir, foram sumarizados estes trabalhos e classificados para cadaum dos três grandes ambientes. Por fim, a seção de discussão (Seção 3.2) trata das vantagens edesvantagens destes trabalhos.

3.1 Trabalhos Relacionados

3.1.1 Separação de Privilégio em Web Services

O WebJail (Van Acker et al., 2011) é um trabalho que foca no lado cliente de umaaplicação web. O WebJail constitui uma camada de políticas dentro do browser para evitar quecomponentes maliciosos provenientes de Mashup’s 1 possam vir a escalar privilégios do usuário.

Os autores inseririam dentro do browser Mozilla Firefox uma camada de políticas e umelemento que intermedeia as chamadas de funções dos mashup’s e aplica as políticas definidas.

Sobre o WebJail foi feita uma análise de performance e os autores mediram o overhead

causado no page load e na execução de funções do browser, criando assim um benchmark para aproposta. Os autores afirmaram ter uma penalidade insignificante de tempo diante da inserçãoda solução, sendo de 7ms o impacto no page load e de 0.1ms o overhead para cada função notempo de execução.

Mining Access Control Errors (MACE) (Monshizadeh; Naldurg; Venkatakrishnan, 2014)foi uma ferramenta desenvolvida com proposito de detectar a existência de vulnerabilidadesdentro do código de uma aplicação que permitissem ataques de escalação vertical e horizontalde privilégios. Esta ferramenta executa análises em busca de inconsistências nas políticas deautorização no lado servidor de uma aplicação web.

Os autores afirmam que para a corretude das aplicações web é preciso verificar cadaoperação executada. É preciso que exista um arquivo com políticas bem definidas para cadaoperação que possa ser permitida para um dado usuário. Analisando a interação de uma aplicação

1Mashup’s são aplicações web que combinam dados e funções de fontes ou componentes diferentes

3.1. TRABALHOS RELACIONADOS 32

web com uma base de dados, o MACE avalia três pontos: o estado da autorização, o contexto daautorização e a consistência do contexto da autorização.

O trabalho relata que as análises são de melhor esforço, mas o grande valor agregadopela ferramenta é a capacidade de detectar falhas ainda desconhecidas. Ou seja, com o usodesta ferramenta nas aplicações web é possível evitar a criação de brechas que podem vir a serexploradas no futuro.

O Passe (Blankstein; Freedman, 2014) é um protótipo para o framework web Django quelimita a comunicação entre componentes compartimentalizados. Os autores afirmam que mesmopara aplicações que sejam executadas em ambientes isolados há ataques que exploram os canaisde comunicação ou as regiões de memória compartilhada. Assim, o Passe protege os dados entrecomponentes, limitando as interações para consultas restritas de dados.

O Passe insere um tipo de proxy entre as aplicações e a base de dados, e também umtoken que valida as políticas em vigor por aplicação. Este proxy confiável é responsável porpermitir ou proibir as consultas de dados, as ações são tomadas com base em um conjunto derestrições. Assim, cada aplicação, que roda em uma área separada e restrita, tem suas consultas àbase de dados intermediadas pelo proxy que checa a validade do token e a política associada.

Os autores avaliaram a vazão e a latência das consultas mas constaram que a inserçãodo Passe tem um impacto que varia conforme a aplicação usada. Tendo o maior impacto nasaplicações que necessitam de alguma operação de I/O do que para aquelas que interagem com abase de dados. Também foi avaliado o overhead da ferramenta Passes que apresentou ter umconsumo excessivo de memória.

3.1.2 Separação de Privilégio em Android

Os autores (Felt et al., 2011) apontaram para os riscos introduzidos pela ameaça deredelegação de permissão. Redelegação de permissão trata-se de um caso especial do confused

deputy attack em que uma aplicação detentora de privilégios executa uma ação para umaaplicação sem privilégios. O IPC Inspection foi um mecanismo proposto pelos autores paracombater a redelegação de permissões.

Foi implementado um protótipo para o Android 2.2, nele foi adicionado o suporte do IPCInspection ao PackageManager2 e ao ActivityManager3. Estas duas modificações permitem umcontrole sobre as interações IPC, reduzindo assim os privilégios entre aplicações. Além disto,também foi estendido o formato do manifest Android para limitar as mensagens recebidas pelasaplicações.

Os autores primeiramente avaliaram 872 aplicações Android a fim de demonstrar suasfragilidades diante da redelegação de permissões, constatando que 11 de cada 16 aplicaçõesestão em risco. Já na avaliação da solução IPC Inspection, foram avaliados: eficiência, facilidade

2o PackageManager é responsável por instalar aplicações, armazenar e aplicar as permissões3ActivityManager gerencia as comunicações entre aplicações, podendo inicializar uma aplicação se necessário


no desenvolvimento e performance. Os autores fizeram uma análise qualitativa quanto àsmétricas avaliadas e afirmaram que o IPC Inspection não impõem restrições no desenvolvimento,conseguindo com baixo impacto evitar todos os ataques de redelegação de permissões.

XMandroid (Bugiel et al., 2011) é um monitor de referência para o Android com umesquema de políticas que controla os canais de comunicação Inter-Component Communication

(ICC). Assim, os autores propuseram um framework que estende o monitor padrão do Android.O sistema de políticas proposto reforça o esquema padrão do Android com um conjunto deregras seguras que visam evitar a escalação de privilégios via os canais ICC.

Na estrutura do Android, os autores modificaram o comportamento do monitor dereferência, assim, para cada canal de comunicação ICC aberto, o monitor de referência passaa consultar um sistema de decisão do XMandroid que irá permitir ou proibir aquela interação.Os autores atentam que o sucesso na detecção de malwares pela solução depende das políticasdefinidas, pois regras inadequadas podem vir a gerar novas brechas e afetar o comportamento deaplicações genuínas.

A solução XMandroid foi avaliada utilizando aplicações maliciosas dentro da plataformaAndroid. Os autores afirmaram que a solução conseguiu detectar ataques de transitividade(Collusion Attacks) entretanto houve um impacto significativo sobre o tempo das chamadas deICC.

PScout (Wain et al., 2012), ou na forma extensa Permission Scout, foi uma ferramentadesenvolvida para ambiente Android incumbida de analisar as permissões necessárias para umaaplicação a partir do código fonte desta aplicação. Os autores constataram que as aplicaçõese Application Program Interfaces (APIs) utilizam em média 22% mais permissões do que onecessário, abrindo assim brechas para atacantes explorarem estes privilégios. O PScout é umaferramenta que reduz o número de permissões desnecessárias nestas aplicações mobile.

A solução utiliza uma ferramenta de bytecode Java para executar a análise estática docódigo-fonte. A extração de permissões pelo PScout é executada em três etapas. Primeiro, sãoidentificadas todas as checagens de permissões pelo Android. Em seguida é construído um grafode chamadas de funções incluindo IPC e Remote Procedure Call (RPC). Por fim, é executadouma verificação em sentido contrário sobre o gráfico, onde são encontradas todas as APIs quepodem alcançar uma determinada permissão dentro do sistema operacional.

Os autores estimaram a qualidade de solidez e completude da ferramenta sobre a aplicaçãoUI Fuzzer e sobre quatro versões do sistema operacional Android: 2.2, 2.3, 3.2 e 4.0. Sobrea aplicação, os autores mostraram obter precisão na detecção das permissões pela ferramenta.Sobre os sistemas operacionais, os autores mostraram que há pouca redundância nas permissõesdo sistema, entretanto, é possível encontrar um pequeno conjunto de permissões em APIs nãodocumentadas.

A API AdDroid (Pearce et al., 2012) foi proposta para o sistema operacional Androidpara separar os privilégios compartilhados entre a aplicação e as bibliotecas de propagandausadas na aplicação. Os autores afirmam que estas bibliotecas de propaganda têm acesso a


todos os privilégios da aplicação de forma desnecessária. Assim, o AdDroid usa a separaçãode privilégios para isolar os privilégios da aplicação e conceder as bibliotecas de propagandaapenas o necessário para operar.

Como prova de conceito foi implementado um protótipo do AdDroid dentro do Android

Open Source Project (AOSP) na versão Gingerbread, o AdDroid é formado por três componentes:a região de uso da biblioteca, um novo sistema de serviço Android e as permissões Android.O primeiro componente constitui a interface de interação entre a aplicação e as propagandas,que via chamadas de IPC interage com o componente do sistema de serviço. Este por sua vez,que roda em background, verifica no componente de permissões a existência das permissões depropaganda e então faz a consulta da propaganda na rede. Por fim o resultado obtido é retornadovia IPC para o primeiro componente.

Foram analisadas as aplicações do Android Market4 e constataram que 46% das aplica-ções que hospedam propagandas tem privilégios em excesso devido ao uso das bibliotecas depropagandas. Com o uso das permissões exclusivas para propagandas inseridas pelo AdDroidfoi possível prevenir que as propagandas obtivessem acesso a privilégios extras da aplicação.

Os autores (Gunadi; Tiu, 2014) constataram que apesar de estrutura do Android isolar asaplicações e seus recursos um dos outros, as vias de comunicação IPC representavam pontospara os ataques de escalação de privilégio Confused Deputy Attack e Collusion Attack. Osautores desenvolveram como prova de conceito a eficiência no uso de políticas Metric Temporal

Logic (MTL) para mitigar estes ataques. Eles propuseram uma extensão para o sistema depolíticas do Android que intercepta as chamadas IPC e mitiga os ataques.

O framework Android foi alterado para inserir o algoritmo de monitoramento. Foiadicionado um recurso ao framework que redireciona as checagens de permissões das aplicaçõespara a solução antes da mesma ser passada ao sistema operacional Android. Assim, antes dosistema operacional Android checar em sua base de políticas regras para aquela ação o MTL éexecutado.

Foram implementadas quatro políticas para interceptar chamadas IPC: a política 1 parabloquear acessos diretos a recursos por aplicações não confiáveis e as demais para bloquearataques de transitividade. Os autores avaliaram o impacto de tempo causado sobre essas chamadaspor cada uma das políticas. Os autores detectaram que a política 1, pela simplicidade do bloqueio,teve um overhead em média de 1ms enquanto que as demais políticas chegaram a dobrar o tempodas chamadas IPC por se tratar de regras mais complexas.

Uma técnica de monitoramento de comportamento anômalo dentro de aplicações foiproposta (Jeong et al., 2014). Os autores relatam que a popularidade do Android impulsionou osurgimento de alguns malwares e variantes de malwares, assim sistemas de detecção baseadosem assinaturas, os antivírus, acabam sendo pouco eficientes no combate a estes malwares.

A proposta de monitoramento é constituída de dois módulos. O primeiro monitoraos eventos e mensagens IPC/RPC, enquanto que o segundo módulo registra ações maliciosas

4Foi substituído pelo Google Play


detectadas dentro da aplicação gerenciada. Ambos os módulos foram implementadas dentro dokernel Android. Os autores afirmam que desta forma foi possível detectar ataques de escalaçãode privilégio como confused deputy attack e collusion attack.

A técnica de monitoramento foi avaliada em ambiente real. Os autores implementaramduas simples aplicações a fim de demonstrar a detecção de um ataque de confused deputy.Uma das aplicações foi implementada com permissão para ler o International Mobile Station

Equipment Identity (IMEI) enquanto a outra simulou um atacante sem tal permissão. Assim,todas as requisições foram detectadas pelo kernel via as chamadas RPC e registradas em umarquivo de log.

O SEIntentFirewall (Mutti; Bacis; Paraboschi, 2015) é um sistema de políticas baseadono SELinux para gerenciar as Intents5 trocadas no ambiente Android. O objetivo é prover umamaior granularidade no controle de acesso Mandatory Access Control (MAC) sobre os objetosIntent.

Foi estendido o AppPolicyModules para alcançar e aplicar políticas sobre os objetos Intent.As modificações feitas pelos autores almejam: recuperar o contexto de segurança associado aaplicação e permitir ao mecanismo de controle de acesso do SELinux manusear as permissõesdefinidas para um objeto Intent.

O uso do SELinux no ambiente Android constitui uma etapa importante para serviços desegurança mais flexíveis e robustos. Os autores afirmam que o SEIntentFirewall é um soluçãoextensível que melhora a aplicação de políticas de controle de acesso.

3.1.3 Separação de Privilégio em Desktop

Codejail (Wu et al., 2012) é uma framework para isolamento de bibliotecas não con-fiáveis. Os autores afirmam que é comum fazer uso de bibliotecas de terceiros para auxiliarno desenvolvimento, entretanto estas bibliotecas compartilham do mesmo espaço de memóriaque a aplicação e podem trazer bugs que comprometem o funcionamento do programa, comovazamento de dados por exemplo.

O protótipo do Codejail foi portado para o Linux. O Codejail atua como uma interfaceentre a aplicação e a biblioteca utilizada. A biblioteca é enjaulada pelo Codejail, ficando isoladada aplicação. Os acessos às funções da biblioteca são feitas via socket UNIX pelo Codejail,assim as bibliotecas não tem acesso direto à aplicação. Esta estrutura permite ao Codejail serefetivo contra ataques de corrupção de memória e execução de código arbitrário.

Foi executado um benchmarking do Codejail avaliando o desempenho de quatro bibliote-cas. Foi medido o desempenho nativo das bibliotecas com o Codejail sem confinar a biblioteca ecom o Codejail confinando a biblioteca. As quatro bibliotecas avaliadas foram: libpng, libexpat,libbzip2, libtiff. Os autores apontaram que o uso do framework Codejail sem confinar a bibliotecaapresentou em alguns casos um overhead menor que 5%.

5Intent é o mecanismo de comunicação usado no Android para troca de informações entre componentes damesma aplicação ou de aplicações distintas


ProgramCutter (Wu et al., 2013) é uma ferramenta de particionamento automático decódigos a partir de uma análise dinâmica das dependências dos dados. Os autores relatam que ouso de técnicas manuais de separação, por ser bastante custosa e levar a muitos erros no ato dodesenvolvimento, acaba promovendo ao desenvolvimento de aplicações monolíticas.

A ferramenta ProgramCutter é aplicada em três etapas: Trace Collector, Graph Partitio-

ner e Source Translator. Na primeira etapa o código monolítico é aplicado ao trace collector

que analisa as interações e dependências entre as parte do código através de labels inseridaspelo desenvolvedor. A partir desta análise é criado uma estrutura de grafo que expressa essasinterações, assim na etapa do graph partitioner é criar de fato o grafo. Por fim, a etapa desource translator utiliza o grafo gerado para reescrever o código monolítico com os privilégiosseparados.

O ProgramCutter foi aplicado às quatro aplicações: OpenSSH, ping, wget e thttpd.Os autores avaliaram para cada uma das ferramentas o overhead de tempo e a capacidade deminimizar os privilégios das aplicações. Com um impacto de menos de 20% no tempo dasferramentas os autores afirmaram ter conseguido minimizar os privilégios de 100% até 22%.

ARBITER (Wang; Xiong; Liu, 2013) foi uma API desenvolvida para gerenciar e isolaras regiões de memória compartilhada entre threads de uma aplicação multithreading. Esta APIconstitui um monitor de referência que fica incumbido de gerenciar essa memória compartilhadaentre as threads.

O ARBITER não faz uso de uma ACL mas sim de um conjunto de labels ao longo docódigo, estas labels são definidas pelo programador para expressar as políticas de segurança daaplicação. Através das labels que é possível dar permissões as threads para operar e como operarem cada região de memória.

Os autores do ARBITER aplicaram a solução sobre a ferramenta memcached e geraramum microbenchmark para quantificar overhead inserido por esta API. Eles chegaram ao resultadode um aumento de 28% no tempo das chamadas das funções do memcached.

Os autores (Trapp; Rossberg; Schaefer, 2015) propuseram um método de análise estáticade particionamento de código. Trata-se de um particionador que cria uma aplicação comparti-mentalizada com o mínimo de partes não privilegiadas, pois os autores afirmam que a segurançade uma aplicação compartimentalizada depende de dois fatores: o número de compartimentos deuma aplicação e do gerenciamento dos compartimentos não privilegiados.

Os autores formam um grafo a partir de um modelo que avalia quatro métricas: existênciade privilégio na função, complexidade desta função, peso do privilégio e o risco agregado àchamadas IPC para aquela função. Por fim, é feito uso de uma heurística que tende a aglomerartodas as partes não privilegiadas dentro de um compartimento, visando assim minimizar asvulnerabilidades agregadas a estes tipos de compartimentos.

Como relatado pelos autores, a ferramenta não estava completa então o processo dedecomposição foi feito manualmente sobre udhcpd que é a versão leve do daemon do Dynamic

3.2. DISCUSSÃO 37

Host Configuration Protocol (DHCP) do projeto BusyBox6. Foram feitas duas separações:dentro de dois processos e dentro de cinco processos. Em relação ao processo monolítico, foiconstatado um overhead de 5.9% e 11.3%, respectivamente.

3.2 Discussão

Foram apresentados os trabalhos presentes na área de separação de privilégios. Elesforam classificados em três grandes áreas de atuação: ambiente Web, ambiente Android eambiente Desktop.

Em geral, a grande preocupação dos trabalhos tem sido de propor ferramentas auto-matizadas de particionamento sem atentar para as vulnerabilidades criadas pelos canais decomunicação. Entretanto, calcado pela infraestrutura provida pelo sistema operacional An-droid, alguns trabalhos demonstraram preocupação com os canais IPC e propuseram meios demitiga-los.

No ambiente web foram destacados três trabalhos: WebJail, MACE e Passe. Apesar defazerem parte do mesmo ambiente, o ambiente web, cada uma tem uma proposta de atuação bemdiferente.

O MACE é uma ferramenta que é aplicada no ato do desenvolvimento do software capazde detectar brechas na estrutura do código antes desconhecidas, que permitiriam a escalações deprivilégios na aplicação. Sua grande vantagem é evitar a criação destas brechas pelo desenvolve-dor, brechas estas que possam vir a comprometer o comportamento da aplicação. Entretanto, épreciso destacar que é exigido do desenvolvedor o conhecimento necessário para corrigir taisfalhas, pois a ferramenta se limita a apontar a sua existência. No MACE são feitas checagensdas interações permitidas entre a aplicação e uma base de dados. São verificadas as consultas abase e esta é uma característica marcante da solução, pois já aponta para uma preocupação sobreas interações entre partes separadas.

Assim como o MACE, o Passe tem um enfoque na proteção dos fluxos de dados entrecompartimentos. Neste trabalho já é percebido uma preocupação com ataques de escalaçãode privilégio que se sucedem pelas interfaces de comunicação. Apesar do impacto causado nodesempenho da aplicação web pela inserção de um elemento intermediário (o proxy), o usodeste mesmo elemento permite agregar mais e melhores rotinas de segurança. Esta vantagempermitiria aos autores prover maiores garantias de segurança aos fluxos de dados.

Por fim, no ambiente web, o WebJail foi uma proposta de modificação na arquiteturados browsers com a inclusão de uma camada de política capaz de controlar o acesso à recursosdas aplicações que rodem no lado da aplicação cliente. Trata-se de um sistema de políticasque gerencia a interação entre as partes confinadas do browser provenientes de aplicaçõesnão-confiáveis. Os autores tiveram como grande vantagem um elemento de controle de acessocentralizado que interferiu pouco no tempo de page load pelo browser.

6BusyBox Project https://busybox.net/

https://busybox.net/

3.2. DISCUSSÃO 38

Vale destacar que dois dos três trabalhos destacados no ambiente web fizeram uso de umsistema de controle de acesso centralizado, intermediando as interações entre compartimentos.Isto é percebido como uma vantagem que provê maior poder de controle dentro de uma solução.

Quando se trata do ambiente Android, este sistema operacional introduz uma série defacilidades sobre o controle de permissões de aplicações e controle sobre o fluxo de dados ICC eisto promoveu o desenvolvimento de muitos trabalhos nesta área que aproveitaram esta facilidade.Facilidade esta que não existe para ambientes Desktop ou Web.

Os trabalhos IPC Inspection, XMandroid, MTL, Jeong et al., e SEIntentFirewall sãoexemplos de trabalhos calcados pelo suporte que o monitor de referência Android detém. Estestrabalhos então propuseram soluções que visavam maior controle sobre o fluxo de mensagensICC entre aplicação. Foram propostas de módulos e funcionalidades adicionais dentro do monitorde referência padrão do Android que criam ganchos para os canais IPCs e garantem assim aaplicação de políticas que delimitam essas chamadas com maior granularidade. Amparados pelainfraestrutura existente no Android as concepções destas soluções são de grande valor, entretantoas ferramentas ficam confinadas no domínio mobile Android.

O trabalho PScout possui uma ideia que lembra o trabalho do MACE proposto paraambiente Web. Eles se assemelham por terem o enfoque em diagnosticar as falhas e vulne-rabilidades em uma aplicação sem atuar e corrigir a mesma. O PScout mostrou que até ossistemas Android ainda estão bastante vulneráveis e permitindo a escalação de privilégios. Já oAdDroid contribuiu bastante demonstrando as falhas ao se compartilhar todas as permissões entrediferentes bibliotecas dentro de uma aplicação. Apesar de ter o enfoque restrito a bibliotecas depropagandas, este trabalho contribuiu bastante, demonstrando falhas na estrutura Android, assimcomo o PScout.

Por fim, o ambiente Desktop. Os autores que concentraram esforço para este ambientetendem a propor métodos de particionamento automático de código. Estas soluções visamdiminuir a responsabilidade do desenvolvedor de aplicar os padrões de projetos para segurança.Entretanto, as soluções tendem a desmerecer as vulnerabilidades que os canais IPC passam aexpor (relatados na Seção 2.4).

No trabalho dos autores Trapp et al., foi relatado que os canais de comunicação IPCpodem expor uma aplicação compartimentalizada. Apesar dos autores não proporem umasolução para prover mais segurança para tais canais, eles propuseram uma heurística paradiminuir o número de canais expostos. Ou seja, Trapp et al. ainda tem um trabalho focado emum particionador automático porém destaca ao longo do artigo os problemas devido ao usoincauto de canais de comunicação IPC.

Já o ARBITER e o ProgramCutter foram abordagens focadas em obter melhores partici-onadores automáticos, porém sem demonstrar preocupação com o exaustivo uso de canais decomunicação IPC/RPC. Os autores dos trabalhos têm como preocupação ter uma boa granula-ridade no particionamento, a fim de mitigar a escalação de privilégios, com o menor impactopossível sobre o tempo de uma aplicação. Em ambos os trabalhos é alcançado algo em torno de


um overhead de 20% após o particionamento. Mas não foi avaliado a resiliência da aplicaçãocontra ataques que pudessem explorar os canais IPC criados. Além disto, a solução ARBITERtem problemas com portabilidade, já que só está disponível para sistemas operacionais x86.

Diferente das soluções Desktop anteriores, o CodeJail não faz particionamento auto-mático, porém, propôs um framework para isolar bibliotecas de terceiros que são anexados auma aplicação. Esta interface não só controla o acesso das bibliotecas às regiões de memóriada aplicação como intermedeia os acessos direto à funções das mesmas. Um ponto bastanterelevante deste trabalho é que além de evitar a escalação de privilégios via essas bibliotecas,a solução também se diz capaz de evitar ataques como corrupção de memória e execução decódigo arbitrário. Os autores não mencionaram nada sobre os ataques listados na Seção 2.4.

Como discutido, os trabalhos do estado da arte não se preocuparam com a segurança dosbarramentos de comunicação criados entre os compartimentos. Calcado neste ponto, o trabalhodesenvolvido nesta dissertação inova em relação aos demais trabalhos do estado da arte porpassar a emprenhar-se em mitigar os ataques que atentam contra estas interfaces de comunicação.Além disto, a solução apresentada visa reforçar alguns pilares de PoLP que também não foramabordados pelos trabalhos da literatura, que são auditoria e rastreabilidade.

3.3 Recapitulação

Neste capítulo foram listados os trabalhos mais relevantes presentes em três grandesambientes: ambiente web, ambiente Android e o ambiente Desktop. Cada um desses ambientespossui características intrínsecas que permitiram e facilitaram o desenvolvimento de algunstrabalhos. Como por exemplo o ambiente Android, onde a estrutura do sistema operacionale existência de um monitor de referência desenvolvido permitiu propostas de trabalhos maisrobustas.

No decorrer do capítulo, foram discutidos os aspectos mais fortes e fracos de cada umdos trabalhos listado. E, dentre os trabalhos mais relevantes na literatura, foi visto que grandeparte deles focaram em ferramentas de separação automatizada de privilégios e acabaram quenão se comprometeram em proteger o canal de comunicação criado.

As propostas que visavam proteger e gerenciar os canais de comunicação estavamconcentradas no ambiente Android. Estes trabalhos estavam calcados na infraestrutura dosistema operacional que permitia e facilitava o desenvolvimento deste tipo de solução. Já noambiente Desktop e Web, poucos foram os trabalhos que se preocuparam com a vulnerabilidadesexpostas pelos canais IPC.

A seguir será dissertado sobre a proposta que visa mitigar as vulnerabilidades expostaspelos canais IPC que não foram cobertas pelos trabalhos existentes.

404040

4Proposta

Até este dado capítulo foram vistos os conceitos do PoLP e as técnicas utilizadas naaplicação deste princípio. O seu surgimento se deu como forma de mitigar ataques de escalaçãode privilégios, minimizando o montante de privilégios compartilhados em uma mesma região dememória. O PoLP foi muito aplicado como contramedida aos ataques de escalação de privilégios,entretanto os recentes dados estatísticos do CVE apresentados apontaram para um crescimentonas vulnerabilidades de escalação de privilégio (Capítulo 1).

Apesar de todos os benefícios promovidos pelo uso do PoLP, em contrapartida foramlevantados problemas que surgiram a partir do PoLP (Capítulo 2), como: as vulnerabilidades doscanais de comunicação (confused deputy attack e collusion attack) e a dificuldade de desenvolver,via métodos manuais, aplicações compartimentalizadas de alta granularidade.

Enquanto isso na literatura (Capítulo 3) os trabalhos em geral tem visado diminuir aresponsabilidade do desenvolvedor no uso de métodos manuais de separação de privilégio,estes trabalhos então propõem ferramentas de particionamento automatizado. As soluções paraambiente Desktop não se preocupam com os ataques criados contra aplicações que implementamo PoLP.

Assim, este trabalho traz como proposta uma abordagem para aplicações compartimenta-lizadas que visa mitigar as vulnerabilidades que atentam contra os canais de comunicação destasaplicações. Além disto, esta proposta almeja melhorar a auditoria e aumentar a rastreabilidade,isto devido ao fortalecimento do conceitos do PoLP chamado de execução monitorada.

A seguir será dissertado sobre a solução Secure-CompApp, destacando sua estrutura,como será alcançado os objetivos, a prova de conceito desta abordagem e por fim será discutidoos aspectos positivos e negativos do seu uso.

4.1 Estrutura

Como dito anteriormente, uma aplicação compartimentalizada divide uma aplicaçãomonolítica em partes distintas, com seus domínios de atuação isolados uns dos outros. Naprimeira parte da Figura 4.1 temos uma abstração de uma aplicação compartimentalizada. Uma

4.1. ESTRUTURA 41

aplicação composta por três processos distintos que se comunicam via um canal de comunicaçãoIPC. Todas as trocas de dados são feitas através do canal IPC estabelecido diretamente entre osprocessos não-privilegiado e o processo privilegiado, como pode ser visto.

Figura 4.1: Proposta de Secure-CompApp

Fonte: Do autor

A proposta é inserida como elemento intermediário de uma aplicação compartimen-talizada, como podemos ver na segunda parte da Figura 4.1. Assim, os canais IPC não maissão estabelecidos diretamente entre os compartimentos e sim serão estabelecidos pelo monitorde referência Secure-CompApp. O Secure-CompApp não só passa a ser o responsável porestabelecer os canais IPC como também passa a gerencia-los.

A intuito de se usar esta estrutura centralizada é de ter um processo exclusivo e especi-alizado na segurança da aplicação. Neste elemento é possível então agregar diferentes rotinasque garantam a segurança da aplicação. Como por exemplo, seria possível inserir módulos quegarantam: a integridade dos dados, confidencialidade dos dados, a disponibilidade dos processosassociados, detecção de comportamento anômalo, etc. Ou seja, é possível inserir vários tipos deesquemas de segurança sem sobrecarregar um processo privilegiado.

Diferente das abordagens mais comuns compartimentalizadas (vide primeira parte daFigura 4.1), esta abordagem isola um processo só para a função de gerenciar as ações da aplicaçãoe não deixar o processo privilegiado incumbido disto.

4.1. ESTRUTURA 42

Figura 4.2: Estrutura do Secure-CompApp

Fonte: Do autor

Os principais conceitos que nortearam a criação do Secure-CompApp foram:

� O padrão de segurança monitor de referência

� Um mecanismo de controle de acesso

� Uma gerencia sobre as comunicações inter-processos

� Um estrutura de reforço a auditória

O Secure-CompApp foi modelado de forma que os módulos não interajam entre si,tendo o monitor de referência como orquestrador de todos os módulos. Esta estrutura tem comoobjetivo garantir que o módulo do monitor de referência tenha o controle sobre o todo.

Como discutido na Seção 2.6, o módulo monitor de referência deve ter um conhecimentode um todo e operar como um elemento que aplica as regras de controle de acesso. Assim, todasas mensagens recebidas são primeiramente tratadas pelo monitor de referência que em seguidaencaminha para cada um dos módulos especializados, a fim de receber o tratamento adequado.

A estruturação da solução dentro dos cinco módulos (Figura 4.2) foi de forma a cobrir oconceitos sobre a qual a solução foi concebida.

O primeiro módulo a ser iniciado é exatamente o cerne do Secure-CompApp, o módulomonitor de referência. Este módulo dá início a execução dos demais módulos. O módulo seguinteque deve ser inicializado é o módulo de Log, que registra todas as ações da aplicação desde a suainicialização. Em seguida os módulos de criptografia, controle de acesso e controle de processossão inicializados.

O módulo de criptografia deve agregar as rotinas de segurança. Nesta proposta estemódulo tem como responsabilidade garantir os pilares de autenticação e integridade, e isto está

4.2. CONTRAMEDIDAS AOS ATAQUES 43

associado ao uso de um esquema de chaves públicas. Este módulo cria e gerencia o par dechaves assimétricas, onde os processos de uma aplicação devem estar de posse da chave pública,enquanto o Secure-CompApp estará de posse da chave privada.

O módulo de controle de acesso deve possuir um modelo de controle de acesso onde ocomportamento padrão de decisão seja de proibir qualquer ação que não tenha sido explicitamentedeclarada. Este comportamento é fundamental para a mitigação das vulnerabilidades que ocorremvia canais IPC. Além disto, este módulo também deve executar em seu conjunto de regras umasérie de verificações a fim de encontrar inconsistências entre as regras que gerem brechas paraataques, como por exemplo o Collusion Attack.

Por fim, o módulo de controle de processos é responsável por gerenciar os processos quecompõem a aplicação. Gerenciando comportamento e disponibilidade dos mesmos.

4.2 Contramedidas aos Ataques

A aplicação do PoLP tem sido a principal forma para mitigar os ataques de escalaçãode privilégios, entretanto, os canais IPC tem servido como porta de entrada para a execução deataques de escalação de privilégios de forma bem sucedida. Os ataques em questão são Confused

Deputy Attack e Collusion Attack.A estrutura do Secure-CompApp força algumas restrições que visam minimizar os

ataques em questão. O elemento intermediário que executa a função de controle de acesso é oresponsável por forçar tais restrições.

O Confused Deputy Attack (explicado na Seção 2.4.1) é um ataque que se aproveita deinterfaces confusas e mal definidas de uma aplicação. Este ataque é combatido pela ação de doismódulos que compõem o Secure-CompApp: módulo de Gerenciamento de Políticas e Controlede Acesso, e módulo de Criptografia.

O módulo de controle de acesso visa restringir os tipos de interações das interfaces decomunicação IPC, isso por ter um comportamento proibitivo padrão para as ação não definidas noconjunto de regras. Este comportamento almeja restringir e bloquear qualquer tipo de requisiçãonão autêntica que possa vir a passar pelo monitor de referência. Já o módulo de criptografiaalmeja com seu esquema de chave pública impossibilitar a interação direta entre um elementonão autêntico e um processo autêntico que compõem a aplicação. Forçando sempre que umarequisição passe pelo monitor de referência e seja analisada pelo módulo de controle de acesso.

Por fim, o Collusion Attack (explicado na Seção 2.4.2) é um ataque que explora atransitividade entre processos autênticos. Este ataque também é combatido pela ação dos doismódulos que compõem o Secure-CompApp: módulo de Gerenciamento de Políticas e Controlede Acesso, e módulo de Criptografia.

O módulo de criptografia atua da mesma forma discutida acima. Com o uso do seuesquema de chave pública, a solução visa impossibilitar a interação direta entre um elementonão autêntico e um processo autêntico que compõem a aplicação. O módulo de controle de

4.3. PROVA DE CONCEITO 44

acesso atua de forma diferente contra este ataque. Por se tratar de um ataque de difícil detecçãoe mitigação, o Secure-CompApp propõem checar no ato da inicialização da aplicação regras quepermitam a existência de transitividade. Este tipo de par de regras deve ser evitado.

4.3 Prova de Conceito

O Secure-CompApp é um conceito de monitor de referência dedicado a uma aplicação.Desta forma ele detém um domínio de aplicação específico permitindo que o monitor possuaregras exclusivas para definir o comportamento entre os processos. Sua implementação foiconcebida seguindo os padrões de segurança Monitor de Referência.

A solução gerencia o canal de comunicação IPC criado interceptando os dados doprocesso de origem, aplicando regras de acesso sobre o dado e encaminhando a mensagem parao processo destino (Figura 4.3). Como prova de conceito o Secure-CompApp foi implementadoem Java e o mecanismo IPC utilizado foi Socket UNIX. A entidade responsável por gerenciar eaplicar o conjunto de regras é o Organization-based Access Control (OrBAC).

Cada processo possui um conjunto de privilégios que justifica a sua separação. Ainteração entre todos os processos é dado pelo mecanismo IPC Socket UNIX. Os dados queantes iriam direto do processo 01 para o processo 03 agora têm como intermediário o monitorde referência, vide Figura 4.3. Os dados são enviados ao monitor que trata de avaliar parâmetroscomo origem de mensagem, destino da mensagem e o tipo da ação. Dentro do módulo doMonitor de Referência a mensagem é analisada. O monitor faz a requisição ao módulo dasRegras que então responde ao monitor se a ação é permitida ou proibida. Em caso de permitida amensagem é encaminha para o processo destino. Em caso de proibida o monitor, além de nãoencaminhar a mensagem, também notifica dois módulos da solução: módulo de Log e o módulode Controle de Processos.

O módulo de Log tem a função de registrar os eventos do Secure-CompApp, estesregistros são importantes para caso o usuário queira auditar o comportamento dos processos, osregistros de logs irão auxiliar nesta auditoria. Já o módulo de Controle de Processos é responsávelpor gerenciar todos os processos pertencentes à aplicação. Além destes módulos há também omódulo de Segurança que tem a responsabilidade de dar as garantias de segurança: garantia deautenticidade dos processos e garantia de integridade dos processos da aplicação.

Um dos grandes papéis do módulo Monitor de Referência é ser o cerne da aplicação,capaz de interagir diretamente com os demais módulos e responsável pela orquestração dosmesmos, fazendo com que o fluxo de informação sempre chegue ao módulo correto.

A seguir serão detalhados os três módulos que interagem com o monitor de referência,além do próprio módulo central que é o monitor de referência.


Figura 4.3: Abstração do Secure-CompApp

Fonte: Do autor

4.3.1 Módulo Monitor de Referência

Constitui o elemento central capaz de interagir diretamente com os demais módulos. Omonitor de referência gerencia as conexões IPC e seus tráfegos, aplicando regras e garantindoencaminhamento correto e seguro das mensagens. Ao inicializar a aplicação, o monitor dereferência impõem uma sequência de passos que reforça o processo de autenticação padrão domecanismo IPC Socket UNIX.

Este módulo faz com que a solução Secure-CompApp opere como um elemento servi-dor que espera por requisições de conexões dos processos compartimentalizados, assim estesprocessos compartimentalizados operam como clientes. Em seu estado inicial do processo deautenticação o servidor aguarda requisições do cliente, cuja máquina de estados está expressa naFigura 4.4. Ao receber uma requisição (Figura 4.6), o servidor invoca o Módulo de Segurança(Seção 4.3.4) que executa os procedimentos de checagem de integridade do processo. O monitorde referência verifica em seu repositório se o valor hash para aquele processo ainda se mantém.


Figura 4.4: Máquina de estado do Servidor

Fonte: Do autor

Em caso de um processo íntegro o servidor então compartilha a chave pública com ele e adicionao processo à sua lista de processos. Se o processo não estiver íntegro a conexão é finalizada e oservidor retorna ao seu estado inicial de aguardar novas conexões.

Figura 4.5: Máquina de estado do Cliente

Fonte: Do autor


A máquina de estados do processo de autenticação do cliente apresenta um fluxo simples(Figura 4.5). O cliente requisita conexão, caso o servidor aceite a conexão lhe é enviada achave pública que será usada para assinatura digital das mensagens. Em caso de o servidor nãoresponder, o cliente então volta ao seu estado inicial. Ao recever a chave pública o cliente enviauma confirmação ao servidor e finaliza o protocolo, estabelecendo assim o canal IPC.

Todos os formatos de mensagens criados para a solução são detalhados abaixo. Foramestruturados três tipos de mensagens: Mensagem de Requisição de Conexão (Figura 4.6),Mensagem de Resposta a Requisição (Figura 4.7) e Mensagem de troca de Conteúdo (Figura 4.8).

Abaixo seguem os formatos das mensagens e a definição de cada campo da mensagem.

Figura 4.6: Formato da mensagem de requisição do processo ao monitor de referência

Fonte: Do autor

� Mensagem de Requisição de Conexão (Figura 4.6)

- Type: especifica o tipo mensagem de requisição de autenticação

- Size: define o tamanho total da mensagem

- PID: especifica o PID do processo que requisita autenticação

- Alias Process PID: define um nome genérico do processo. Este nomegenérico é definido pelo desenvolvedor e deve ser único, pois servirá paraa mensagem de conteúdo para endereçar o destino da mensagem, apesardo PID ser um identificador único é um elemento desconhecido até obootstrap da aplicação

Figura 4.7: Formato da mensagem de resposta do monitor de referência ao processo

Fonte: Do autor


� Mensagem de Resposta a Requisição (Figura 4.7)

- Type: especifica o tipo mensagem de resposta à uma requisição de auten-ticação


- Reserved: campo separado para futuras extensões

- Public Key: chave pública

� Mensagem de troca de Conteúdo (Figura 4.8)

- Type: especifica o tipo mensagem que transporta o conteúdo entre osprocessos


- Reserved: campo separado para futuras extensões

- Destination Alias Process PID: nome genérico do processo definido pelodesenvolvedor que especifica o destino da mensagem

- Origin Alias Process PID: nome genérico do processo definido pelodesenvolvedor que especifica a origem da mensagem

- Digital Signature: assinatura digital gerada pelo módulo criptográfico

- Content: conteúdo da mensagem

Figura 4.8: Formato da mensagem trocada entre os processos

Fonte: Do autor


4.3.2 Módulo de Controle de Processos

Este módulo é incumbido de gerir os processos da aplicação. Ele observa continuamenteo comportamento dos processos avaliando alguns parâmetros coletados:

� Variação de consumo de memória

� Variação de consumo de processamento

Esses dados coletados são organizados pelo Controlador de Processos e em seguidasão enviados para o monitor de referência que registrará nos logs. O intuito em coletar essesdados é registrar o comportamento de cada processo. Mantendo essas informações em registro émelhorado a rastreabilidade da aplicação, facilitando assim possíveis auditorias executadas pelodesenvolvedor.

Além destas funções passivas (as funções de medições citadas acima), este módulopossui funções de caráter atuante sobre os processos. Trata-se de funções que visam parar oureexecutar processos associados à aplicação, conforme decisão do monitor de referência.

O módulo de Controle de Processos interage com o sistema operacional e não diretamentecom os processos. É através de chamadas de funções ao sistema operacional que são feitasverificações e intervenções aos processos correntes.

4.3.3 Módulo de Gerenciamento de Políticas de Controle de Acesso

O OrBAC é um modelo de controle de acesso onde as políticas são especificadas em umnível abstrato, tornado-se independente de qualquer tipo de implementação. Ele é uma expansãodo modelo de controle de acesso Role-based Access Control (RBAC) que permite gerir de formasimples e compacta as políticas de acesso. O OrBAC disponibiliza um framework para analisare resolver conflitos onde regras são especificadas através de uma linguagem eXtensible Access

Control Markup Language (XACML), este recurso de resolução de conflitos acaba tornando-sede alta complexidade em outras linguagens.

Na Figura 4.9 é possível ver a distinção do nível abstrato do nível concreto. O nívelconcreto é composto pelas entidades concretas: Subject, Actions e Objects. Enquanto o nível abs-trato é composto pelas entidades abstratas: Role, Activity e View. O Context e a Organization sãoentidade que possibilitam a dinamicidade das regras, dependendo do Context e da Organization

uma permissão/proibição pode mudar para uma tupla Subject, Action e Object.Devido a sua flexibilidade o OrBAC pode ser modelado para se adaptar a qualquer

ambiente, o que representa uma vantagem sobre outros modelos como por exemplo Discretionary

Access Control (DAC). Na literatura há exemplos de autores que mostraram como é possíveladaptar a regras do OrBAC a cenários diversos, como por exemplo para redes (Titov; Zaborovsky,2010; Cuppens et al., 2005) ou até mesmo modelar o OrBAC como um MAC (Benferhat;Bouriche; Ouzarf, 2011). Dentre eles há trabalhos que a propõem usar o dinamismo das regras


Figura 4.9: Estrutura organizacional do OrBAC

Fonte: Adaptado de ORBAC (2013)

do OrBAC aplicado sobre as Java Virtual Machine (JVM) (Autreal; Cuppensboulahia; Cuppens,2013).

O OrBAC foi integrado através de sua API em Java. Dadas as entidades que compõem oseu modelo de controle de acesso foi preciso adaptá-las ao cenário. Assim, para que suas regrasfossem aplicadas ao ambiente, as entidades foram usadas da seguinte forma:

� Subject é a entidade que representa os processos correntes pertencentes à aplicação

� Actions é a entidade que representa o conjunto de operações do Sistema Operacionalcabíveis à aplicação

- Ler, escrever, enviar, etc

� Objects é a entidade que representa o alvo da ação

- Arquivo, diretório, outros processos, etc

� Organization é a entidade que define o hospedeiro

4.3.4 Módulo de Criptografia

As responsabilidades sobre a segurança estão centradas neste módulo, tendo o objetivo degarantir a integridade dos processos e dependências associados a aplicação, além da autenticidadedas mensagens trocadas entre os processos compartimentalizados.

No processo de inicialização da aplicação este módulo faz uma checagem de integridadedos processos que serão executados e também dos arquivos que compõem a aplicação. Isto inclui


garantir que o arquivo que contém as políticas do sistema sempre estará integro. O algoritmode hash SHA-256 foi usado para garantir que os processos estarão íntegros sempre. Em casode inconsistência nas assinaturas o módulo de Log é notificado para registrar a ocorrência eaplicação não é executada.

A autenticidade das mensagens é atestada a partir do uso de uma assinatura digital. Oesquema de chave pública Rivest-Shamir-Adleman (RSA) (Jonsson; Kaliski, 2003) com umachave de 1024 bits é usado com o algoritmo de hash SHA-256. O módulo de Criptografia fica deposse da chave privada enquanto que cada processo íntegro faz uso de uma única chave pública.

4.3.5 Módulo de Log

O módulo de Log fica unicamente incumbido de gerar os relatórios de comportamentoda aplicação. Tanto os eventos anômalos detectados pelo monitor de referência são relatados aeste módulo como também estatísticas do comportamento da aplicação. Os relatórios geradossão de grande importância para o aumento da auditoria da aplicação e também para o aumentoda rastreabilidade.

As mensagens reportadas foram modeladas para conter um corpo comum para os cincotipos diferentes de mensagens que podem ser registradas. A parte comum a todos é a presença deum timestamp da mensagem e um nível que classifica aquela informação. Os níveis são divididosentre: Grave (SEVERE), Aviso (WARNING), Informação (INFO), e Configuração (CONFIG).

Já os tipos das mensagens são categorizados dentro das seguintes operações:

� Inicialização dos Módulos: é registrado o instante em que a aplicação é criada, alémdo PID que define o processo da solução Secure-CompApp

� Interação entre os Processos: as mensagens trocadas entre processo são registradastambém. Para cada tipo de interação definida deve haver regras associadas, sejamelas permissivas ou proibitivas. Caso aquele tipo de interação possua uma regrapermissiva associada a mensagem é então analisada pelo monitor de referência e gerauma entrada no arquivo de log com informações de processo origem da mensagem eprocesso destino da mensagem

� Bloqueio de Interação entre os Processos: caso aquele tipo de interação não possuauma regra permissiva associada, a mensagem é então descartada pelo monitor dereferência e gera uma entrada no arquivo de log com informações do possível processoorigem da mensagem e o possível processo destino da mensagem

� Estatísticas dos Processos: periodicamente o módulo de controle de processos exe-cuta checagens de consumo de memória e processamento de cada um dos processos.Essas informações são então periodicamente registradas

4.4. DISCUSSÃO 52

� Vulnerabilidade nas Regras: no ato da inicialização da aplicação é executado umaverificação no arquivo de políticas. Caso seja encontrada alguma brecha para oCollusion Attack, a aplicação não será executada, além disso é gerada uma entradapara a ocorrência.

4.4 Discussão

Por se tratar de uma abordagem diferente das demais apresentadas na literatura, o Secure-CompApp tanto traz vantagens como também é possível destacar desvantagens neste esquema. Aseguir será discutido e destacado os aspectos positivos e negativos da solução Secure-CompApp.

4.4.1 Vantagens

Devido às restrições impostas pela estrutura do Secure-CompApp é possível destacar duasgrandes vantagens em relação a outros trabalhos da literatura: capacidade de mitigar os ataquesde escalação de privilégios provenientes dos canais de comunicação IPC, o fortalecimento dopilar de auditória do PoLP.

O uso de um monitor de referência que gerencia toda a aplicação, e junto a ele umsistema de controle de acesso mais restritivo, mitigam os ataques de Confused Deputy Attack.Isto porque as interfaces de comunicação IPC não mais passam a receber qualquer tipo requisiçãode qualquer processo. O controle sobre os dados fica mais rigoroso, o que dificulta a ocorrênciadeste tipo de ataque.

O esquema de assinatura digital das mensagens trocadas garante que os processos nãotroquem tais dados diretamente entre si. Apenas Secure-CompApp fica de posse da parte privadada chave assimétrica, forçando assim que as mensagens assinadas pelos processos sempre tenhamque passar pelo monitor para que a assinatura seja validada e atualizada.

Além disto, as rotinas de inicialização e checagens executadas pelo monitor de referênciamitigam os ataques de Collusion Attack. Como já relatado em seções anteriores, este ataque éde difícil detecção e mitigação. Assim, o Secure-CompApp visa evitar a criação de regras quepermitam a transitividade.

As rotinas citadas acima não estão presentes em outros trabalhos da literatura, represen-tando assim uma vantagem inserida por essa solução no contexto de separação de privilégios.

4.4.2 Desvantagens

O Secure-CompApp, por ser uma solução centralizada, acaba ganhando maior destaquecomo alvo em possíveis ataques. Esta estrutura centralizada que coordena a interação dosprocessos da aplicação agregou muitas vantagens, entretanto, por ser o cerne da aplicação, oSecure-CompApp pode ser alvo de ataques que almejam comprometer o impedir o funcionamentoda aplicação.


Um dos possíveis ataques mais prováveis de ocorrer são aqueles que comprometem adisponibilidade da aplicação, como por exemplo ataques de Denial of Service (DoS). Outrapossibilidade são ataques que tentem corromper as rotinas de segurança do Secure-CompApp,como por exemplo ataques que atentem contra a integridade dos dados ou da própria chaveassimétrica, compartilhada entre processos autênticos.

4.5 Recapitulação

Fundamentado sobre o princípio da execução monitorada da separação de privilégios, asolução Secure-CompApp almeja mitigar os ataques de escalação de privilégios provenientesdas interfaces de comunicação IPC. Também é propósito desta solução melhorar a auditoria eprocessos de rastreabilidade dentro da aplicação, fortalecendo assim alguns pilares do PoLP.

Inserido como um elemento intermediário em uma aplicação compartimentalizada oSecure-CompApp é responsável por criar e gerenciar os canais de comunicação IPC de aplicaçõesparticionadas. Operando como um elemento centralizado a solução pode agregar vários módulosde segurança a fim de aumentar as garantias de segurança.

O Secure-ComApp foi estruturado de forma a aplicar a restrições necessárias para mitigaros ataques de escalação de privilégios e aumentar os processos de auditoria e rastreabilidade. Osmódulos de monitor de referência, gerencia de políticas de controle de acesso, log, criptografia econtrole de processos integram esta solução.

Como prova de conceito a solução foi implementada em linguagem de alto nível Java, oscanais foram estabelecidos através de Socket UNIX e o modelo de controle de acesso utilizadofoi o OrBAC.

No próximo capítulo será dissertado sobre a metodologia de avaliação da proposta. Serádissertado sobre o ambiente de avaliação, métricas coletadas e cenários utilizados na validaçãoda solução.

545454

5Avaliação

Como prova de conceito a solução proposta Secure-CompApp foi implementada eavaliada em ambiente real, toda a implementação segue a estrutura discutida na Seção 4.3.

Neste capítulo serão apresentadas as variáveis de performance do Secure-CompAppusadas para avaliar o impacto causado pela inserção da solução dentro da aplicação. Tambémserá apresentado as configurações do ambiente de teste e dos cenários criados para execução eavaliação da solução.

5.1 Metodologia

5.1.1 Ambiente

O Secure-CompApp foi implementado em ambiente real. Assim, a prova de conceitofoi desenvolvida dentro do sistema operacional Ubuntu 12.04.5 LTS, arquitetura de 64 bits e aversão do kernel 3.2.0-97.

A máquina que hospedou os experimentos possui um processador Intel Core i7-2600com 8 núcleos e o processador operando em uma frequência de 3.40GHz.

5.1.2 Métricas

A execução da solução Secure-CompApp é composta por três grandes etapas: o processode bootstrap, o processo de handshake e a troca de mensagens. As métricas utilizadas devemobter informações suficientes para mensurar o impacto causado pelas camadas de segurançainseridas pela solução. Elas serão aplicadas em dois cenários conforme será apresentado naSeção 5.1.3, para que fique claro ao leitor a diferença de performance.

Todavia, foi feita também uma análise que nos mostrará os benefícios resultantes douso da solução, foram utilizadas mais duas métricas. Primeiramente, foi medida a capacidadede expansão de uma aplicação que utiliza a solução Secure-CompApp e o descarte de pacotesassociado a esses cenários mais extensos, ou seja, com maiores números de processos com-partimentalizados. Por fim, foi medido o quanto pode ser mitigado das vulnerabilidades de

5.1. METODOLOGIA 55

Confused Deputy Attack e Collusion Attack. Desta forma foi avaliado o comportamento doSecure-CompApp e seus laudos gerados ao perceber uma tentativa de interação entre processosonde não há regras associadas que permitam tal interação. A seguir, a descrição de cada uma dasmétricas utilizadas.

5.1.2.1 Tempo de bootstrap

O tempo de bootstrap é definido (Souto et al., 2012) como o intervalo de tempo queleva para uma rede e seus nós alcançarem a configuração final. Neste trabalho este intervalode configuração do ambiente é constituído pela inicialização das rotinas de segurança peloSecure-CompApp. As rotinas que compõem esta métrica são: geração do par de chaves de 1024bits com RSA, inicialização do sistema de políticas, e inicialização do canal de comunicação.

5.1.2.2 Tempo de handshake

A métrica de handshake (Gupta et al., 2002) é bastante utilizada para verificar o tempo queum protocolo demanda para fazer um troca de parâmetros de configuração ou troca de recursosde segurança, como: chaves simétricas, chaves assimétricas, ou parâmetros de criptografia.

Neste trabalho as etapas de segurança que compõem o protocolo de handshake são:verificação integridade dos processos que requisitam comunicação, envio da chave públicaao processo autenticado, e inserção do socket do processo à pilha de sockets dos processosautenticados.

5.1.2.3 Tempo de delay

O tempo demandado para que uma mensagem saindo de sua origem seja entregue aodestino é mensurada por uma métrica de delay (Wang; Xiong; Liu, 2013). Há vários fatores queimpactam neste tempo, como por exemplo etapas como marshall da mensagem, a latência dosocket, e etc.

Neste trabalho, além das etapas citadas que impõem atrasos nas mensagens, tambémserão levadas em conta nesta métrica: checagem e validação da assinatura digital, e verificaçãode política associada.

5.1.2.4 Escalabilidade

Compartimentalização significa que os componentes de uma aplicação são executadosem compartimentos isolados uns dos outros. Assim, a Compartimentalized Metric (Almorsy;Grundy; Ibrahim, 2013) pode ser medida pelo número de componentes independentes que podemser executados sem interferir no comportamento do outro.

Nesta avaliação será apresentado a capacidade de expansão do número de processosassociados ao Secure-CompApp, mostrando que a estrutura da solução pode comportar aplicações

5.1. METODOLOGIA 56

com uma alta granularidade de compartimentos. Junto a isto, será então medida a perda depacotes ocasionada pela expansão do cenário.

5.1.2.5 Contramedidas aos Ataques

As análises de segurança (Wu et al., 2013) irão avaliar a capacidade da solução Secure-CompApp de mitigar os ataques de Confused Deputy Attack e Collusion Attack. Será discutido areação da solução diante de processos que tenham um comportamento anômalo que induzem aosataques listados.

Os registros dos ataques serão mostrados no arquivo de log gerado pela solução comoprova de ataques mitigados.

5.1.3 Cenário

Foram criados três diferentes cenários. O primeiro cenário constitui uma aplicaçãocomposta por três processos e o Secure-CompApp intermediando as ações (Figura 5.2). Aoprocesso 1 foi atribuído o privilégio de manipulação de arquivo, enquanto que os demaisprocessos deste cenário enviam mensagens com um conteúdo aleatório a ser escrito no arquivoatravés do processo privilegiado. Neste cenário foram coletadas as métricas de bootstrap ehandshake seguindo os parâmetros definidos na Tabela 5.1.

Tabela 5.1: Parâmetros de simulação no cenário da Figura 5.2

Parâmetros ValoresDuração da simulação 30 sNúmero de simulações 100

O tempo de bootstrap é coletado a partir do momento em que todas as rotinas deinicialização são concluídas, uma rotina de registro de tempo foi fixada dentro da solução nosseguintes pontos: geração do par de chaves, inicialização do sistema de políticas e inicializaçãodo canal de comunicação. Em seguida o tempo de handshake é coletado para cada um dosprocessos que executa o procedimento de autenticação no Secure-CompApp. Assim, a rotina deregistro de tempo foi fixada dentro dos processos que irão se autenticar no Secure-CompApp.

Para a métrica de delay foram utilizados dois cenários: o cenário 01 (Figura 5.2) que temcomo elemento intermediário o Secure-CompApp e o cenário 02 (Figura 5.3) que representa amesma aplicação do cenário 01 porém sem o Secure-CompApp. Ambos os cenários seguem osparâmetros definidos na Tabela 5.2. Para fins de validação os processos privilegiados possuemprivilégios de escrita em arquivo e os processos não-privilegiados enviam em suas mensagens umconteúdo randômico a ser escrito em tais arquivos. Além disto foram definidas regras permissivasno OrBAC para todos os processos (Figura 5.1).

5.1. METODOLOGIA 57

Figura 5.1: Regras criadas na ferramenta MotOrBAC para o cenário 01

Fonte: Do autor

Figura 5.2: Cenário simples com a solução Secure-CompApp

Fonte: Do autor

Nestes dois cenários os processos irão se comportar da seguinte forma: os processosnão-privilegiados enviam as mensagens ao processo privilegiado com um conteúdo de escrita,assim a rotina de registro de tempo é fixada dentro do processo origem e do processo destino.Desta forma, então, foi possível coletar o atraso sofrido pela mensagem com a inserção do nóintermediário Secure-CompApp.

O primeiro cenário (Figura 5.2) também será utilizado para validar o comportamento doSecure-CompApp contra os ataques desenhados contra o PoLP neste cenário o último processoinserido irá seguir um comportamento malicioso. Será analisado o comportamento da soluçãodiante de cada um dos ataques. Foram definidas regras permissivas entre Processo 2 e Processo1, e regras proibitivas entre Processo 3 e Processo 1 (Figura 5.1).

Por último, o cenário 01 foi estendido para provar a robustez da aplicação, como definidona Figura 5.4. O cenário será expandido a cada interação e será avaliado o descarte de pacotes

5.1. METODOLOGIA 58

Figura 5.3: Cenário simples sem a solução Secure-CompApp

Fonte: Do autor

Tabela 5.2: Parâmetros de simulação para avaliação do delay das mensagens nos cenáriosdas Figuras 5.2 e 5.3

Parâmetros ValoresTamanho da Mensagem 128 bytesPeríodo de envio das Mensagens 100 msDuração da Simulação 300 sNúmero de Simulações 100

pelo Secure-CompApp devido ao uso intenso do barramento e dos sockets associados. Foramdefinidas regras permissivas no OrBAC para todos os processos.

O número de nós no cenário será expandido a cada interação. Serão avaliados quatrocenários:

� Cenário Estendidos 01 composto por 02 (dois) processos

- Processos privilegiados: 01

- Processos não privilegiados: 01

� Cenário Estendidos 02 composto por 04 (quatro) processos



5.1. METODOLOGIA 59

Figura 5.4: Cenário extenso com a solução Secure-CompApp

� Cenário Estendidos 03 composto por 08 (oito) processos



� Cenário Estendidos 04 composto por 16 (dezesseis) processos



Na tentativa de simular algo mais factível quanto ao número de processos comparti-mentalizados o tamanho máximo do cenário foi então limitado. Já a distribuição dos processosentre "privilegiado"e "não-privilegiado"foi uma amostra o quão escalável é o Secure-CompApppossibilitando gerenciar os mais diversos cenários. Na Tabela 5.3 está descrito os parâmetros desimulação que foram utilizados.

Tabela 5.3: Parâmetros de simulação para avaliação da escalabilidade no cenário daFigura 5.4

Parâmetros ValoresTamanho da Mensagem 128 bytesFrequência de envio das Mensagens 100 msDuração da simulação 300 sNúmero de simulações 100

5.1. METODOLOGIA 60

Figura 5.5: Regras criadas na ferramenta MotOrBAC para os cenários estendidos

Fonte: Do autor

616161

6Resultados

Diante das abordagens presentes na literatura (Capítulo 3) esta dissertação propôs oSecure-ComApp (Capítulo 4) como forma de mitigar a vulnerabilidades que não foram até entãosanadas. Neste capítulo serão apresentados os resultados das avaliações definidas anteriormente(Capítulo 5).

Assim como os trabalhos da literatura discutidos, aqui será demonstrado o benchmark

obtido a partir das avaliações executadas. Os resultados serão discutidos entre as soluçõesdo mesmo ambiente (Seção 3.1.3) correlacionando o desempenho, mitigação de ataques ediferenciais da solução.

6.1 Bootstrap

O processo de inicialização do Secure-CompApp é composto pelo carregamento dealguns módulos. Dentre os módulos que mais impactam no valor desta métricas estão a criaçãodo par de chaves, o carregamento das políticas e a criação do canal de comunicação, em ordemdecrescente de impacto. A métrica de bootstrap não apresentou pertencer a nenhuma distribuiçãoestatística e os resultados podem ser observados na Tabela 6.1 e na Figura 6.1.

Para melhor avaliação esta métrica foi destrinchada de forma a destacar o impactocausado pelas principais etapas que compõem o processo de bootstrap, conforme as Tabelas 6.2,6.3 e 6.4 e Figura 6.2.

Tabela 6.1: Estatísticas do bootstrap

Parâmetro Tempo (ms)Máximo 1207.0Média 1065.0Mínimo 951.0Desvio Padrão 45.47616

O processo de geração de par de chave RSA apresentou o maior custo de tempo. Isto eraesperado em virtude de processos criptográficos que envolvem esquema de chave pública serem

6.1. BOOTSTRAP 62

Figura 6.1: Análise de tempo do protocolo de bootstrap

Figura 6.2: Análise das etapas que compõem o bootstrap

bastante custosos, conforme pode ser visto na Tabela 6.2. A escolha da chave de tamanho 1024bits foi concebida já como forma de minimizar este impacto ao invés do uso de chaves maiores,mas é inevitável não ter este alto custo associado. Quanto maior for o nível de segurança usadomaior será o custo de tempo e processamento exigido para estas operações criptográficas.

A etapa de carregamento das políticas tem como objetivo fazer uso da API do OrBAC,carregar o arquivo de políticas e, por fim, executar um processo de checagem sobre o conjunto

6.1. BOOTSTRAP 63

Tabela 6.2: Estatísticas do bootstrap: etapa degeração do par de chaves


Tabela 6.3: Estatísticas do bootstrap: etapa doesquema de políticas


de regras contido no arquivo. Esta API desenvolvida em Java não apresentou valores outliers,além de demonstrar uma baixa variação no tempo de criação e carregamento de uma instanciaOrBAC para gerenciar o arquivo de políticas. Diferente do que ocorre na etapa do Canal deComunicação, que é um etapa repleta de outliers. Os resultados obtidos nesta etapa podem servisualizados na Tabela 6.3.

O processo de inicializar o canal de comunicação cria o socket e a pilha de sockets

dos clientes. Trata-se do processo mais simples e rápido, pois não envolve nenhuma operaçãocriptográfica e nem muito menos carregamento de uma complexa API (como visto na Tabela6.4), entretanto esta etapa gerou muitos outliers (Figura 6.2).

Para permitir o uso de socket UNIX na linguagem Java utilizamos uma Java Native

Interface (JNI) chamada JUnixSocket 1. As medições sobre esta etapa foram obtidas atravésdo uso desta JNI. O surgimento dos outliers estão presentes no acesso ao barramento decomunicação no ato da criação dos canais IPC. Através da JNI JUnixSocket a aplicação fazuma requisição ao sistema operacional para ter acesso ao barramento de comunicação, assim,dependendo dos processos em background do SO que também requisitam acesso ao barramento,este tempo idle de acesso pode variar gerando os referidos outliers.

Tabela 6.4: Estatísticas do bootstrap: etapa de abertura do canal de comunicação


A rotina do bootstrap é executada uma única vez, no momento de inicialização daaplicação. Este custo fica limitado há apenas um instante e representa um impacto que surgecom qualquer rotina de segurança. Inclusão de sistemas de segurança tem um preço e tal preçofica bem perceptível (Tabela 6.1).

1https://github.com/kohlschutter/junixsocket

https://github.com/kohlschutter/junixsocket

6.2. HANDSHAKE 64

6.2 Handshake

O IPC Socket UNIX possui um mecanismo padrão de autenticação onde o cliente abreum socket com um servidor e envia através deste canal uma tupla com identificadores únicospara o servidor: PID, UID e GID. O processo de autenticação ocorre durante a troca da primeiramensagem entre cliente e servidor, porém isto não evita que um atacante forje estes parâmetrose nem impede que qualquer processo consiga obter conexão com o dado servidor. A soluçãoSecure-CompApp obriga cada processo a passar um protocolo de autenticação. A amostra segueuma distribuição Chi-Quadrado, Figura 6.3.

Tabela 6.5: Estatísticas do protocolo dehandshake com Secure-CompApp


Tabela 6.6: Estatísticas do protocolo dehandshake sem Secure-CompApp


Figura 6.3: Análise de tempo do protocolo de handshake

Conforme podemos ver nas Tabelas 6.5 e 6.6, a rotinas de handshake insere um atraso de500ms em relação ao processo default de um canal IPC. Entretanto, o tempo demandado paraautenticação é executado apenas uma vez por processo e é justificado por rotinas fundamentaisque garantem que apenas processo íntegros irão poder estabelecer comunicação. É no instante doprotocolo de autenticação que o Secure-CompApp atesta a integridade do processo e envia para

6.3. DELAY 65

Figura 6.4: Análise de delay das mensagens

ele a chave pública gerada no bootstrap. Ou seja, o tempo obtido é a composição da checagemdo hash SHA-256 e em seguida o tempo que o processo leva para carregar a chave pública eenviar a confirmação para o monitor de referência.

6.3 Delay

A troca de mensagens entre os processos privilegiados e os não-privilegiados é o eventomais repetido durante a execução da aplicação, se compararmos com as métricas medidasanteriormente que ocorrem apenas uma vez por execução. Um grande impacto sobre o tempo detransmissão destas mensagens poderia tornar inviável o funcionamento de uma aplicação. Cabeum estudo para avaliar as restrições temporais de cada uma das aplicações que fazem uso decompartimentalização de aplicações, mas isto vai além do escopo deste trabalho.

Os resultados obtidos para o cenários 01 (Figura 5.2) e o cenário 02 (Figura 5.3) podemser observados na Tabela 6.7 e Tabela 6.8, respectivamente.

Tabela 6.7: Estatísticas de delay das mensagenscom Secure-CompApp


Tabela 6.8: Estatísticas de delay das mensagenssem Secure-CompApp


6.3. DELAY 66

Figura 6.5: Análise das etapas delay das mensagens

Os processamentos executados pelo Secure-CompApp sobre os pacotes apresentaram umoverhead de mais 30ms na média em relação a transmissão de pacotes sobre o IPC. Dependendodas restrições temporais de cada aplicação este valor pode ser ou não ser aceitável. Na análiseestatística foram observados valores outlier que foram destrinchados a seguir em busca dejustificar os resultados obtidos.

Ao destrinchar as camadas de segurança há três etapas entre a transmissão e recepção deum pacote dentro do Secure-CompApp que devem ser detalhados, vide Figura 6.5:

� Gerenciamento da pilha de processos

� Operações criptográficas

� Checagem de regras

A interação entre a solução Secure-CompApp e os processos alocados é feita através deuma estrutura de dados em pilha e cada elemento da pilha possui uma referência para cada umdos processos alocados. Esta pilha é checada periodicamente pelo monitor de referência quecoleta as mensagens enviada por cada processo, executa as rotinas de segurança sobre elas e porfim encaminha cada mensagem para o seu destino.

Nesta etapa foi inserido um gargalo que impacta no tempo da mensagem, há um tradeoff

de economia entre processamento e delay da mensagem. Quanto maior for a frequência comque as mensagens são checadas maior será o consumo dos recursos do processador do host

pela solução. A frequência de checagem foi parametrizada e pode assim ser definida pelodesenvolvedor conforme a restrições de tempo e processamento da aplicação. Para nossa

6.4. ESCALABILIDADE 67

avaliação a periodicidade de checagem foi fixada em 50ms, assim é esperado que o tempomáximo que uma mensagem aguardaria dentro da pilha é limitado por este período.

As operações criptográficas executadas são de geração de uma assinatura digital everificação da assinatura digital da mensagem. Nesta etapa, o uso de uma chave RSA menortornou o processamento rápido, enquanto que as funções hash são bastante rápidas em relaçãoàs operações criptográficas, justificando assim a rápida geração e verificação das assinaturasdigitais. Entretanto esta etapa é também geradora de outliers nos resultados pois as funçõescriptográficas de geração e verificação das assinaturas digitais das mensagens exigem muitasoperações matemáticas complexas e custosas.

Por último há o processo de checagem de uma regra. Esta etapa mostrou ser um processorápido em relação as etapas anteriores. Porém, esta eficiência é proporcional ao número de regrascontidas no arquivo de políticas, já que a API do OrBAC fornece ao desenvolvedor uma lista deregras para operar. Ou seja, quanto maior o conjunto de regras mais tempo será demandado nestaetapa. A conceito do Secure-CompApp é ter um conjunto de regras que defina o comportamentode apenas uma aplicação e isto faz com que o conjunto de regras criadas seja sempre pequenoassim como o tempo de verificação.

6.4 Escalabilidade

O Secure-CompApp foi submetido a um teste de estresse onde em cada um dos cenáriosos processos trocaram pacotes em uma frequência alta. As avaliações nos mostraram que asmensagens descartadas pelo monitor foram todas a partir de inconsistência no processo deverificação da assinatura da mensagem. Como pode ser visto na Tabela 6.9, conforme o cenáriocresce a taxa de perda de pacotes também aumenta.

Tabela 6.9: Taxa média de perda de pacotes em cenários extensos

Cenário Taxa de Perda de Pacote (%)Estendido 01 0.429971Estendido 02 1.286829Estendido 03 3.861174Estendido 04 6.613135

A estrutura de ser um nó gerencial centralizado permite a solução Secure-CompApp teruma grande vantagem sobre uma aplicação que não usa esta solução. Pois em aplicações quenão utilizam desta estrutura, quanto maior for o número de compartimentos de uma aplicaçãomenos factível é o gerenciamento dos diversos canais entre eles. Fazendo uma analogia com ouso de chaves criptográficas, este problema se assemelha ao problema de gerenciamento de umgrande repositório de chaves simétricas, ou seja, quanto maior o número de chaves mais difícilfica o gerenciamento e uso das mesmas.

6.5. REDUÇÃO DE ATAQUES 68

Assim, para ser facilmente escalável, o Secure-CompApp foi implementado de formaa utilizar um único buffer para comunicação entre os vários processos e isto é o que permitede forma fácil adicionar inúmero processos a um aplicação compartimentalizada que utilizao Secure-CompApp. Entretanto, este teste de estresse mostrou que este buffer acaba ficandobastante poluído, gerando assim inconsistência nas mensagens.

Ou seja, a forma como o Secure-CompApp foi implementada permite ao desenvolvedorconectar vários processos entre si, abstraindo para ele a gerencia destes canais de comunicação.Entretanto, o uso extensivo deste mesmo canal de comunicação pode fazer com que o conteúdode um pacote enviado altere a integridade de um outro pacote.

6.5 Redução de ataques

Como dissertado na Seção 2.4, dois ataques foram desenhados para códigos que seguemo PoLP. Sobre o resultado obtido pelas tentativas destes ataques foi feito uma análise dasdetecções feitas pelo Secure-CompApp que notifica o usuário através do sistema de logs. Aseguir estão as análises para cada um dos ataques.

6.5.1 Confused Deputy Attack

A inserção do Secure-CompApp como elemento intermediário na estrutura obriga queapenas elementos íntegros e autênticos consigam interagir com os demais processos, isto jáminimiza a possibilidade deste tipo de ataque por um elemento malicioso. Além disto o sistemade políticas constitui uma camada de segurança que possibilita a definição das interações entre osmódulos. O desenvolvedor define suas políticas que são então carregadas pelo Secure-CompAppno momento do bootstrap, o monitor então fica responsável por aplicar as regras criadas.

As mensagens que não estavam especificadas nas regras permissivas do Secure-CompAppforam excluídas e o evento foi relatado ao módulo de Log, um trecho dos relatos podem serobservados na Figura 6.6. As mensagens que possuíam uma regra permissiva associada foramencaminhadas aos seus destinos. Todos os eventos, até mesmo os eventos de sucesso, sãorelatados ao sistema de log para futuras auditorias.

Figura 6.6: Arquivo de log com as ocorrências de fluxo não permitido

A camada de políticas representa um recurso que mitiga o Confused Deputy Attack desdeque as regras sejam bem definidas pelo desenvolvedor. Ter este sistema de políticas centralizadopara aplicação facilita o gerenciamento, garantindo assim que as regras sejam sempre aplicadas.

6.6. DISCUSSÃO 69

A ferramenta não cria regras automaticamente, fica a cargo do desenvolvedor criar oconjunto de regras que definam o comportamento da aplicação, porém, em caso de não existiruma regra para um determinado fluxo, o Secure-CompApp excluí as mensagens, pois ele adotauma posição de proibição por padrão do próprio OrBAC.

6.5.2 Collusion Attack

A camada de políticas não tem a capacidade de mitigar de forma automatizada o Collusion

Attack, entretanto, em meio às rotinas de checagem de integridade e carregamento do arquivode políticas é executado um mecanismo que checa a existência de transitividade no conjunto deregras. Desta forma o desenvolvedor é notificado no arquivo de log caso uma regra apresentepossibilidade de transitividade, o que permitiria o Collusion Attack. Como visto na Figura 6.7 oSecure-CompApp inseriu em seu arquivo de log uma notificação de transitividade, esta ocorrênciamostra que o par de regras permissivas p1 e p0 possibilita o Collusion Attack.

O processo 3 (pro3) possui permissão para interagir com o processo 2 (pro2) e o processo2 para interagir com o processo 1 (pro1), entretanto, apesar de não existir diretamente uma regrapermissiva de interação entre pro2 e pro1 há neste ponto uma transitividade que possibilita talinteração.

Figura 6.7: Arquivo de log com aviso de par de regras que permitem a transitividade

Assim como o OrBAC possui um mecanismo integrado para detecção de conflitos, oSecure-CompApp em sua camada de políticas disponibiliza este recurso para apontar as regrasque induzem a transitividade. O desenvolvedor deve então redesenhar seu conjunto de políticas afim de eliminar este problema.

6.6 Discussão

A solução Secure-CompApp será aqui discutida fazendo um paralelo entre ela e outrasquatro soluções propostas na literatura: ProgramCutter (Wu et al., 2013), ARBITER (Wang;Xiong; Liu, 2013), o trabalho de Trapp et al. (2015), e o Codejail (Wu et al., 2012).

Primeiramente, é importante ressaltar que nenhuma das soluções previamente citadaspossuem rotinas de bootstrap ou handshake. Estas etapas são causadoras de um grande impactono Secure-CompApp, entretanto, são nestas etapas em que são carregadas e executadas asprincipais rotinas de segurança da abordagem deste trabalho. O Secure-CompApp insere nãosomente checagens de integridade como também rotinas associadas a autenticidade de processos.


Todos os trabalhos tem uma grande preocupação em avaliar o overhead inserido no de-sempenho de uma aplicação. Coletando os valores de cada solução em seus trabalhos percebemosque a preocupação em obter melhores desempenhos é quantificado em seus resultados: Codejailobteve um overhead menor que 5%, ProgramCutter menos de 20%, ARBITER impactou em28% no tempo das chamadas das funções, e Trapp et al. atingiu um overhead de 11.3%.

Neste quesito o Secure-CompApp obteve uma performance muito inferior aos demaistrabalhos, chegando a impactar em 5 vezes no tempo de delay. Maior parte deste impacto estáassociado com o gerenciamento de uma pilha, que futuramente será melhorado. Outro fatotambém que deve ser observado é que o Secure-CompApp utiliza um esquema de assinaturadigital para garantir a integridade e autenticidade dos dados trocados nos canais, garantias estasque não estão presentes nas outras soluções.

Quanto a escalabilidade de cada uma das soluções, os particionadores automatizados(ProgramCutter, ARBITER, e o trabalho de Trapp et al.) não apresentam resultados que quanti-fiquem a granularidade da solução e também o impacto causado conforme sua granularidade.Este trabalho avalia esta métrica pois o PoLP garante que uma maior separação dos privilégiosprevinem mais ataques de escalação.

O último ponto a ser discutindo entre os trabalhos é a capacidade de mitigação dosataques de escalação de privilégios. Dos trabalhos citados apenas o CodeJail avaliou isto. Osautores do CodeJail analisaram que a solução seria efetiva contra dois tipos de ataques: ataquede corrupção de memória e ataque de execução de código arbitrário. Entretanto, os autores nãomencionam sobre a eficiência contra os principais ataques de escalação de privilégios: Confused

Deputy Attack e Collusion Attack.O Secure-CompApp tem como foco a mitigação destes ataques. Sua estrutura e módulos

foram propostos de forma a impor maiores restrições contra estes ataques e tais restrições nãoexistem nos demais trabalhos. Além disto, apenas o trabalho de Trapp et al. demonstrou umapreocupação sobre as vulnerabilidades expostas pelos canais de comunicação IPC. Com ummaior foco sobre tais vulnerabilidades, este trabalho propôs uma forma de mitigar os dois ataquesde escalação de privilégios.

É notório que esta solução apresentou uma performance inferior aos demais trabalhos,porém, é preciso destacar o foco dos trabalhos comparados não era a segurança. Assim, todasas rotinas inseridas em prol de mitigar os ataques tiveram um custo sobre a performance destasolução.

6.7 Recapitulação

Este trabalho gerou um benchmark para a solução Secure-CompApp e avaliou a escala-bilidade e capacidade de mitigação de ataques da solução. Tal benchmark foi composto pelostempos de bootstrap, handshake e delay.

O tempos de bootstrap e handshake alcançaram em média tempos de 1065ms e 608.6ms,


respectivamente. Tais métricas são referentes a execução e configuração das rotinas de segurançapresentes no Secure-CompApp. Assim, tal impacto é justificado pelas rotinas de segurança quemitigam os ataques provenientes do canal de comunicação IPC.

Quando comparado com outros trabalhos propostos na área, o tempo de delay inseridopela solução Secure-CompApp apresentou um impacto maior que os demais trabalhos, em médiade 41.51ms. Este tempo é composto por verificações de assinaturas digitais, aplicações derestrições do modelo de controle de acesso e reencaminhamento da mensagem. Tais etapas sãoresponsáveis por inserir tal gargalo mas são fundamentais para garantir integridade e autenticidadedas mensagens além de interfaces de comunicação IPC menos susceptíveis a ataques de escalaçãode privilégios.

Por fim, as análises de escalabilidade e mitigação de ataque apontaram para um soluçãoque comporta uma aplicação de alta granularidade, provendo mecanismos eficientes contra osdois ataques Confused Deputy Attack e Collusion Attack. Em prol de mitigar tais ataques, com oSecure-CompApp foi possível também aumentar a geração de registros de logs de uma aplicação,melhorando assim a rastreabilidade e a auditória da mesma, fortalecendo assim um dos princípiosdo PoLP.

727272

7Conclusão

A solução mais aplicada para mitigar ataques de escalação de privilégio é o PoLP.Este princípio propõe mitigar ataques de escalação de privilégios utilizando métodos paraparticionar os privilégios dentro de uma aplicação. Isolar os privilégios de uma aplicação emcompartimentos diferentes diminui o dano causado por um ataque de escalação bem sucedido.Assim, uma aplicação de estrutura monolítica é transformada em uma estrutura distribuídacomposta por vários compartimentos interconectados via canais de comunicação.

O uso de padrões de projeto de segurança constitui a principal forma de se aplicar esteprincípio na forma manual. Entretanto, devido à dificuldade de aplicar na forma manual, muitostrabalhos na literatura propuseram ferramentas automatizadas de particionamento a fim de tiraresta responsabilidade do desenvolvedor.

Seja o PoLP aplicado através de métodos manuais ou com o uso de ferramentas automati-zadas o CVE constatou um aumento de vulnerabilidades que permitem a escalação de privilégios.Estas vulnerabilidades tem se concentrado nas interfaces de comunicação IPC utilizadas para in-tegrar os compartimentos da aplicação e isto culminou no surgimento de dois ataques desenhadospara aplicações que implementam o PoLP: Confused Deputy Attack e Collusion Attack.

Focado em mitigar estes ataques de escalação de privilégios provenientes das interfacesde comunicação, este trabalho apresentou uma solução para aplicações compartimentalizadascapaz de gerenciar as interfaces de comunicação mitigando ataques e fortalecendo os princípiosde rastreabilidade e auditoria do PoLP. Este trabalho apresentou o Secure-CompApp, umaferramenta para auxiliar os desenvolvedores de código a produzir softwares compartimentalizadoscom canais comunicação IPC seguros.

Estruturado como um monitor de referência para a aplicação compartimentalizada, oSecure-CompApp insere camadas de segurança que impõem restrições à comunicação entre oscompartimentos da aplicação. Tais restrições são responsáveis por sanar as vulnerabilidadesgeradas pelo uso incauto dos canais de comunicação IPC.

Esta solução foi avaliada e um benchmark foi gerado. Foi constatado que os esquemas desegurança da solução impactaram bastante na performance da aplicação. Todavia, o uso dessasrotinas para garantir integridade e autenticidade aos dados trocados nos canais de comunicação e

7.1. CONTRIBUIÇÕES 73

aos processos associados permitiram ao Secure-CompApp alcançar seus objetivos.Assim, podemos concluir que o Secure-CompApp impõe um conjunto de restrições

capaz de mitigar os ataques de escalação de privilégios além de melhorar o processo auditoria ea rastreabilidade dentro de uma aplicação. Contudo, é inegável que há um trade off de maioresgarantias de segurança com menores níveis de performance na aplicação. Esta diminuição deperformance é maior que o de outros trabalhos, como também as garantias de segurança sãomaiores que o destes mesmos trabalhos.

Apesar do impacto causado pela solução ser justificado pelas rotinas de segurançaacreditamos que a solução ainda necessita de melhorias em seu desempenho. Esta e outrassugestões são abordadas na Seção 7.2.

7.1 Contribuições

O Secure-CompApp agrega as seguintes contribuições:

� Uma forma de gerenciar o IPC garantindo segurança para a aplicação

� Recursos para mitigar ataques a aplicações compartimentalizadas

- Confused Deputy Attack

- Collusion Attack

� Aumento de auditoria nas aplicações compartimentalizadas

� Garantias de integridade e autenticidade aos processo compartimentalizados

� Facilidades para estender o número de compartimentos por aplicação

7.2 Trabalhos Futuros

Este trabalho provou o conceito de execução monitorada para prover garantias de segu-rança aos canais de comunicação, entretanto, a soluções teve um impacto alto sobre a performancede uma aplicação compartimentalizada. Foi mostrado neste trabalho um impacto superior aoutras ferramentas de compartimentalização. Assim, há etapas e módulos que podem ser optimi-zadas para prover um melhor desempenho: bootstrap, handshake e delay. Uma das alternativaspara otimizar estes tempos é com o uso de melhores estruturas de dados para o cerne do monitorde referência.

Além disto, este trabalho demonstrou que a sua estrutura torna possível agregar outrosmódulos para aumentar as garantias de segurança. Como propostas futuras há a possibilidade deimplementar módulos baseado em rede neural, cada um com uma rede diferente, para avaliar ocomportamento de um processo e assim detectar um comportamento anômalo.

7.2. TRABALHOS FUTUROS 74

Por fim, outra proposta de trabalho futuro pensada é de dar maior poder de decisãoao monitor de referência visando sua aplicação em um cenário de grid. Em tais ambientes osprocessos de uma só aplicação são executados em diferentes hospedeiros, assim a proposta seriade dar ao Secure-CompApp recursos de containers para migrar processos de um hospedeiropara o outro. Esta ação seria realizada no caso do Secure-CompApp detectar que um hospedeiroesteja sendo atacado ou qualquer outro tipo de comportamento anômalo.

757575

Referências

ALMORSY, M.; GRUNDY, J.; IBRAHIM, A. S. Automated software architecture security riskanalysis using formalized signatures. Softw. Eng. (ICSE), 2013 35th Int. Conf., [S.l.],p.662–671, 2013.

ASHOOR, A. S.; GORE, S. Importance of Intrusion Detection system (IDS). InternationalJournal of Scientific and Engineering Research, [S.l.], v.2, n.1, p.1–4, 2011.

AUTREL, F.; CUPPENS-BOULAHIA, N.; CUPPENS, F. Enabling dynamic security policy inthe Java security manager. Foundations and Practice of Security, [S.l.], p.180–193, 2013.

BARAIYA, D.; DIWANJI, H. A Survey on Application Collusion Attacks on AndroidPermission-Mechanism. , [S.l.], 2015.

BENFERHAT, S.; BOURICHE, K.; OUZARF, M. Encoding default-based SELinux-securitypolicy in Organization-Based Access Control Model. 2011 Int. Conf. Internet Technol. Secur.Trans., [S.l.], n.December, p.608–613, 2011.

BITTAU, A.; MARCHENKO, P. Wedge: splitting applications into reduced-privilegecompartments. In: 5TH . . . . Proceedings. . . [S.l.: s.n.], 2008. p.309–322.

BLANKSTEIN, A.; FREEDMAN, M. J. Automating Isolation and Least Privilege in WebServices. In: IEEE SYMP. SECUR. PRIV., 2014. Anais. . . [S.l.: s.n.], 2014. p.133–148.

BRUNETTE, G. An Overview of Solaris 10 Operating System Security Controls. Security,[S.l.], p.1–44, 2007.

BUGIEL, S. et al. XManDroid: a new android evolution to mitigate privilege escalation attacks.Tech. Univ. Darmstadt, Tech. Rep., [S.l.], p.1 – 18, 2011.

BUGIEL, S. et al. Towards Taming Privilege-Escalation Attacks on Android. NDSS 2012 (19thNetwork and Distributed System Security Symposium), [S.l.], 2012.

BUYENS, K.; De Win, B.; JOOSEN, W. Resolving least privilege violations in softwarearchitectures. In: ICSE WORK. SOFTW. ENG. SECUR. SYST., 2009. Anais. . . [S.l.: s.n.],2009. p.9–16.

CARLINI, N.; FELT, A. P.; WAGNER, D. An evaluation of the google chrome extensionsecurity architecture. In: PRESENTED AS PART OF THE 21ST USENIX SECURITYSYMPOSIUM (USENIX SECURITY 12). Anais. . . [S.l.: s.n.], 2012. p.97–111.

CHEN, J.; TIAN, Z. Statistical Analysis of The Privilege Level of Vulnerability. Int. Symp.Comput. Informatics, [S.l.], 2015.

CHIONIS, I.; NIKOLOPOULOS, S.; POLENAKIS, I. A survey on algorithmic techniques formalware detection. , [S.l.], 2013.

CUPPENS, F. et al. A formal approach to specify and deploy a network security policy. FormalAspects in Security and Trust, [S.l.], p.203–218, 2005.

CVE. CVE-2011-4062. 2011.

REFERÊNCIAS 76

CVE. CVE-2011-3079. 2011.

CVE. CVE-2013-1537. 2013.

CVE. Microsoft: estatisticas de vulnerabilidades. 2015.

CVE. Linux: estatisticas de vulnerabilidades. 2015.

CVE. CVE-2015-7613. 2015.

FELT, A. P. et al. Permission Re-Delegation: attacks and defenses. Proc. 20th USENIX Conf.Secur., [S.l.], p.22–22, 2011.

GENEIATAKIS, D. et al. Adaptive defenses for commodity software through virtual applicationpartitioning. Proc. 2012 ACM Conf. Comput. Commun. Secur. - CCS ’12, [S.l.], p.133,2012.

GUDKA, K. et al. Exploring Compartmentalisation Hypotheses with SOAAP. In: IEEE SIXTHINT. CONF. SELF-ADAPTIVE SELF-ORGANIZING SYST. WORK., 2012. Anais. . .[S.l.: s.n.], 2012. p.23–30.

GUNADI, H.; TIU, A. Efficient Runtime Monitoring with Metric Temporal Logic: a case studyin the android operating system. FM 2014: Formal Methods, [S.l.], p.1–19, 2014.

GUPTA, V. et al. Performance analysis of elliptic curve cryptography for SSL. In: ACMWORKSHOP ON WIRELESS SECURITY, 1. Proceedings. . . [S.l.: s.n.], 2002. p.87–94.

HAFIZ, M.; ADAMCZYK, P.; JOHNSON, R. E. Growing a pattern language (for security).Proc. ACM Int. Symp. New ideas, new Paradig. reflections Program. Softw. - Onward!’12, [S.l.], p.139, 2012.

HARDY, N. The Confused Deputy: (or why capabilities might have been invented). SIGOPSOper. Syst. Rev., New York, NY, USA, v.22, n.4, p.36–38, Oct. 1988.

IMMICH, P. K.; BHAGAVATULA, R. S.; PENDSE, R. Performance analysis of fiveinterprocess communication mechanisms across UNIX operating systems. Journal of Systemsand Software, [S.l.], v.68, n.1, p.27–43, 2003.

JAEGER, T. Reference Monitor. Encycl. Cryptogr. Secur., [S.l.], n.Springer US, p.1038–1040,2011.

JEONG, Y.-S. et al. A kernel-based monitoring approach for analyzing malicious behavior onAndroid. Proc. 29th Annu. ACM Symp. Appl. Comput. - SAC ’14, [S.l.], p.1737–1738,2014.

JONSSON, J.; KALISKI, B. Public-Key Cryptography Standards (PKCS) #1: rsacryptography specifications version 2.1. [S.l.: s.n.], 2003. (3447).

KERRISK, M. et al. Linux Programmer’s Manual. 2009.

LIDIE, S.; WALSH, N. Mastering Perl/Tk: graphical user interfaces in perl. [S.l.]: "O’ReillyMedia, Inc.", 2002.

LONVICK, C. M.; YLONEN, T. The Secure Shell (SSH) Protocol Architecture. [S.l.: s.n.],2006. (4251).

REFERÊNCIAS 77

MARFORIO, C. et al. Application collusion attack on the permission-based security modeland its implications for modern smartphone systems. [S.l.]: Department of ComputerScience, ETH Zurich, 2011.

METTLER, A.; CLOSE, T. Joe-E : a security-oriented subset of java. Isoc Ndss 2010, [S.l.],p.1–20, 2010.

MONSHIZADEH, M.; NALDURG, P.; VENKATAKRISHNAN, V. Mace: detecting privilegeescalation vulnerabilities in web applications. , [S.l.], p.690–701, 2014.

MUTTI, S.; BACIS, E.; PARABOSCHI, S. An SELinux-based Intent manager for Android.IEEE Conf. Commun. Netw. Secur., [S.l.], 2015.

OPENBSD. OpenSSH. 2009.

ORBAC. Orbac. 2013.

PEARCE, P. et al. AdDroid. Proc. 7th ACM Symp. Information, Comput. Commun. Secur.- ASIACCS ’12, [S.l.], p.71, 2012.

PERRIN, C. The Importance of Privilege Separation. 2009.

PROVOS, N.; FRIEDL, M.; HONEYMAN, P. Preventing Privilege Escalation. Proc. 12thConf. USENIX Secur. Symp. 12, [S.l.], p.16, 2003.

ROOKER, T. The Reference Monitor: an idea whose time has come. Proc. 1992-1993 Work.New Secur. Paradig., [S.l.], p.192–197, 1993.

SALTZER, J. H.; SCHROEDER, M. D.; MEMBER, S. The Protection of Information inComputer Systems A . Considerations Surrounding the Study of Protection. Access, [S.l.], v.63,n.9, p.1278–1308, 1975.

SAMARATI, P.; CAPITANI, S. D. Access Control : policies , models , and mechanisms.Foundations of Security Analysis and Design, [S.l.], v.2171, p.137–196, 2001.

SCHREUDERS, Z. C.; PAYNE, C.; MCGILL, T. The functionality-based applicationconfinement model. Int. J. Inf. Secur., [S.l.], v.12, n.5, p.393–422, 2013.

SCHUMACHER, M. et al. Security Patterns: integrating security and systems engineering.[S.l.]: John Wiley & Sons, Ltd, 2013.

SOUTO, E. et al. HTR: a framework for interconnecting wireless heterogeneous devices. In:IEEE CONSUMER COMMUNICATIONS AND NETWORKING CONFERENCE (CCNC),2012. Anais. . . [S.l.: s.n.], 2012. p.645–649.

STEVENS, W. R.; FENNER, B.; RUDOFF, A. M. UNIX network programming. 3.ed. [S.l.]:Addison-Wesley Professional, 2004.

STEVENS, W. R.; RAGO, S. A. Advanced programming in the UNIX environment. [S.l.]:Addison-Wesley, 2013.

TITOV, A.; ZABOROVSKY, V. Firewall Configuration based on Specifications of AccessPolicy and Network Environment. Security and Management, [S.l.], p.146–151, 2010.

REFERÊNCIAS 78

TRAPP, M.; ROSSBERG, M.; SCHAEFER, G. Program Partitioning Based on Static Call GraphAnalysis for Privilege Separation. IEEE Symp. Comput. Commun., [S.l.], p.506–511, 2015.

Van Acker, S. et al. WebJail. In: ANNU. COMPUT. SECUR. APPL. CONF. - ACSAC ’11, 27.Proceedings. . . [S.l.: s.n.], 2011. p.307.

WAIN, K. et al. PScout : analyzing the android permission specification. CCS ’12 Proc. 2012ACM Conf. Comput. Commun. Secur., [S.l.], p.217–228, 2012.

WANG, J.; XIONG, X.; LIU, P. Practical Fine-grained Privilege Separation in MultithreadedApplications arXiv : 1305 . 2553v1 [ cs . os ] 12 may 2013. arXiv Prepr. arXiv1305.2553,[S.l.], p.1–24, 2013.

WOOL, A. A quantitative study of firewall configuration errors. Computer, [S.l.], v.37, n.6,p.62–67, 2004.

WU, Y. et al. Codejail: application-transparent isolation of libraries with tight programinteractions. In: Comput. Secur. 2012. [S.l.: s.n.], 2012. p.859–876.

WU, Y. et al. Automatically partition software into least privilege components using dynamicdata dependency analysis. In: AUTOMATED SOFTWARE ENGINEERING (ASE), 2013IEEE/ACM 28TH INTERNATIONAL CONFERENCE ON. Anais. . . [S.l.: s.n.], 2013.p.323–333.

Apêndice

808080

ADificuldades Encontradas

A.1 Gerenciamento de Threads

Conforme dissertado no Capítulo 4, há vários módulos que compõem a solução Secure-CompApp e para cada módulo há um conjunto de atribuições. Para que todas estas funcionalida-des fossem executadas sempre e permitissem o funcionamento correto da solução foi necessárioimplementar uma solução multithread.

O principal problema trata-se do gerenciamento destas threads. Foi preciso corrigirproblemas de deadlock, starvation e sincronimos de thread que vieram a acontecer ao longodo desenvolvimento. Este problema se agravou na fase de coleta de resultados para os maiorescenários, que eram composto por mais processos, sendo que para cada processo é criada umanova thread no monitor de referência que gerencia seu canal de comunicação.

Este problema foi minimizado fazendo uso de recursos de paralelismos mais avançadospara a linguagem Java: thread pools, executor services, hashmap para threads, elementosatômicos de sinalização entre threads e block heap.

Os conceitos listados foram estudados para melhor serem inseridos dentro da provade conceito da solução. Eles auxiliam no gerenciamento de um largo número de threads

minimizando problemas recorrentes de deadlock, starvation e sincronimos de thread.

A.2 Gerenciamento de canais IPC

A estrutura centralizada do Secure-CompApp visa concentrar na solução todos os canaisde comunicação a fim de minimizar o problema de gerenciamento. Entretanto, esta vanta-gem agregou outras dificuldades para a solução rotear e endereçar os dados trocados entre osprocessos.

Inicialmente, foi utilizado outro esquema de canais IPC, como por exemplo uma soluçãode shared memory. Apesar do estudo ter apresentado a menor vazão para este esquema, talvazão ainda seria suficiente para as avaliações. Entretanto, este canal apresentava problemas paraendereçar um dado em maiores cenários, além de que era preciso criar um complexo e robusto

A.3. MODELO DE CONTROLE DE ACESSO 81

esquema de sincronismo para escrita e leitura de dados na região de memória.A outra abordagem foi o uso de um socket UNIX com uma pilha de interfaces de

comunicação para cada um dos processos associados. Nesta abordagem a dificuldade ficouem melhor gerenciar a pilha e prover o correto roteamento dos dados. A identificação dosprocessos com socket UNIX é feita através do PID, GID e UID, porém estes valores só tornam-seconhecidos no instante da criação do processo. Assim, foram criados formatos de mensagenscom cabeçalhos que permitissem uma identificação mais amigável de cada processo associadono ato da execução.

A.3 Modelo de Controle de Acesso

Apesar de ser um modelo de controle de acesso muito usado, a documentação do OrBACnão sanou todas as dúvidas quanto ao seu uso para criar, ler e manipular os arquivos de políticasXACML. Para executar estas ação via a API acaba não sendo uma atividade simples, que exigemanipulação de várias estruturas de dados programaticamente.

A forma mais simples de criar e editar estes arquivos é através de uma ferramenta queimplementa várias funções da API OrBAC, o MotOrBAC1. Assim, as dificuldades com a APIforam minimizadas para apenas fazer leitura do arquivo de políticas e gerenciamento das regrasali contidas.

1http://motorbac.sourceforge.net/

Documents

Gregório Patriota Correia...Cada ﬁo de cabelo perdido e também cada novo ﬁo branco que ganhe, cada uma destas marcas mostram o quão loga foi a jornada. Agradeço também a quem