Quando se quer fazer uma mudanc¸a de pol´ıticas global envolvendo v´arios dom´ınios de seguranc¸a, ´e utilizado o algoritmo de actualizac¸˜ao de anteparas em v´arios dom´ınios.
O algoritmo 3 descreve o comportamento do manager m quando este inicia o processo de actualizac¸˜ao de pol´ıticas em v´arios dom´ınios, ou seja, a actualizac¸˜ao de um conjunto de enforcers que se encontram em v´arios espac¸os l´ogicos. O manager tem acesso a todos os espac¸os de tuplos nos v´arios dom´ınios. Para cada dom´ınio, existe um conjunto de vari´aveis privadas: o status define se houve sucesso ou insucesso na aplicac¸˜ao da nova pol´ıtica num determinada espac¸o, o ugroup ´e o conjunto de enforcers de cada dom´ınio que vai ser actualizado com novas pol´ıticas e por ´ultimo, a vari´avel notDeployed define quais os enforcers de cada dom´ınio que n˜ao aplicaram a pol´ıtica de seguranc¸a.
A func¸˜ao policy update context() recebe quatro parˆametros: f (define o n´umero m´axi- mo de falhas de enforcers que pode ocorrer durante o processo de actualizac¸˜ao de pol´ıti- cas), new p (matriz com as novas pol´ıticas que ser˜ao enviadas para todos os enforcers, de todos os dom´ınios), timeout (tempo m´aximo que os enforcers esperam pelo manager pela finalizac¸˜ao do processo de actualizac¸˜ao) e por ´ultimo, o utype (tipo de actualizac¸˜ao que define que pol´ıticas devem ser aceites enquanto o processo de actualizac¸˜ao ainda n˜ao foi finalizado, descrito na Secc¸˜ao 3.7).
O algoritmo 3 utiliza as mesmas func¸˜oes externas que os algoritmos anteriores e ´e constitu´ıdo pelos seguintes passos:
1. m insere um tuplo POLICY (para cada enforcer em cada dom´ınio administrativo). Estes tuplos ser˜ao depois consumidos pelos enforcers. (linhas 2 a 5);
2. m insere um tuplo CONTEXT em todos os espac¸os de tuplos associados aos dom´ınios para anunciar que existe um novo contexto. Este novo contexto (ver Secc¸˜ao 2.1.1) ir´a actualizar as pol´ıticas destes espac¸os de tuplos (linha 6);
3. m continua a ler tuplos DEPLOYED em todos os espac¸os de tuplos associados aos dom´ınios, at´e que todos os enforcers (menos poss´ıveis faltosos) apliquem as suas novas pol´ıticas. Esta parte ´e executada em paralelo, atrav´es de v´arias threads, uma para cada dom´ınio, no entanto, optou-se por descrevˆe-la de forma sequencial para manter a simplicidade (linhas 8 a 23);
4. Depois de todos os enforcers actualizarem as suas pol´ıticas, ´e altura de verificar se o contexto foi aplicado com sucesso ou n˜ao, em cada espac¸o (linha 24);
5. m insere um tuplo CONTEXT DEPLOYED em todos os espac¸os de tuplos asso- ciados aos dom´ınios, indicando o sucesso/insucesso na realizac¸˜ao da actualizac¸˜ao (linhas 25 a 27);
Cap´ıtulo 3. Algoritmos de actualizac¸˜ao de pol´ıticas coordenadas 29
Algoritmo 3 Manager - Actualizac¸˜ao de Anteparas em v´arios dom´ınios Shared variables:
1: ts1, · · · , tsn← ∅ {espac¸o de tuplos partilhado}
Private variables:
1: statusj ← ∅ {para cada dom´ınio 1 . . . n}
2: ugroupj ← ∅ {para cada dom´ınio 1 . . . n}
3: notDeployedj ← ∅ {para cada dom´ınio 1 . . . n}
procedure policy update context(f, new p, timeout, utype)
1: id ← nextId()
2: for all 1 ≤ j ≤ n do 3: for all pk∈ ugroupj do
4: tsj.out(hPOLICY, id, pk, new p[j][k]i)
5: end for
6: tsj.out(hCONTEXT, id, f, ugroupj, timeout, getT ime(), utypei)
7: end for
8: for all 1 ≤ j ≤ n do 9: expired ← f alse
10: notDeployed ← ugroupj {enforcers que ainda n˜ao aplicaram a pol´ıtica}
11: while | notDeployed |> f ∧ ¬expired do 12: for all pk ∈ ugroupj do
13: if tsj.rd(hDEPLOYED, id, h(new p), ?pji), timeout) then
14: notDeployed ← notDeployed \ {p} 15: else 16: expired ← f alse 17: end if 18: end for 19: end while 20: if ¬expired then 21: status ← true 22: end if 23: end for
24: status = statusj∧ · · · ∧ statusn
25: for all 1 ≤ j ≤ n do
26: tsj.out(hCONTEXT DEPLOYED, id, status, notDeployedj, ugroupj \
{notDeployedj}i)
27: end for
Cap´ıtulo 3. Algoritmos de actualizac¸˜ao de pol´ıticas coordenadas 30
O algoritmo 4 descreve o comportamento do enforcer pi quando o mesmo transita
para o estado de actualizac¸˜ao de pol´ıticas em v´arios dom´ınios, i.e., quando o manager cria um novo contexto no espac¸o l´ogico onde pi est´a inserido.
Algoritmo 4 Enforcer pi - Actualizac¸˜ao de Anteparas em v´arios dom´ınios
Shared variables:
1: ts ← ∅ {espac¸o de tuplos partilhado}
procedure policy update()
1: id ← nextId()
2: if ts.rd(hCONTEXT, id, ?f, ?ugroup, ?timeout, ?ts, ?utypei then
3: if pi ∈ ugroup then/
4: return
5: end if
6: if ts.rd(hPOLICY, id, pi, ?new pi) then
7: applyP olicy(new p, utype)
8: ts.out(hDEPLOYED, id, h(new p), pii)
9: expired ← f alse
10: if ts.rd(hCONTEXT DEPLOYED, id, ?status, ?f ailed, ?successi, timeout) then
11: if status = true ∧ ¬expired then
12: applyP olicy(new p, N EW ) 13: else
14: applyP olicy(φ, ROLLBACK)
15: end if 16: end if
17: end if
18: end if
O algoritmo ´e constitu´ıdo pelos seguintes passos:
1. Se pi lˆe um tuplo CONTEXT, o processo de mudanc¸a de contexto ´e iniciado e o
algoritmo ´e executado (linha 2). Se pi ´e um membro desse grupo, o algoritmo ´e
executado, sen˜ao retorna (linhas 3 a 5);
2. pi lˆe o tuplo POLICY do espac¸o de tuplos associado ao dom´ınio, que cont´em a
pol´ıtica a ser aplicada (linha 6);
3. pi aplica a pol´ıtica de seguranc¸a (de acordo com o tipo de actualizac¸˜ao que se en-
contra descrito na Secc¸˜ao 3.7), atrav´es da func¸˜ao applyPolicy() (linha 7);
4. pi insere um tuplo DEPLOYED, representando o sucesso de obter a nova pol´ıtica
(linha 8);
5. pi espera pela resposta do manager, indicando o sucesso/insucesso no processo de
Cap´ıtulo 3. Algoritmos de actualizac¸˜ao de pol´ıticas coordenadas 31
6. Se o processo de mudanc¸a de contexto for um sucesso, i.e., se todos os dom´ınios actualizarem as suas pol´ıticas, ent˜ao pi aplica a nova pol´ıtica, passando apenas a
aceitar pacotes que respeitem a mesma (atrav´es do parˆametro NEW na func¸˜ao ap- plyPolicy()- descrito na Secc¸˜ao 3.7). Se ocorrer um timeout, pi faz um ROLLBACK
e aplica a pol´ıtica antiga, ou seja, a que estava em aplicac¸˜ao antes do in´ıcio do processo de actualizac¸˜ao (linhas 11 a 15);
A pol´ıtica de controlo de acesso (ver Secc¸˜ao 2.4.3) do espac¸o de tuplos usada pelos algoritmos 3 e 4 est´a descrita na Figura 3.6.
Object State T S
Rrd: execute(rd(t)) : − invoke(p, rd(t))
Rpolicy: execute(out(hPOLICY, id, e, new pi)) : −
invoke(m, out(hPOLICY, id, e, new pi)) ∧ @id, e : hPOLICY, id, e, ∗i ∈ T S ∧ manager(m)
Rcontext: execute(m, out(hCONTEXT, id, f, ugroup, timeout, ts, utypei)) : −
invoke(m, out(hCONTEXT, id, f, ugroup, timeout, ts, utypei)) ∧ @id : hCONTEXT, id, ∗, ∗, ∗, ∗, ∗i ∈ T S ∧
∀j ∈ ugroup : hPOLICY, id, j, ∗i ∈ T S ∧ manager(m) Rcontext deployed:
execute(m, out(hCONTEXT DEPLOYED, id, status, notDeployed, deployedi) : − invoke(m, out(hCONTEXT DEPLOYED, id, status, notDeployed, deployedi) ∧ ∃id : hCONTEXT, id, ∗, ∗, ∗, ∗, ∗i ∈ T S ∧
@id : hCONTEXT DEPLOYED, id, ∗, ∗, ∗i ∧
(∀ps ∈ deployed : hDEPLOYED, id, h, psi ∈ T S) ∧ manager(m)
Rdeployed: execute(out(hDEPLOYED, id, h, ei) : −
invoke(p, out(hDEPLOYED, id, h, ei)) ∧
∃id : hPOLICY, id, e, new pi ∈ T S ∧ enf orcer(e) ∧ p = e ∧ h = h(new p)
Figura 3.6: Pol´ıtica de seguranc¸a do espac¸o de tuplos usada nos Algoritmos 3 e 4. Assim como na pol´ıtica anterior (na Figura 3.5), a leitura de qualquer tuplo ´e permi- tida atrav´es da regra Rrd. A regra Rpolicy, tamb´em descrita na pol´ıtica anterior, permite
a inserc¸˜ao de tuplos POLICY se n˜ao houver outro tuplo do mesmo tipo no espac¸o de tuplos com o mesmo identificador, da actualizac¸˜ao e do enforcer. A regra Rcontext ´e si-
milar `a regra Rnew policy da pol´ıtica anterior (ver Figura 3.5) que define que apenas se
pode inserir o tuplo CONTEXT se n˜ao houver outro do mesmo tipo com o mesmo id e que todos os tuplos POLICY com o mesmo identificador da actualizac¸˜ao, definidos no ugroup estejam no espac¸o. A regra Rcontext deployed define que s´o deve ser inserido
no espac¸o o tuplo CONTEXT DEPLOYED se n˜ao houver um tuplo do mesmo tipo e houver um tuplo CONTEXT, ambos com o mesmo identificador de actualizac¸˜ao. Fi- nalmente, a regra Rdeployed descrita na pol´ıtica anterior, define que s´o pode ser inserido
Cap´ıtulo 3. Algoritmos de actualizac¸˜ao de pol´ıticas coordenadas 32
o tuplo DEPLOYED quando existe um tuplo POLICY com o mesmo identificador da actualizac¸˜ao e o id do processo que o est´a a inserir seja o mesmo id do enforcer do tuplo DEPLOYED.
As regras Rpolicy, Rcontext e Rcontext deployed definem operac¸˜oes que s˜ao executadas
apenas pelo manager, ao contr´ario da regra Rdeployed que define a regra de inserc¸˜ao de
tuplos DEPLOYED por parte do enforcer.