Publicações do PESC Mecanismo de Proteção em Sistemas de Computador

MECANISMOS DE PROTE~ÃO EM SISTEMAS DE COYPUTADOR

LeiXa Scdero Lima de Rezende

TESE SUBPlETIDA AO CORPO DOCENTE DA COORDENAÇÃO DOS PROGRAMAS DE PÓS-GRADUAÇÃO EM ENGENHARIA DA UNIVERSIDADE FEDERAL DO RIO DE JANEIRO COMO PARTE DOS REQUISITOS NECESSÁRIOS PAPA A @ZríFi!l

_-

ÇÃO DO GRAU DE MESTRE EM CIÊNCIAS (M.Sc.)

Aprovada por:

PIERRE JEAN LAVELLE Presidente

~en.Cel. ALMIR $AZ DE LIMA

J SUELI MENDES DOS SANTOS

/

LUIZ ANTONIO CARNEIRO DA CUNHA COUCEIRO

RIO DE JANEIRO, R3

-

BRASIL JULHO DE 1981

REZENDE, LEILA SODERO LI-MA DE

Mecanismos de ~ r o t e ç ã o em Sistemas d e Computador (Rio de J a n e i r o ) 1 9 8 1 .

X I I I , 261p. 23,7 cm (COPPE-UFRJ, M.Scb, Engenharia de Sistemas, 1981)

Tese

-

Universidade Federal do Rio de J a n e i r o . Faculdade de Engenharia

1. Mecanismos de proteção para a segu rança de dados em s i s t e m a s de computador I . C O O P E / U F R J 11. ~ i t u l o ' ( s ê r i e )

.)

Dedicamos e s t e t r a b a l h o a t o d a s a s pessoas que s e n t i r a m e m algum i n s t a n t e d e sua v i d a :.as conse- q u ê n c i a s d e uma f a l h a d e p r o t e ç ã o no computador.

AGRADECIMENTOS

Agradecemos a t o d a s a s p e s s o a s que com d e s p r e n - dimento nos t r a n s m i t i r a m s u a s e x p e r i ê n c i a s legando

5

comunidade c i e n t í f i c a uma q u a n t i d a d e e n c i c l o p é d i c a d e a r t i g o s , sem o s q u a i s t e r i a s i d o i m p o s s i v e i a r e a l i z a ç ã o d e s s e t r a b a l h o .

~ambém a o p r o f e s s o r P i e r r e _Jean Lavella por s u a o r i e n t a ç ã o o b j e t i v a e r a c i o n a l e a o p r o f e s s o r Gerhard Schwarz por s e u i n c e n t i v o e d e s a f i o cons- t a n t e s .

RES UM0

Sistemas de computadores constituem alvo frequen- te de ataques para obtenção de ~rivilégios a níveis pessoal, empresarial e nacional, são analisados os componentes de cada sistema de computador com o obje tivo de se identificar suas vulnerabilidades e propor salvaguardas. Um conjunto amplo de mecanismos depro teção em projeto ou em uso no mundo e apresentado, analisado e criticado. Finalmente, é proposta uma classificação desses mecanismos segundo padrães de discrecionaridade.

ABSTFACT

Computer systems constitue a frequent target o£ attack to achieve privileges at personnel, corporate and national levels. Computer systems components are analysed with the objective o£ identifying their vulnerabilities and propose safeguards. A wide range o£ protection mechanisms in project or in use at world is presented, analysed and criticised. Finally, a classification o£ those mechanisms is proposed, accord- ing to discrecionarity patterns.

SIGLAS ARP A

-

ARPANET

-

CDC

-

DBMS

-

FJCC

-

ICS

-

IMF

-

IMS

-

IPC

-

JCL

-

LNS

-

MPC

-

NB S

-

NCC

-

NOS

-

NRCC NSC

-

NSF

-

OS/370

-

ROM

-

SDC

-

S JCC

-

SRI

-

TCP

-

TIP

-

UCC

-

VM/370

-

Advanced Research Projects Agency ARPA Computer Network

Control Data Corporation Data Base Management System Fall Joint Computer Conference Inventory Control System (IBM)

Instalation Management System (IBM) Information Management System (IBM) Interprocess Comrnunication

Job Control Language (IBM) Local Name Space (HYDRA)

Master Control Program (Burroughs) National Bureau of Standards

National Computer Conference Network Operating System

National Research Concil of Canada Network Security Center

National Science Foundation Operating System (1~M/370) Read Only Memory

Systems Development Corporation Spring Joint Computer Conference Stanford Reseãrch Institute Transmission Control Protocol Terminal Interface~~Processor User Controled Cryptography Virtual- Machine (IBM/370)

PALAVRAS EM INGLÊS

Pedimos l i c e n ç a a o s a p o l o g i s t a s da l h g u a p o r t u g u e s a p a r a e x p r i m i r sem a s p a s , a p ó s t r o f e ou i t á l i c o termos da l i n g u a i n g l e - s a que se tornaram c o r r i q u e i r o s no ambiente c i e n t i f i c o , p a r a o s q u a i s a t r a d u ç ã o ou é i n e x i s t e n t e ou d i m i n u i poder p a r a a p a l a - v r a o r i s i n a l . Outros termos em i n s l ê s , não t ã o t é c n i c o s nemtão e s p e c i f i c o s s ã o t a d a s p a l a v r a s back-up b a t c h b i t buf f er ' b y p a s s

'

b y t e cache c a l 1 c a p a b i l i t y c l i p c l u s t e r dead-lock d e f a u l t dump e n t r y - p o i n t f a c i l i t y f a u l t f r o n t - d o o r f ront-end u t i l i z a d o s e n t r e apõst;ofes. A s e g u i r , uma l i s - em i n g l ê s que s e r ã o e n c o n t r a d a s no t e x t o :

'

handshaking

'

hardware 'house-keeping' i n p u t 1/0 j ob l a b e l l i n k l o g i n l o o p 'need-to-know' of f - l i n e o f f s e t o n - l i n e

'

one-way

'

o u t p u t o v e r f l 8 w overhead p a g e - f a u l t password

'

p i p e p o i n t e r ' p o o l ' p r o c e d u r e prof i l e s c h e d u l e r s o f t w a r e s t a c k s t a f f s t r e a m t a g ' t i c k e t

'

' t u r n - a r o u n d ' w o r k i n g - s e t

ÍNDICE DE FIGURAS Fig 2 . 1

-

Fig.3.1

-

Fig 3.2

-

Fig 3.3

-

Fig 3.4

-

Fig 3.5

-

Fig 3.6

-

Fig 3.7

-

Fig 3.8

-

Fig 3.9

-

Fig 4 . 1

-

Fig 4.2

-

Fig 4.3

-

Fig 4.4

-

Fig 4.5

-

Fig 5.1

-

Fig 5.2

-

Fig 5.3

-

Fig 5.4

-

Fig 5.5

-

Fig 6.1

-

Fig 6.2

-

Fig 6.3

-

Fig 6.4

-

Fig 6.5

-

Fig 6.6

-

Fig 6.7

-

Fig 7.1

-

Fig 7.2

-

Fig 7.3

-

Relação entre Seguranqa e Integridade da informação

m t r i z de acesso e m um universo de 3 sujeitos e 9 objetos Estrutura interna de um mecanismo baseado e m matriz de acesso ~ n s t r u ç & s que modificam a m a t r i z de acesso

L i s t a de capabilities de um job

Capabiiity etiquetada no sistema BCC-500

Efeito da transmissão de capability na matriz de acesso

comparação entre mecanisms de capabilities e de l i s t a s de acesso 28

L i s t a de chaves e fechaduras c m atributos de acesso W a n i s m de chave-fechadura no C&-TSS

Níveis de classificação militares Conjuntos de categorias militares Elementos do modelo multinível

Níveis de arquitetura do sistema KSOS Treliça de fluxo seguro de informaçÕes

Mapamento no mecanismo de memória v i r t u a l Ehdereçamento no sistema IBM S/38

~ i r e t ó r i o s para arquivos permanentes

Um diretório paralelo ao organograma de uma empresa

cmparação entre segmentação lógica e f i s i c a de um arquivo

Descritor de segmento Segmnto de descritores

Descritor de segmento contendo número de anel C a p b i l i t i e s de memória

Capabilities de entrada

Confinamento no I/Q de uma procedure ~peração na D a t a BQrk Machine

~ o m h i o s de execução em arquiteturas hierârquicas

~nclusão do softmre do VM/370 na hierarquia de um sistem

Fig 7.4

-

Arquitetura do UCLA SECüRE üNIX Fig 7 . 5

-

Arquitetura do IWM/370

Fig 7.6

-

Estrutura do KSOS

Fig 8.1 e Testes de segurança para prccessamento de transação Fig 8.2

-

Esquema de validação de acesso discrecionário

Fig 8.3

-

Grafo de autorização do sistema R Fig 8.4

-

Operação de recuperação no UCLA INGRES

Fig 9.1

,-

Vulnerabilidades de uma rede de ~0mpu@d~re~ Fig 9.2

-

Aigori-hno de criptografia do DES

Fig 9.3

-

Transmissão de chaves entre dois nós de uma rede

Fig 9 . 4

-

visão do usuário da rede

Fig 9.5

-

Fluxo de dados em canais criptografados processo-a-processo Fig 9.6

-

Configuração de m a rede cam NSC

Fig 9.7

-

conexão entre XSOÇ e rede multinivel

Fig A. 1

-

Arquitetura do PSOS

Fig B.l

-

~xtensões de objetos no HYDRA Fig B. 2

-

Sistema distribuido MEDUSA Fig B .3

-

organização de um CM

Fig B.4

-

Terminal multinivel do SIGMA Fig B. 5

-

Configuração inicial do XNOS

Pag

.

2

11.

-

FUNDAMENTOS

1. Conceitos ~ásicos

2. Mecanismos de Proteção e Sistemas Operacionais 3. Características de um Mecanismo de Proteção

4 . Componentes de um Mecanismo de Proteção 111.

-

MECANISMOS

DISCRECIONARIOS

1. Modelo da Matriz de Acesso

-

2. Capabilities 3. Listas de Acesso 4. Chaves-fechaduras

IV.

-

MECANISMOS NÃO-DISCRECIONÁRIOS 1. Modelo ~ultinível

2. Níveis de Segurança e Arquiteturas ~ierárquicas 3. Controle de Fluxo

4. Momento de ~igação

V.

-

PROTEÇÃO DA INFORMAÇÃO ARMAZENADA 1. ~ernória Virtual

2. Arquiteturas Etiquetadas 3. ~icroprogramação

4. Diretórios

5. Acesso ~ Ó g i c o a Arquivos

6. Criptografia Aplicada a Arquivos VI.

-

EXECUÇÃO PROTEGIDA DE PROCESSOS

1. Processos

2. ~ominios e ~ e ~ m e n t a ç ã o 3. Anéis de Proteção

APÊNDICE A

-

SISTE-MACiDE HARDWARE CONCENTRADO ADEPT-50 B C C - 5 0 0 MULTICS CAL-TSS UCLA U N I X KSOS S / 3 8 P S O S

APÊNDICE B

-

S I S T E M A S DE HARDWARE DISTRIBUÍDO

B . l

-

HYDRA B . 2

-

r n D U S A B . 3 SIGMA B. 4

-

XNOS B I B L I O G R A F I A ~ N D I C E DE PALAVRAS-CHAVE

Presentemente os danos realizados através de computador atin- gem mais de 200 milhões de dólares anuais somente nos Estados Uni dos. Os conhecedores do assunto estimam que isso é apenas a ponz ta de um iceberg já que menos de 1% de todas as fraudes por compu

-

tador são detetadas, e quando o são as companhias mostram-se em- baraçadas em torná-las públicas.

Os problemas d.e segurança associados a um complexo sistema de computadores não dizem respeito apenas aos atos intencionalmen- te realizados em beneficio próprio. ~á casos em que, acidental- mente,toda uma comunidade pode ser posta em perigo. Por exemplo no ano de 1980 os computadores do Departamento de Defesa dos Esta dos Unidos emitiram vários alarmes falsos anunciando a captaçãõ de sinais provenientes de mísseis soviéticos. Por duas vezes a guerra esteve prestes a estourar.

Deliberados ou não, os atos que causam a exposição, modifica- ção ou destruição de informação sensível devem ser prevenidos. As características especiais que compõem esses sistemas de compu- tadores, como: grande quantidade de informação simultaneamente disponível a vários usuários, acesso de longas distâncias e reten ção de resíduos mesmo depois de parcialmente utilizados, fazem dã segurança uma meta dificil de ser atingida.

Os mecanismos de proteção empregados nos sistemas de compu- tadores são 5s vezes complexos e caros. Entretanto, se o proble- ma for equacionado na sua raiz, soluções simples e baratas podem ser encontradas. Sistemas inseguros não podem se tornar magica- mente seguros pela adição de um ou mais mecanismos de proteção, como não se pode tornar saudavel um organismo doente através de um simples remédio.

A expansão dos sistemas, a distribuição do processamento, a ligação de vários componentes em redes tornaram o problema da se- gurança mais sério. O tamanho ao qual os sistemas chegaram, impe de muitas vêzes, que se façam testes completos e acompanhamentõ das suas tarefas. Técnicas de certificação e metodologias de es- pecificação formal ajudam os projetistas a testar cada item rela- cionado à proteção do sistema.

Muito tem sido pesquisado na área de segurança de computador. Desde a confiabilidade de cada microelemento do hardware até 5s características psicolÓgicas do profissional de processamento de dados o caminho

6

extenso e emocionante. De ambos os prismas: dos que se protegem e dos que querem atacar. Cada detalhe é im- portante, uma pequena fresta pode ser fatal. Mesmo que não haja danificação na informação, mesmo que não haja escoamento de segre dos, a perda de um simples arquivo pode significar a destruiçãõ de meses de trabalho realizado por toda uma equipe.

Hoje em dia é difícil encontrar uma geração de computadores que não tenha dispositivos de segurança, providos por uma tecnolo gia em continuo aperfeiçoamento. Todos já se conscientizaram de que o computador é uma ferramenta e uma arma, tanto a nivel indi-

dividual como a empresarial e internacional. 1nvengÕes de ficção científica como espiões eletrÔnicos se tornaram realidade em tem- po inferior ao que levaram para ser imaginadas. Instrumentos tão potentes não podem cair em mãos de pessoas inescrupulosas ou "in- gênuas"

.

A pesquisa para esta Tese se situou na análise dos mecanismos de proteção implementados em sistemas desenvolvidos ao longo des- ses quinze Últimos anos. Esses mecanismos, criados paraequipamen tos, sistemas e ambientes diferentes foram comparados com o objez tivo de encontrar os elementos essenciais de cada aproximação. características comuns foram filtradas e reunidas a fim de se es- tabelecer um conjunto básico correspondente aos componentes prin- cipais de um mecanismo de proteção. Além de procurar os elemen- tos estruturais, analisamos as modulações criadas em torno dêles e sua validade.

Esta Tese foi escrita para o estudante ou profissional de pro cessamento de dados que, tendo uma visão sistêmica geral não tem necessariamente conhecimento detalhado de cada assunto tratado. Assim, ao analisar mecanismos de proteção, por exemplo, de um ban co de dados, partimos da definição de banco de dados, caracterísz ticas e modelos, para em seguida atingir o assunto que nos diz respeito. Essa preocupação foi uma constante durante todo o nos- so trabalho, e embora deixe margem para críticas pelos especialis -

tas, optamos por um conteúdo menos elitista e mais didático. De certa forma, essa decisão foi praticamente uma necessidade pois dada

5

amplitude dos assuntos enfocados seria irreal supor conhe- cimento prévio de cada um deles.

A Tese está dividida em oito capítulos, dez se considerarmos a ~ntrodução e a conclusão. O capítulo I1 contém os fundamentos para os seguintes. são apresentadas definições de termos básicos em segurança, características principais e componentes de um meta nismo de proteção. O capítulo 111 introduz os mecanismos de pro- teção discrecionários apresentando uma Sa:q~áVE?l base teórica e ai- guns exemplos. O capitulo IV repete o mesmo para o caso dos meca -

nismos não-discrecionários. No capitulo V são analisados vários mecanismos de proteção da informação armazenada, estaticamente fa lando. No capítulo VI essa mesma informação é considerada dinâmz camente, durante a execução dos processos do sistema. O capítulõ VI1 enfoca uma nova tendência na construção de mecanismos de pro- teção, a de agrupá-los numa parte privilegiada do sistema opera- cional, o núcleo, onde desfrutam de todas as vantagens que o po- der lhes confere e de onde controlam o funcionamento de todo o sistema. No capítulo VI11são apresentados mecanismos de proteção específicos para Banco de Dados e no capítulo IX os específicos para Sistemas ~istribuídos.

Os Apêndices, como na maioria dos casos, são parte integrante desse trabalho e na versão inicial estavam incluídos no corpo da Tese. Entretanto, com o objetivo de separar MECANISMOS de SISTE- MAS achamos por bem criar os Apêndices, contendo a descrição de alguns sistemas estudados. Na realidade estes constituem o sub- conjunto mais detalhadamente analisado do conjunto total, que in- clui em torno de 40 sistemas, como se verá pelas referências.

Esta Tese, sendo tanto uma análise como uma síntese, é antes de tudo, a exemplo do assunto estudado, uma proposta preventiva de uma mentalidade de segurança. ~ s t á na hora de conscientizar- mos a nossa sociedade, em especial os que trabalham direta ou in- diretamente em computadores, da necessidade de se utilizar meca- nismos de proteção. Este é, sem dúvida o nosso objetivo primor- dial.

11.1 CONCEITOS BÃSICOS

No contexto de proteção da informação em computadores existem alguns conceitos que devem ser especificados antes de se proceder às referências. 1. ACESSO

-

3. POLÍTICA DE

-

SEGURANCA 4. POLÍTICA DE

-

INTEGRIDADE 5. SEGURANÇA X

-

INTEGRIDADE 6. MECANISMO DE.- PROTEÇÃO

A habilidade de fazer uso de uma informação ar- mazenada em um sistema de computador. Tipos de acesso são: ler, escrever, copiar, alterar, executar, etc.

A atitude de conceder o ACESSO à informação através de um conjunto de regras previamente es -

tabelecidas. Exemplo: autorização para ler. Um conjunto finito de regras -que delimitam o ACESSO

2

informação durante a execução de uma computação. Políticas de segurança são imple- mentadas através de mecanismos de proteção. Exemplo: privacidade é uma política de segu- rança que regula a disseminação de informação relativa a uma pessoa ou a um grupo de pessoas. Um conjunto de regras que especificam a ALTERA- ÇÃG da informação durante a execução de uma computação. Como no caso da politica de segu- rança, existem mecanismos de proteção que supor tam a política de integridade e estes podem ser um subconjunto daqueles (já que ALTERAÇÃO é um tipo de ACESSO)

.

Uma violação da segurança pode implicar ou não em uma violação na integridade, embora a possi- bilidade de uma modificação correta da informa- ção após uma violação na segurança seja remota. O diagrama da Fig. 2.1 explica porque.

O conjunto de facilidades de ha-rdware e soft- ware colocado à disposição dos programadores como base para a implementação de políticas.

T A O ~ Ç Ã O

NA INTEGRIDADE

NA INTEGRIDADE

Fig .2.1 ~ e l a q ã o e ~ t r e Segurança e Integridade da ~ n f ormação (%a 77)

7. DISCRECIONARIDADE

-

E

a propriedade d.e um mecanismo segundo a qual o ACESSO aos recursos do sistema e especificado pelos próprios usuários indi vidualmente ou por grupos de usuários, de modo que satisfaçam suas necessidades par -

titulares de utilização do sistema.

8. NÃO-DISCRECIWRIDADE- 'É a propriedaze de um mecanismo segurido a qual todos os usuários e recursos do sis- tema são compartimentalizados em niveis pré-fixados e o ACESSO só é concedido em acordância com a hierarquia estabelecida. 9. CONFIABILIDADE

-

E

a propriedade de um mecanismo que desem penha comprovadamente as funções que

lhe

são atribuidas.

10. RECUPERABILIDADE

-

É a propriedade de um mecanismo que após qualquer erro, acidente, desastre ou que da do sistema pode ser (:restaurado seE causar perda de serviço ou de segurança. 11. AUDITÃBILIDADE

-

É a propriedade que envolve a monitora ção contínua da segurança e confiabilidã de de um mecanismo incluindo a deteçãõ de comportamento anoma10 ou potencialmen

-

te perigoso.

Peter Denning (Den 71) definiu um sistema de computação em ter

-

mos das várias funções de controle e supervisão que provê para os processos criados pelos seus usuários, onde o termo PROCESSO deno- ta um programa em execução. O conjunto de funções realizadas pelo sistema pode ser especificamente dividido em 7 grupos:

criação e remoção de processos.

Controle do progresso dos processos, isto é, garantindo que ca -

da processo evolua a uma taxa positiva e não bloqueie o pro- gresso dos outros.

locação

de recursos de hardware para os processos, exemplo: dispositivos de I/O.

locação

de recursos de software, exemplos: arquivos, edito- res, compiladores, assemblers, bibliotecas de rotinas e siste- mas de programação.

conexão entre processos através dos meios de comunicação inter -

processuais.

Tratamento das condições excepcionais que surgem durante a exe cução dos processos, exemplos: erros aritméticos ou de máquiZ na, interrupções, instruções ilegais ou privilegiadas.

~roteção e controle de acesso à informação.

O software sue realiza ou auxilia o hardware a realizar essas funções é chamado Sistema operaciona1

.

Enquanto que os seis primeiros grupos de funções estão intrin- secamente ligados à própria existência do sistema, o sétimo grupo apresenta uma caracteristica de opcionalidade que pode ser compro- vada pela existência de um grande número de sistemas operacionais, aceitos e utilizados em larga escala, que não possuem as funções do sétimo grupo.

O conceito de proteção em sistemas de computação começou a apa

recer contemporaneamente aos sistemas de multiprogramação. ~ n t e ~ riormente, os recursos do computador cómo CPU, memória principal,

sistemas de arquivos e periféxicos eram utilizados simultaneamente por um só usuário, que blocava um certo tempo durante o qual a má- quina lhe era dedicada. Assim, programas, arquivos, e todo o mate ria1 sensíSB2 poderiam ser protegidos pelos métodos tradicionais, uma vez que não necessariamente permaneciam armazenados no próprio sistema de computação.

Com o advento dos sistemas de multiprogramação, a possibilida- de de se compartilhar recursos da máquina paralelamente entre

vá-

rios usuários, trouxe a necessidade de se protegê-los de uma manei ra apropriada. Inicialmente a proteção era incluída na tarefa dos

schedulers ou gerentes de recursos que, ao alocarem cada recurso, testavam a "competência" do processo solicitante. N ~ O se poderia dizer que isso fosse realmente um mecanismo de proteção, melhor seria considerá-lo apenas um '"housekeeping'.

Dos primeiros gerentes de recursos até hoje muito tem sido pesquisado na área de sistemas operacionais seguros, a maioria das pesquisas financiadas pelo Departamento de Defesa dos Esta- dos Unidos como se pode ver pelas referências. O sistema opera- cional é o responsável pelo acesso aos recursos da máquina. É através das suas decisões e ordens que todo o complexo de equipa- mentos desempenha cada função específica. Assim, uma vez obtido o controle do sistema operacional, pode-se conseguir qualquer in- formação, bastando que ela exista em algum lugar do sistema.

Teoricamente existem 2 alternativas para se atingir maior se- gurança num sistema operacional, uma basicamente corretiva e uma

-

basicamente preventiva (Neu 78). A primeira envolve o acesso a estrutura dos sistemas existentes para descobrir falhas de segu- rança e a tentativa de cobrir as trajetórias que levam a essas fa

-

lhas. A segunda envolve o projeto de novos sistemas que são

in-

trinsecamente seguros e cuja segurança pode ser comprovada de al- guma maneira convincente.

Com respeito à aproximação CORRETIVA várias técnicas tem si- do utilizadas para descobrir erros que reduzem a segurança. Estas incluem codificação de pesquisa para certos modelos de instruções dos programas correspondentes a chaves de prováveis falhas e tam- bém as tentativas tradicionais de penetração operacional. Entre- tanto, várias razões levam a crer que esta aproximação não é a me -

lhor :

.

não é necessário procurar m@toparadescobrir falhas nos sis

_-

temas existentes.

.

trajetórks que tentam remover essas falhas, são elas mesmas frequentemente falhas.

.

tentativas de caracterizar as falhas não detetadas são no máximo apenas especulativas.

Assim, em geral, adaptações de segurança possuem efetivid.ade limitada e inevitavelmente deixam muitas tncÕgnitas.

A longo prazo o uso da aproximação PREVENTIVA é significante- mente mais produtivo. Esta aproximação significa que o sistema foi projetado com o objetivo fundamental de prover segurança. De ve incluir identificação explícita dos propósitos e especificaçãõ formal do projeto. Deve usar uma linguagem de programação moder- na e deve empregar provas formais das propriedades mais signifi- cantes para o comportamento do sistema, exemplo: segurança. Pes quisas recentes mostram que é possível assegurar a segurança de um projeto especificado precisamente antes da sua implementação e depois assegurar a segurança da implementação.

Existe porém um problema de custo na aproximação preventiva. Milhares de instalações de computadores em todo o mundo estariam

dispostas a pagar pela segur:nça das suas aplicações mas não a mo dificá-las para compatibiliza-las com novos sistemas, Os custos de modificação, recompilação, redocumentação, treinamento, etc, relativos a mudança de software ou de hardware são elevados de- mais na maioria das situações. Para evitá-los existe uma 3a. al- ternativa que é uma combinação das aproximações corretiva e pre- ventiva. O sistema existente é reprojetado de tal forma que suas partes relevantes para a segurança são isoladas em uma pequena e claramente definida coleção de programas chamada núcleo. Entre- tanto, a efetividade dessa combinação pode também ser reduzida pe las restrições impostas ao projeto como por exemplo a necessidade de manter compatibilidade com a interface original insegura. Pode também confundir POLÍTICA com MECANISMOS, tornando o sistema espe cifico para um número restrito de politicas. Mas de qualquer for ma, em muitos casos esta azternativa já foi escolhida e satisfaz às necessidades especificas a que se propõe.

Concluindo, podemos observar a intensa modificação pela qual passaram os mecanismos de proteção num sistema operacional: de "função opcional" para N~CLEO. Agora já se sabe que um mecanismo de proteção é tanto mais seguro quanto mais fundo estiver no sis- tema do computador. Muitos são implementados em firmware e mui- tos também no próprio hardware. Sistemas de computadores não po- dem mais se dar ao luxo de possuir Security Facilities opcionais, como no passado, pois a segurança só pode existir se estiver na sua base.

Nos capítulos seguintes examinaremos as 2 Últimas alternati- vas e os artificios que foram utilizados para resolver suas vicis -

11.3 CARACTERÍSTICAS DE UM MECANISMO DE PROTEÇÃO

Num sistema de computador um mecanismo de proteção deve ser capaz de controlar internamente a interação entre os vários usuá- rios do sistema, garantindo separação quando requerida, permitin- do cooperação irrestrita quando desejada e proporcionando tantos degraus de controle intermediário quantos forem necessários.

Os múltiplos usuários de um computador possuem diferentes ob- jetivos e são responsáveis por diferentes níveis de autoridade. Um grupo tão diverso só poderá usar o mesmo sistema se este for geral o suficiente para satisfazer as necessidades específicas de cada um, proporcionando-lhes a capacidade de proteger seus pró- prios bens e de liberar o acesso, de maneira controlada, a outros usuários.

O projeto dos mecanismos de proteção 6 a sua fase mais impor- tante. Nela são definidas as técnicas que levarão % implementa- ção das políticas de segurança. Nela são especificadas formalmen te as estruturas que serão mais tarde implementadas de acordo com o que foi projetado.

Independentes da política, do mecanismo e da técnica emprega

d o s , existem algumas características que devem orientar o projetõ de todo mecanismo de proteção. Estas foram surgindo a partir de erros cometidos e compõem agora o conjunto das características ne cessárias para tornar a construção do sistema mais rápida e para tornar o mecanismo mais seguro e compatível. são as seguintes:

FUNCIONALIDADE

-

SIMPLICIDADE

-

PROJETO NÃO

-

SECRETO

O mecanismo deve ser capaz de atender às necessidades do conjunto de usuários de uma maneira correta e natural.

Mecanismos simples podem ser exaustiva- mente testados e todas as trajetórias de dados podem ser investigadas.

Os mecanismos de proteção não podem de- pender da ignorância dos seus usuários, que na realidade são pessoas de altissi- mo nivel intelectual. O projeto deve ser divulgado, debatido em palestras, pg ra apresentar todos os problemas antes da implementação. A proteção real deve dependerdos parâmetros, estes sim, se- cretos, -pass&ei~ de serem alterados peA riodicamente. Esta separação entre meca -

n i m s e parâmetros, embora primitiva, en viou um número surpreendente de projetos de volta à prancheta de desenho.

EFICIÊNCIA DE

-

Embora os mecanismos de proteção ocasio- DESEMPENHO nem implicitamente um aumento no over- head geral do sistema, este deve ser o mínimo possivel. Especialmente em siste mas que são projetados para substituir outros, comparações são anevitáveis. 5. ECONOMIA

-

O custo da implementação de um tipo qual

quer de restrição de acesso não deve ser fator importante na determinação da polí -

tica de segurança, portanto, os mecanis- mos de proteção devem ser capazes de rea lizar economicamente qualquer uma delas, MÁXIMO APROVEITA-

-

Um software "feito sob medida" para um MENTO DO HARDWARE hardware especzfico pode não ser comer- cializável independentemente, mas as van tagens em simplicidade d,e a l g o ~ I t m o s ~ economia de linhas de prograrnaqão e ra- pidez na execução compensam plenamente. FALTA DE ACESSO

-

Se os mecanismos são baseados em permis- COMO DEFAULT são ao invés de em exclusão, os próprios usuários comunicarão erros eventuais que lhes impeçam de acessar recursos aos quais tem direito.

COMPLETARIDADE

-

Cada tentativa de acesso deve ser valida -

da, o mecanismo não pode "memorizar" re- sultados de testes anteriores e conceder acesso baseado nessas informaçÕes, pois isso cria um sério embaraço nas situa- ções de revogação de direitos.

MÍNIMO DE

-

Derivado ,do 'need to knowl militar, esse

PRIVILEGIOS

principio postula que cada usuário do

sistema deve utilizar somente o mínimo necessário de privilégios para realizar seu trabalho. Assim, o número de intera ções potenciais entre programas privile- giados é menor, o sistema fica menos ex- posto a a auditoria é mais fácil.

COMPARTILHAMENTO

-

Cada objeto compartilhado é uma trajetó- M ~ N I M O ria em potencial entre usuários, podendo ser utilizada para escoamento ilicito de informação. Além disso, funções que ser vem a vários usuários tem maior dificuly dade em manter a satisfação individual e podem levar

5

construção deportas falsas driblando o mecanismo de proteção.

11. NATURALIDADE NA

-

O uso rotineiro e automático dos mecanis INTERFACE HUMANA mos de proteção é uma característica esr

sencial, caso contrario canais "simplifi cadores" serão automaticamente construír dos burlando os criterios pré-estabeleci -

dos.

12. DESCENTRALIZAÇÃO

-

Por dois motivos: para evitar "gargalos" DAS ESPECIFICAC~ES nas decisões administrativas que se toma DE PROTEÇÃO das centralmente poderiam gerar 'bypassT nas situaqões de urgência e para não au- mentar a vulnerabilidade do sistema, que

é tanto maior quanto mais concentrada for.

13. FLEXIBILIDADE

-

Deixar margem para inclusões, adaptações, implementações de novas políticas, cria- ção de ambiente de proteção privativo do usuário e de subsistemas protegidos que possibilitem a implementação de qualquer esquema de controle de acesso.

14. CERTIFICAÇÃO

-

Provar que o projeto do sistema atende às especificações formais e que a imple- mentação atende ao projeto é o mesmo que provar que a implementação do sistema a-

-

tende à especificação formal. Isto e chamado certificação e já existem alguns sistemas cujos mecanismos de proteção £o -

ram totalmente certificados.

Para finalizar, algumas considerações sobre a confiabilidade do hardware. O hardware 6 o pr6kequisito para a construção de qualquer sistema, e em se tratando de um sistema seguro, é indis- pensável que tenha o mínimo de erros. A diferença fundamental en tre a confiabilidade do hardware e do software é que um componenZ te de hardware nunca pode ser completamente livre de erros. Ambos são suseetlveis a erros algorítm&cÕs, mas o hardware é também suscetível a erros probabillsticos. Estes representam as falhas imprevisíveis dos elementos e-a proteção contra elas é geralmente obtida através da redundância (estática e dinâmica), deteção e 10 calização de erros, tolerância de faltas e reconfiguração/recupe~ ração dinâmica. O sistema PRIME, desenvolvido em Berkeley Por Fabay é um excelente exemplo de um hardware construido para man- ter disponibilidade, privacidade e custo efetivos através da re- dundância (Fab 73)

.

11.4 COMPONENTES DE UM MECANISMO DE PROTEÇÃO

Tradicionalmente um sistema formal é dividido em três partes:

.

uma sintaxe para descrever elementos e propriedades de

elementos.

.

uma semântica descrevendo os exemplos concretos dos ele- mentos e dando um significado às sentenças da sintaxe.

.

uma teoria de provas para raciocínios sobre os elementos e suas propriedades.

Uma lógica de proteção 6 um sistema formal cujos elementos são os componentes do mecanismo de proteção. Nesta seção serão descritos alguns componentes de um sistema de proteção, os mais comuns. 0s exemplos concretos serão vistos nos outros capítulos e também nos apêndices. 0s raciocínios estão também dispersosnos outros capítulos, mas não nos arriscamos ainda a elaborar uma teo ria de provas. Os dados e achamos Os componentes OBJETOS

-

EXTENS~ES

-

DE OBJETOS SUJEITOS

-

primeiros passos nesse sentido ainda estão se% -

melhor esperar por eles.

mais comuns de um mecanismo de proteção são: são elementos do sistema operacional que po- dem ser acessados e cujo acesso deve ser con- trolado pelo mecanismo ,- - de proteção. Cada ob-

j eto deve estar . -dn9mocamenke associado a uma identificação que lhe é atribuida no momento da sua criação. Exemplos de objeto são: pro- .gramas e arquivos de usuário, páginas de memó -

ria principal, dispositivos de I / O , etc.

Existem dois tipos de objetos: os primitivos, produzidos diretamente pelo sistema e as ex- tensões, que são objetos criados pelos usuá- rios. ~xtensões de objetos são por exemplo sistemas de arquivos especiais, subsistemas protegidos, etc. ~ l é m de tornar o sistema mais flexível as extensões transferem ao usu- ário parte da responsabilidade na proteção dos seus próprios objetos.

são os elementos ativos do sistema, ou seja: os que podem acessar objetos, como por exem- plo OS programas, terminais, etc. Sujeitos tambgm podem ser acessados, portanto são um

subconjunto dos objetos e devem possuir iden- tificação única.

PROCESSOS

-

Dos componentes de um mecanismo de proteção, o processo

6

o mais importante, por ser um elemento ativo, portanto um sujeito, e por ser na maioria das vezes o responsável por todas as funções realizadas no sistema. Exem plos de processos são: programas de usuário; gerentes de memória e de I / O , etc.

REGRAS DE

-

É um conjunto de regras explicitamente espe- ACESSO cificadas que definem o tipo de acesso auto- rizado entre o conjunto de sujeitos e o con- junto de objetos. Devem ser simples, comple tas e flexíveis para gerarem um ambiente de proteção compatível com as aspirações do gru

-

po de usuários. Exemplos de regras são: au- torização para ler, para executar, etc.

NÍVEL DE

-

f?, a combinação de uma categoria de classifi- SEGURANÇA cação ordenada hierarquicamente e de um con- junto de compartimentos. Sujeitos e objetos podem ser distribuídos em vários níveis de segurança, que caracterizam os privilégios de acesso de cada grupo. Exemplos: SECRETO, NÃO

DISSEMINAVEL

A ESTRANGEIROS, etc.

D O M ~ N I O DE

-

É o conjunto de elementos que um processo em EXECUÇÃO execução pode acessar com seus respectivos direitos de acesso. Um sujeito pode ser vis -

to como um par (processo, domínio) em que o processo é um programa em execução e o domí- nio é o ambiente de proteção em que o proces -

so atua.

SUBSISTEMA

-

É uma coleção de objetos de procedures e da- PROTEGIDO dos que é encapsulado em um dor3kia de si mesmo de maneira que a'estrutura interna-das

seus objetos de dados só é acessível atravgs dos seus objetos de procedure, que só podem ser chamados em pontos de entrada protegidos.

-

A reunião de todos os mecanismos de proteção

numa parte protegida do sistema. É um arti- f k i o utilizado para simplificar a depuração- e a certificaçao de sistemas seguros.

10. CAPABILITY

-

Uma referência protegida

a

um objeto do sis- tema. contém normalmente o endereço e os di -

111.1 MODELO DA MATRIZ DE ACESSO

Um dos modelos mais influentes nos mecanismos de proteção é o da matriz de acesso, desenvolvido por Lampson e ,.cornplernentado por Graham e Denning (GrD 72). A base desse modelo é uma matriz cujos elementos contém as regras de acesso de SUJEITOS a OBJETOS. A escolha dos sujeitos, objetos e regras de acesso é feita à dis- creção do projetista, de maneira a preencher as necessidades espe cíficas de cada sistemaj devido a isso, é um modêlo discrecionári'o e pode ser utilizado na construção de mecanismos de proteção dis- crecionários.

Numa matriz de acesso o conjunto de sujei+osê representado pe las linhas da matriz

SI,

s 2

...

e o conjunto de objetos pelas suaç colunas x ~ f X 2 . . .

.

'Cada entrada da matriz A (s,x) contém cadeias, chamadas ATRIBUTOS-DE ACESSO que especificam os direitos ou pri- vilégios de acesso de cada elemento. Como foi definido no capítu 10 anterior, sujeitos são também objetos, portanto devem constar das colunas da matriz (fig 3 -1)

.

*Indica autorizaqão de "cópia" do atributo zscrever

Fig. 3.1

-

Matriz de acesso em um universo de 3 sujeitos e 9 objetos (Den 71)

.

Associado a cada tipo de objeto, existe um monitor, através do qual o acesso a este tipo de objeto é validado. Exemplos de monitores são o SISTEMA DE ARQUIVOS para os arquivos,~ HARDWARE pa ra a execução de instruções e endereçamento de memória e o S I S T E ~ MA DE PROTECÃO para os sujeitos. Assim, quando um sujeito Si so- licita um tipo de acesso ao objeto xj o monitor checa a matriz para verificar se

3

4 em A (si, xj): Basicamente o conjunto de etapas percorridas entre a solicitaçao e a obtenção do acesso é

o seguinte:

parar escrever

1. O sujeito s solicita acesso ao objeto x da maneira o(

.

2. O sistema de proteção ativa o monitor de x e lhe fornece o tripPIe,t(s, OL

,

x)

.

3. O monitor de x vai à matriz de proteção e verifica se exis -

te 4 em A (s, x). Se positivo o acesso é concedido, se negativo é sinalizada uma violação de proteção.

Pode-se observar que os atributos de acesso são examinados pe- lo monitor do objeto a cada tentativa de acesso, o que é uma carac terística importante num mecanismo de proteção. A organização deg te mecanismo pode ser representada pelo diagrama da fig. 3.2, onde os testes de acesso são invisíveis para os sujeitos, mas estão pre -

sentes em cada solicitação.

SUJEITOS I _{I MONImWS I} I _0BJEIY)S I ler F s SIS-DE

,1

1 _{I ARQUIVOS i} I I acordar P I

S F

j 1 I I I $1 I I I

Fig

.

3.2 Estrutura interna de um mecanismo baseado em matriz de acesso (GrD 72).

E

conveniente interpretar toda a informqão especificando os tipos de acesso de sujeitos a objetos como constituindo um ESTADO. de proteção do sistema. Uma vez que a matriz de acesso é dinâmi- ca, cada alteração na matriz significa uma mudança no estado de proteção. É condição fundamental que qualquer mudança sempre le- ve a outro estado protegido, portanto, alterações na matriz devem ser cuidadosamente controladas. Para isto, existe o monitor da própria matriz e da sua exatidão depende todo o sistema de prote- ção. Na organização da fig. 3.2, por exemplo, a matriz pode ser lida a partir de qualquer monitor de objetos, mas modificada ape- nas pelo seu próprio monitor.

As regras que gerenciam alterações na matriz de acesso são im -

plementadas através de um conjunto de operações permitidas. Por exemplo:

Transferir 06 a&, x)- autoriza o sujeito a transferir os di -

reitos de acesso que ele possui para outro sujeito.

Incluir oL em A(sr o)- autoriza um sujeito a incluir direi- tos de acesso em outro sujeito.

Muitas outras operações são facultadas a sujeitos na altera- ção da matriz de acesso, como inclusão e deleção de sujeitos e ob

-

jetos, etc.

A idéia lançada por Lampson inclui o uso de dfreitos denomina dos PROPRIEDADE,CONTROLE e

COPIA

como regras para criar, deletar e transferir atributos de acesso em uma matriz. O direito de pro priedade pode ser exercido para qualquer objeto (inclusive sujeir tos) e o direito de controle apenas para sujeitos. Desses direi- tos decorrem as seguintes autorizações:

C R I A G - Ã O

-

D E L E Ç Ã O

-

Um sujeito s pode adicionar qualquer di- reito de acesso a A (s'

,

x) para qualquer s' se s tem direito de propriedade sobre o objeto

x

.

Por exemplo, na fig. 3.1 sl pode adicionar "controle" em A ( ~ 2 , s2)

,

ou "Ler" em A (s3, £2) porque sl tem PRO- PRIEDADE sobre s2 e f2.

Um sujeito s pode deletar qualquer direi- to de acesso de A (s

'

,

x) para qualquer x se s tem direito de controle .sobbe o su- jeito s'. Por exemplo, s2 pode deletar "escrever" de A (s3

,

£2) e "parar" de A (s3

,

p1) porque s2 tem CONTROLE sobre

S3-

Se

*

aparece em A (s, x)

,

s pode colo car

*

QL OU a em A (s', x) para qualquer

s ' . Por exemplo, sl pode colocar "ler" em A (s2, fl) ou "*propriedade" em

A (s3. s2) porque sl tem

*

(C~PIA) em A (slr fl) e A ( S ~ P s2)

(OBS: a cópia é feita na mesma coluna). O asterisco de cópia é necessário para prevenir qualquer su- jeito não privilegiado de passar adiante atributos de acesso que lhe foram concedidos. Na figura 3.3 6 encontrado um resumo das instruções protegidas que modificam a matriz de acesso.

-

-Comando (por so) A

Criar objeto x Destruir objeto x Criar sujeito s Destruir sujeito s proprietário controle ou proprietário :controle ou proprietário nenhuma proprietário nenhuma proprietário operação rasultante armazenar 4 em A (s

,

x)

h1

armazenar ot em A(s,x)

{=@i

deletar &de A(s,x)

copiar A (s ,x) adicionar coluna. x em A armazenar "proprietário"

&-I

A(so,x) deletar coluna x de A adicionar linha

e

c01 , s em A armazenar "controle" em A'( s,, s

deletar linha

e

cola s de A Fig. 3.3

-

1nstruçÕes que modificam a matriz de acesso (GrD 72)

Graham defendeu a tese de que não énecessário haver distinção entre os direitos de propriedade e controle. ~ l é m disso, a noção de transferência pode ser extendida para incluir um modo TRANSFE- RÊNCIA PURA, no qual o direito de acesso transferido desaparece do sujeito que transfere. Por exemplo, se o simbolo " i " indica transferência pura, o sujeito s pode colocar .& ou 4 em A(s',x) sempre que

.

aparecer em A(s ,x)

,

mas nesse caso,

.

o( é deletado

de A (s,x). Pode-se desejar limitar o numero de proprietários de um objeto em exatamente 1. Assumindo que cada objeto tem inicial -

mente um proprietário esta condição será perpetuada permitindo a- penas

".

propriedade" ou "propriedade", mas não "*propriedaden.

2

importante notar que um modelo serve para ajudar a compreen são do funcionamento lógico de um sistema e não implica em nenhuz ma implementação particular. Assim, regras de acesso não preci- sam ser armazenadas na forma de uma matriz. De fato, esta seria uma solução muito ineficiente, porque em geral, a matriz de prote -

ção é esparsa e qualquer sujeito tem acesso apenas a um pequeno subconjunto do conjunto de ob j etos

.

Existem no mínimo 3 irnplementações práticas do modelo da ma- triz de acesso, A primeira usa a idéia de armazenar a matriz A por linhas, isto é, com cada sujeito s associado a uma lista de pares ( S I A ( s , x)), onde cada par 6 chamado CAPABILITY e a lista

é chamada C-lista (lista de capabilities). A segunda, :usa a idéia de armazenar a matriz A por colunas, isto é, com cada obje- to

x

associado a uma lista

de

pares (s, A ( 3 , X ) ) r chamada LISTA DE ACESSO. A terceira aproximação, CHAVE-FECHADURA,

6

uma combi- nação das duas primeiras, p& cada sujeito tem uma C-lista e cada objeto uma lista de acesso. A C-lista é composta por _entradas

(x,K) onde K é uma chave e a lista de acesso & composta por entra -

das (L, o ~ ) I onde L é uma fechadura e oC um atributo de acesso. O acesso é concedido quando a chave K "abrir" a fechadura L. Es- sas três implementações são estudadas em detalhe nas próximas se- ções.

Finalmente, utilizando o modêlo ' da matriz de pro-t;eçãci, Harrison, Ruzzo e Ullman (HRU 76) desenvolveram um modelo formal de sistemas de protecão e d-emonstraram que em casos restritos po- de ser demonstrado se um sistema é seguro, mas isto se torna 'im- possível de uma maneira generalizada. Surpreendentemente e sob hipóteses bastante fraaas; encontraram que não pode ser decidido se um sistema geral possui situações seguras. Isto acontece por- que os mecanismos de proteção são empregados % critério dos usuá- rios e liberam para estes os aireitos sobre seus objetos. Na realidade, se formos considerar êsse ponto de vista, nenhum siste -

ma é seguro no sentido de guardar hermeticamente objetos, mas ape nas possibilita aos usuários que tenham seus objetos "sob control leu.

Particularmente interpretamos a tese acima como uma consequên -

cia normal de qualquer esquema com tendências liberalizantes: a responsabilidade de proteção, que era potencialmente do sistema, fica descentralizada sobre seus usuários.

fi

essa a filosofia bá -

111.2

-

CAPABILITIES

Provavelmente a palavra mais usada nos meios ligados

5

seyuran ça de computadores na Última década tenha sido CAPABILITY. ~ a n t o g foram os sistemas, as teorias, as teses de mestrado e doubarado, que a idéia de capability é aplicada em pelo menos metade dos meca -

nismos de proteção de hardware e de software.

Basicamente, capability é um ticket que referencia um objeto e contém um conjunto de direitos de acesso, A posse de uma capabili -

ty é considerada como uma evidência de que o sujeito pode acessar o objeto das formas e apenas dessas formas descritas pela capabili -

tY

A idéia de capability foi lançada em 1966 por ~ e n n i s e - Van Horn (DeV 66) ao descrever mecanismos de proteção para sistemas de multiprogramação. Para controlar o acesso aos objetos do sistema, particularmente aos segmentos de memória, os autores sugeriram uma lista de capabilities, em que cada capability era constituída por 4 partes:

.

um indice numérico

-

através do qual a capability era chama- da pelos processos.

.

um indicador de propriedade

-

O para o objeto possuido,

N

pg ra

não

possuldo,

.

um pointer contendo o endereço do objeto.

.

vários indicadores de acesso

-

X para executar, R para ler e

w

para escrever.

O acesso a cada objeto protegido, por exemplo, um segmento de memória, era obtido pelo fornecimento do indice numérico d a capabi -

lity correspondente ao segmento. Cada job era constituído por um conjunto de processos possuindo a mesma C-lista (fig. 3 . 4 ) , e 2 processos com independentes C-listas nunca poderiamfazer parte do mesmo job, mesmo se elas fossem idênticas.

PROCESSO 1

C-LISTA

Uma vez que os dispositivos perlfésicos também eram recursos físicos do sistema, as funções de 1/0 também deveriam ser contro ladas por capabilities da C-lista do job. Durante a execução de um job, capabilities poderiam ser adicionadas ou deletadas da C- lista através de um mecanismo de esferas de proteção em que o processo executante "preparava" a esfera do processo seguinte, transferindo-lhe algumas de suas capabilities com autoridade se- melhante ou restringida.

Finalmente, cada usuário ou grupo de usuários do sistema cha mado PRINCIPAL podia ter um grupo de "objetos retidos", indepenr dentes da execução de jobs, os quais poderiam ser segmentos de memória, funções de 1/0, entradas ou diretórios organizados em árvores, onde cada entrada continha o nome do componente e uma capability para ele.

Posteriormente muitas modificações foram feitas nos contei-

tos iniciais de capabilities (Lin 76). Embora diferentes siste- mas as usem de formas bastante diversas, capabilities em geral possuem 3 propriedades:

.

Dado que existem capabilities para um objeto do sistema, êsse é o Único caminho possível para se chegar a ele.

.

Uma parte da capability determina os modos de acesso para o objeto.

.

A criação e modificação das capabilities estão subordina- das a uma parte do sistema de baixo nível e acesso restri- to.

Para impedir a criação de capabilities por usuários não auto -

rizados que através delas ganhariam acesso a objetos, existem 2 possibilidades: partição reservada e etiqueta.

O método da PARTICÃO RESERVADA consiste em manter na memória algumas localizações especiais como segmentos e registros apenas para capabilities, cujo acesso é vedado aos usuários. A solução por parti@o! é usada na Chicago Magic Number Machine e no Plessey System 250. Para cada:segmento definido no instante da !sua criação se o mesmo deve conter capabilities ou dados. ~ l é m dis- so, existe um grupo de registros de processado^ para dados e um para capabilitjles. O conjunto de instruções satisfazem regras como as seguintes: dados só podem ser copiados em segmentos de dados, capabilities só podem ser copiadas em segmentos de capabi -

lities, etc.

O método da ETIQUETA consiste em incluir em cada palavra da memõria um bit extra ou um conjunto de bits, inacessíveis aos u- suários, que identificam se a palavra é uma capability, caso em que apenas o sistema de proteção tem permissão para modificá-la. Usam etiquetas o Burroughs 6700, o Rice, a Basic Machine, entre outros. O S/38 da IBM utiliza etiquetas para autenticarpinters. Nesse sistema, as capabilities são pointers, munidos de direitos de acesso, que podem ser transcritos e armazenados indefinidamen te para uso postexior (BerBD). Também o BCC-500 utiliza etique- tas para validar capabilities, cuja estrutura é a da fig. 3.5.

Fig. 3.5

-

Capability etiquetada no sistema BCC-500 (Lam 69)

ETIQUETA

A etiqueta é legível apenas pelo supervisor. O tipo contém o ti- po do objeto, por exemplo, arquivo. O valor contém _ o endereqo,; por exemplo o índice no disco. Os atributos de acesso são os mo- dos permitidos de acesso ao objeto (Lam69).

As duas alternativas, partição e etiqueta são equivalentes,no sentido de que uma estrutura representada por uma delas pode ser transladada para equivalente na outra. Qual das duas ₆ a melhor? Fabcy (Fab 74) apresenta as vantagens e desvantagens da partição reservada.

_E

mais simples para suportar diferentes formatos de capabilities e dados, o que é importante pois as capabilities s"~. longas: em geral 64 bits. ~ l g m disso permitem fácil alocação, re cuperacão e modificação pelo sistema de proteção, pois estãÕ todas em locais conhecidos, eliminando os mecanismos de memória necessários para trabalhar com etiquetas. Entretanto, . como a

maioria dos objetos necessita simultaneamente capability e dados; dois segmentos precisam ser qmnuseados em vez de apenas um, como no caso das etiquetas.

TIPO

A coexistência de capabilities e dados no mesmo objeto também pode ser obtida sem a existência de arquiteura etiquetada como propõe Anita Jones ( ~ o n 80) pela introdução de uma CERCA de separa ção entre dados e capabilities- Esta cerca é usada para testes de ~{erificação de limite, os quais garantem que as tcapabilities são manipuladas apenas por operações apropriadas do sistema.

O índice nqérico criado por Dennis e Van Horn para identifi car cada capability numa C-lista, atualmente se chama identifica1 dór e não necessita ser numérico, podendo ser implementado de duas maneiras :

VALOR

.

o identificador é um pointer para o objeto, contendo seu en dereço e limite, ou alternativamente um pointer para uma tã -

bela de indireção ou paginação.

ATRIBUTOS DE ACESSO

.

o identificador é um código Único em todo o sistema e está permanentemente associado ao objeto, sendo chamado identifi

-

cador Único (Lin 76)

.

Na primeira maneira, existe o inconveniente de se precisar a- tualizar periodicamente as capabilities sempre que o objeto mudar de endereço (ou as tabelas de indireção). A segunda maneira tem sido mais utilizada, embora tenha o inconveniente de ser 'one-way' cada identificador tem que ser Único para toda a vida do Skstema e seu tamanho varia em torno de 50 bits.

Frequentemente um sujeito tem permissão para transmitir 1 , uma

cópia ou outorgar uma capability a outro sujeito. Na matriz de proteção isto significa a inclusão das regras de acesso da capabi lity na interseção da linha do novo sujeito com a colunadoobjet~, como na fig 3.6.

X,.

1

Fig. 3 . 6

-

Efeito da transmissão de capability na matriz de aces- so (Pop 7 4 )

No sistema HYDRA, por exemplo, as capabilities podem ser pas- sadas de um usuário para outro, inclusive podendo : ser ,retidas por usuários entre sessões de terminais. Ob~~etos nãó possuem "pro prietários". Todos os portadores de capabilities para um objetõ dividem o controle entre si na proporção dos seus direitos.

e

cla -

ror se um usuário retiver para si todos os direitos em relação a um objeto, se torna proprietário na prática. Apenas o núcleo do sistema pode manipular capabilities, assim, é impossível falsifi- car uma capability ou obter acesso a um objeto sem possuz-la. ~ l é m disso, ao contrário da maioria dos sistemas baseados em capa bilities, no HYDRA, não apenas os sujeitos, mas também os objetos podem conter C-listas, por exemplo, um diretório pode conter capa bilities para objetos do tipo arquivo e semáforo (CoJ 75,.Jon 80).

Um ponto importante envolvendo transmissão de capabilities diz respeito 5 REVOGAÇÃO de direitos. Em algumas situações é neces- sário revogar os direitos de acesso que tenham sido previamente concedidos. Se as capabilities que representam esses direitos ti -

verem sido copiadas muitas vezes, medidas especiais precisam ser tomadas. A mais simples de todas é fazer uma cópia do objeto e deletar a versão antiga, mas isso pode destruir os direitos de acesso de outros sujeitos autorizados e aausar a existência de li xo na memória representado pelas capabilities de "objetos-fantasz mas". No sistema CAL-TSS as capabilities não apontam para obje- tos diretamente, mas para uma entrada de uma tabela globalta qual aponta para o objeto, A revogação é realizada simplesmente pela deleção da entrada na tabB3.a global. Torna-se necessário obter uma nova capability para o objeto e distribui-la pelos sujei%os que permanecem autorizados. As entradas na tabela podem ser reu- sadas sem risco, porque tanto a capability como a entrada na tabe la contém o mesmo nome interno do objeto, que é verificado.

as

este sistema causa o aparecimento de diferentes cópias de uma ca5 pability apontando para a mesma entrada (LaS 7 6 ) .

~evogação seletiva desativando apenas as ~ a p a ~ i l i t e s desejadas pode ser feita construindo-se um grande número de pointers retroa- tivos, que acompanham a trajetoria das capabilities entre os pro- cessos. Isto foi feito na 15a. revisão do Multics para refletir as mudanças de uma entrada no diretorio diretamente nos descxito- res de registros, mas é uma alternativa cara.

A revogação seletiva pode ser implementada de uma forma mais econõmica, pela criação de capabilities revogáveis que apontam pa- ra um objeto indiretamente através da capability principal do obje to. A capability revogável pode ser desativada sem alterar a prin

-

cipal

.

Outra solução, contida na tese de Anita Jones é a deleqão _pg riódica de todas as capabilities dos processos forçando a sua rea- quisição.

E

controvertida no aspecto de que o perzodo de ativida- de de cada processo é muito pequeno e a revogação só pode ocorrer quando o processo é suspenso ou encerrado. Por exemplo, não seria possivel ao proprietário de um arquivo revogar o acesso de um pro- cesso que já o tenha aberto e o esteja utilizando (Lin 76).

Finalmente, as capabilities podem ser colocadas em "caixas fe- chad&sWe passar como num correio entre processos que tem autoriza- ção para transmití-las mas não para exercê-las até um processo fi- nal que as recebe e utiliza. Capabilities especialmente aplicadas

à criação de domínios protegidos para processos são vistas na se- ção VI.4.

111. 3

-

LISTAS DE ACESSO

O armazenamento da matriz de acesso por colunas dá origem 5s LISTAS DE ACESSO, 5s vezes chamadas listas de controle de acesso. A cada objeto é ássociada uma lista contendo nome de todos os su- jeitos que podem acessá-10 com os respectivos modos de acesso. Listas de acesso não necessitam conter endereços e pointers como no caso das capabilities, embora isso possa acontecer. A fig.3.7 mostra a diferença entre as duas formas de armazenamento.

LISTA

Fig. 3.7

-

~omparação dos mecanismos de capabilities e de listas de acesso.

A grande vantag.em . d o mecanismo de listas versibilidade dos ligamentos, tão difícil de canismo de capabilities. Para se modificar de um sujeito, basta alterar ou eliminar esse acesso do objeto. de acesso 6 a a@- ser executada no me ou excluir o acessõ sujeito da lista de 4

O exemplo mais simples de uma lista de acesso e encontrado

KSOS (CaD 79). Embora este sistema tenha sido projetado especifi

camente para implementar o mecanismo de multiníveis não-discreciõ -

nários, razões de flexibilidade ocasionaram a criação de uma pe- quena lista de acesso para cada objeto. Esta lista e composta por apenas 9 bits que especificam os tipos de acesso: ler, escre- ver e executar/pesquisar para o proprietário, outros usuários do mesmo nzvel, todos os outros usuários. ~ l é m de ser sLmples, 6 e- ficiente e barata, pois a maior parte do overhead é transferida para o controle dos níveis.

Listas de acesso trazem à tona um problema muito característi co: o controle de quem pode modificar a informação de controle de acesso, No mecanismo de capabilities, esta consideração está difcsa, pois um sujeito que possui uma capability pode ter a auto -

ridade de propagá-la. Na lista de acesso, o controle está mais preciso e,centralizado, o que é vantaqem, mas também exige >uma forma eficiente de ser exercido. O objetivo principal deste meca- nismo é gerar dentro do computador uma estrutura de autorização que reflita ou modele a estrutura da organização que utiliza O computador. Basicamente, 2 políticas podem ser modeladas: auto- controle e controle hierárquico (SaS 75).

AUTO-CONTROLE é o esquema mais simples. Neste, o conceito de bits de permissão pode ser extendido para bcluir não apenas auto rização para ler e escrever, mas também autorização para modifil car a própria lista de acesso em que estão contidos. Suponhamos por exemplo que a criação de um novo objeto esteja condicionada 5

criação de uma lista de acesso cuja entrada inicial contém todas as permissões para o sujeito que a criou. Assim, o criador rece- be um pointer para esta lista e pode construi-la contendo quais- quer sujeitos com quaisquer direitos de acesso ao objeto recém- criado. Provavelmente a maior objeção ao auto-controle seja O seu "absolutismo": não há previsão para mudanças de autoridade que não tenhamsido antecipadas pelo seu criador. Por exemplo, num sistema de time-sharing comercial, se o chefe de um departamento qualquer estiver doente, não há meio de um funcionário de sua con fiança adquirir acesso temporário a um ,rquivo recém-criado. pior que isso, o auto-controle pode criar objetos completamente inaces -

siveis, gerando lixo na memória.

Para eliminar esses problemas tem sido usado o esquema de CON -

TROLE HIERÃRQUICO. Neste, sempre que um novo objeto é criado, o criador tem que especificar algum controlador de acesso previamen te existente para regular as futuras mudanças de acesso. Cada

COE

trolador pode ser em si mesmo uma lista de acesso de outro objetõ, o que origina uma árvore de listas de acesso. A interpretação de

"bit de modificação da lista" é modificada para um pointer que vem da lista imediatamente superior à lista corrente. A aproxima -

ção hierárquica modela o controle de acesso, pois um usuário com autoridade para modificar uma lista de acesso tem tambem; autori- dade para modificar todas as listas de acesso que se encontram a- baixo desta.

O controle hierárquico é usado em sistemas de tempo comparti-

-

lhado como se segue. Ao primeiro controlador de acesso e : as- sociada uma lista de acessos no nome do administrador do sistema. Este cria vários controles de acesso, por exemplo, um para cada departamento na sua companhia e confere permissão de modificar a- cesso ao administrador de cada departamento. Cada administrador pode, adicionalmente, criar controladores de acesso para os subde partamentos e assim por diante. Qualquer forma de compartilhamen -

to pode ser modelada pela simples criação de listas de acesso. Em uma emergência, os administradores (ou seus back-ups) ?o- dem intervir e modificar qualquer lista de acesso das suas subar- vores.

A obje$ã6 a este esquema é que os administradores ficam mui- to poderosos. Pode-se argumentar que o sistema está simplcismente espelhando a realidade de uma empresa em que a responsabilidade e o poder estão associados a uma hierarquia. Entretanto, no compu- tador, existe uma diferença: o abuso do poder quase sempre passa desapercebido. Para solucionar esse problema foi sugerido que se adicionasse ao controlador de acesso um campo chamado PRESCRIÇÃO. Sempre que uma tentativa de modificar uma lista de acessos 6 ~fei- ta, a permissão de modificação só é concedida após a verificação do campo de prescrição, que contém diretrizes, as quais podem ser:

.

gravar no histórico do sistema a modificação.

.

adiar a alteração por um dia (período de "descongelamento'?)..

.

aguardar que a alteração seja confirmada por outra pessoa. Nos casos mais sérios, a prescrição pode significar que a al- teração só pode ser realizada se for confirmada por um comitê de representantes de vários departamentos ou grupos de usuários. To das estas politicas de segurança podem ser implementadas utiliza6 -

do o mecanismo das listas de acesso com controle hierárquico e não apenas uma hierarquia pura e simples como se imagina a priori. A noção de "prescrição" na realidade, muda as estruturas empresa- riais típicas permitindo que o controle seja realizado em todos os níveis. Embora aparentemente essencial a um mecanismo de pro- teção, não se conhece um sistema real que a tenha implementado.

Nos sistemas de arquivos os diretórios funciona,mi analogamen- te 5s listas de acesso. Associado a cada arquivo h& um.:nbero de bits especificando quem pode acessá-10 e de que maneira. Como a grande maioria dos diretórios são organizados em árvores, pode-se concluir que empregam o esquema do controle hierárquico. Na se- ção V.4 serão revistas as listas de acesso usadas em diretórios.

A política de isolamento completo pode ser implementada atra- vés do mecanismo de listas de acesso: basta restringir cada lis- ta a apenas uma entrada, que representa apenas um usuário. Este

é um caso extremo e também não foi implementado na prática.

Um dos sistemas pioneiros no uso de listas de acesso para pro teger objetos é o MULTICS. Neste sistema, sempre que um objeto

é

criado ganha como default uma lista semelhante à do diretório em que o objeto é adi~ianado. Se o proprietário desejar -pode modificá la a seguir, e a lista resultante ficará "ligada" ao objeto, sen- do consultada a cada tentativa de acesso. Todos os diretórios fa zem parte de uma estrutura onde sujeitos autorizados a modificar- elementos dos níveis superiores tem permissão para modificar 6s que lhes são subordinados, inclusive a lista de acesso inicial

(Sal 74a).

Listas de acesso correspondem mais aos objetivos dos usuários, pois é mais fácil controlar o acesso a um objeto ou a um grupo de objetos, do que, seletivamente controlar os sujeitos que podem a- cessá-lo, Entretanto possuem diversas desvantagens. A 'iríforma- ção de um processo em execução não está localizada e convemÕes entre nomes globais e locais devem ser constantemente realizadas antes dos testes de proteção. Isto significa que mesmo nas situa çÕes em que o acesso 6 recusado, o sistema já sofreu o impacto de todas as conversões e operações de endereçamento. Portanto, as capabilities são consideradas melhores para representações inver- sas e processamento. Um sistema pode lucrativamente utilizar am- bas se tiver um bom mapeamento e a atualização das listas de aces so for convenientemente refletida na atualização das capabilities. Tanto o CAL-TSS como o MULTICS são sistemas que usam ambos os me- canismos (Pop 74)

.