<%BANNER%>

Voting-enabled role-based access-control model for distributed collaboration

University of Florida Institutional Repository
xml version 1.0 encoding UTF-8
REPORT xmlns http:www.fcla.edudlsmddaitss xmlns:xsi http:www.w3.org2001XMLSchema-instance xsi:schemaLocation http:www.fcla.edudlsmddaitssdaitssReport.xsd
INGEST IEID E20101123_AAAAAB INGEST_TIME 2010-11-23T05:18:11Z PACKAGE UFE0011941_00001
AGREEMENT_INFO ACCOUNT UF PROJECT UFDC
FILES
FILE SIZE 32975 DFID F20101123_AAACCD ORIGIN DEPOSITOR PATH manian_v_Page_041.QC.jpg GLOBAL false PRESERVATION BIT MESSAGE_DIGEST ALGORITHM MD5
b928f6274c88250bde6380a5083d2292
SHA-1
99b81ed6aca6ffd39126a80bcb9cc18603393223
6229 F20101123_AAACBO manian_v_Page_031thm.jpg
b2d3637b517276d188ee5c5ca5332cf1
1a653d1bdb4349a74b2f0c4be6b93fa23bc767a9
1936 F20101123_AAABWI manian_v_Page_009.txt
2d80d2b451284d890813c78688c61c40
3165911d110a21ee4830c2825ac8a6db4437a24c
44050 F20101123_AAABVU manian_v_Page_097.pro
555a1add18704b96b14735f1c55bf9df
57191fdbfe5555eee7f3c7905f9ed6fc0a4c7a12
7378 F20101123_AAACCE manian_v_Page_042thm.jpg
1e9ae6d3b505edf072bd9a938a2aa120
b82f2e1aff5c15b94865ef55f78c6afd4fb7a5f9
23180 F20101123_AAACBP manian_v_Page_031.QC.jpg
351222039a3861aedf8fe38371c66cc3
52323554e01bc6f0a3da66b10fa0ea73123bb874
230 F20101123_AAABWJ manian_v_Page_010.txt
031ecf97a89732f5d16400366711d6de
c33910ff6a947b24090e85309d745b5536f0a863
6512 F20101123_AAABVV manian_v_Page_099.pro
93e6cdd8e7d9f7a923715612d6d3a44f
e8369bcb26cb878a724916be3859162e60722f44
27871 F20101123_AAACBQ manian_v_Page_032.QC.jpg
587310a5b8bfd8d3c0d2f3fc38721c4d
aad1806b32b05834bd7a931b5d21f111e4727306
1926 F20101123_AAABWK manian_v_Page_011.txt
d3187d78e2d63f73d7ccf31a2c2b97cf
3fc90adfa39829e40c7f5766c6320da72ac85e2e
49679 F20101123_AAABVW manian_v_Page_100.pro
e3b7adb0d1e449cef2510b92006c51dd
0eeb813993308e72d5f6c37bdbbed0ec873c0231
26089 F20101123_AAACCF manian_v_Page_043.QC.jpg
a5c6c17ef356246aa9f59131ec7299ef
5d78099e22a0d847d115615c43ba5b852567d2f9
7031 F20101123_AAACBR manian_v_Page_033thm.jpg
89c9b6a56f2ffdb4d989d72ff0594e9d
a7cf4768a5812e781b4340634b6f1e7bba7c3a33
1829 F20101123_AAABWL manian_v_Page_012.txt
33c43c6249285b4a4a3a13a1b514d934
d215810feaa677fb836333d500d3adde7371c240
58222 F20101123_AAABVX manian_v_Page_101.pro
b34d61dc035890333575b13d26abe285
b503e7fd750e00630570c446cbcb229f08896888
5898 F20101123_AAACCG manian_v_Page_045thm.jpg
73fe7c453a712654c13de171c46baf97
4ca75245c64e19b062145c0e4b14dd338f73ec45
1994 F20101123_AAABXA manian_v_Page_030.txt
f6bd9e2d208d425ec5e1b3d1c547d3bd
aab61ac830bce47226496872cbd960c6e5b2086a
29554 F20101123_AAACBS manian_v_Page_033.QC.jpg
1a8b710a7b2cc1989313346fb4ad2a08
44c20d03890132997c75960f37e1db4a8d0035b3
2527 F20101123_AAABWM manian_v_Page_013.txt
b3ea5780460d5955c610a138e679f2c9
e35615a7f1e92d46554c0ff717ab4316a95f701c
55698 F20101123_AAABVY manian_v_Page_102.pro
63f186901bdafca7bb8313c1c14a227d
2a1114ade68d5173fd1e345f4338604ab76a19d9
23356 F20101123_AAACCH manian_v_Page_045.QC.jpg
81c78bce32be4db0877ab5b91eac1c9f
508e8a33fb2c4b6a83a6dc4b31c7c0067f5bf6b1
1784 F20101123_AAABXB manian_v_Page_032.txt
635184093bdefc15ceff7c697e5ecff2
878978b0c4bf0c52a78b3c799311ce4f9ddb6cb5
7390 F20101123_AAACBT manian_v_Page_034thm.jpg
3c236acd84fc207a1923f40d582415b4
5c7504e7c74319f2e782c472b189e399b851c1ef
2029 F20101123_AAABWN manian_v_Page_014.txt
ec9b1e282f7a58b82b9c356d33e62890
2b7f5c8e87c079c01b127012d83b88ede5fee1e8
7260 F20101123_AAACCI manian_v_Page_046thm.jpg
f613948b2e5414e6e95bff8c92b4b4bf
db1e6f01e24a80b9568fa097d650e606d035bb36
1951 F20101123_AAABXC manian_v_Page_033.txt
0a3560e82fb7c3b45e81f8ccef314bd3
bb60b1ef2d7bc9da97ebfddfeb68efdc78a48eed
30297 F20101123_AAACBU manian_v_Page_034.QC.jpg
141fb5469bca3b980686dc5f05b31e5d
5ee4f49209e9f3a74634729e008e34306ddc5029
1234 F20101123_AAABWO manian_v_Page_015.txt
09f70b9208cdf475c288112b9d71428f
1abe725da1c99eddd3857968f69e9886e858af04
60013 F20101123_AAABVZ manian_v_Page_103.pro
049eaaa44c617d9cfc676a1c0096f36c
4200ed1cd7a0721e5629ffb45a50cbcf33868d6f
31104 F20101123_AAACCJ manian_v_Page_046.QC.jpg
703c189b385aba3ddc188fe903d00b1c
b710f9b882ad45bf23895e5cdc6ef6b267913904
2018 F20101123_AAABXD manian_v_Page_034.txt
10035c5aa06bfb992325e40107552396
9c31e4c06b0eaa847171023f5d53afc19d38f9b9
29493 F20101123_AAACBV manian_v_Page_035.QC.jpg
b01e3701705e95cf71476887f8054209
76f093b45b0b412bf3dd1f67a20eb7a24c98ab79
758 F20101123_AAABWP manian_v_Page_016.txt
ae955a089b2109cc0caf018f6c1cd41f
4220bf80368d97b6a88e6ce370f65dcbbb7c635c
3280 F20101123_AAACCK manian_v_Page_047thm.jpg
5131fe7297fa45ed8e3030029e604982
e23c77a160a361531be92e3862529984e36c90a9
2160 F20101123_AAABXE manian_v_Page_036.txt
a2818c9124cdf9f47337310a727e21aa
f7037a7dfab0cf8ba35bc3d2f6c8f90f8dc3921e
6999 F20101123_AAACBW manian_v_Page_036thm.jpg
83482433e9d8fa5c609567db3caad0cc
e794dd6fa8bee699049834b704b5ebf5129346cc
2195 F20101123_AAABWQ manian_v_Page_018.txt
2bc1ac9cd590cadec41f47c0df3c81a1
eb5d3b2ee53198ab8a52743bb8def1b749564c32
12087 F20101123_AAACCL manian_v_Page_047.QC.jpg
71cd55880127d5f146800a1c48f9b266
83e92904b5aad3ce65dc8c3c60aa1ad42f02f054
1991 F20101123_AAABXF manian_v_Page_037.txt
0187155ed6d2d333608e9eeb8ba21b0c
a14084cb021406b7949ee818c574a145d61b61ce
29257 F20101123_AAACBX manian_v_Page_036.QC.jpg
cfe4880d18cee2d6fa9eadc54b7cb70c
84e5e8ac619cd171ac46c24e1a129a2b16b63199
2372 F20101123_AAABWR manian_v_Page_019.txt
5d25d3fa5a3a45dc137602a65bfab494
cf8a9b3cfd60b5594b446b99153aae32836318dd
7207 F20101123_AAACDA manian_v_Page_056thm.jpg
27bf059af2e7769d943ca706cab93ab2
40bd4da8b3c69acf18155b13c839d3bbdf90e25b
2535 F20101123_AAACCM manian_v_Page_048thm.jpg
e286c08e6839ccbc891045e44b4d8a02
d09c03967107301d94e6667f09b5ed24c2a458d4
1762 F20101123_AAABXG manian_v_Page_038.txt
6be0f3c33b780123a1bf6f4f369b5cd7
585c91d3076fa9983e7459a1059ee47b1cf09d94
29831 F20101123_AAACBY manian_v_Page_037.QC.jpg
6a8172d12dad01b885b3a750e2a9331c
cb3960de94832318fefa29942dc9cd3122c75588
1846 F20101123_AAABWS manian_v_Page_020.txt
0715e2309baed1905270f558eecfd63e
1255ffb8c41b744d8176450928cf2c5e2f399b21
30775 F20101123_AAACDB manian_v_Page_056.QC.jpg
9e2f380fbdbf0ecd812a7856742cc2ce
b67ddbf9422b87eec6bb0fe1face25d41ec6509e
8754 F20101123_AAACCN manian_v_Page_048.QC.jpg
c3964cb77836c4971466bca9e8cf270c
57a96310a0fe67a677f3cd4fdbe245defd67bc19
2180 F20101123_AAABXH manian_v_Page_039.txt
83b8d5fb9e40e6292a76eae67a2cdff9
a4f9e17dbaa439bde948f7e48e7a39a1be46bef7
6800 F20101123_AAACBZ manian_v_Page_038thm.jpg
576411e0ee78da2a968f69bd6b1aa296
e2003ef083ce4136a2323b58670d303cea562564
94 F20101123_AAABWT manian_v_Page_021.txt
c07f344a1c612a981738a9b72b74357a
9c2a37fd6e28e497b0622635025542ccea09cff7
7180 F20101123_AAACDC manian_v_Page_057thm.jpg
d350b4953246eb23e1085bb4234bd228
d7afe9df2785b59709811e77680b0d54ad177cf9
27162 F20101123_AAACCO manian_v_Page_049.QC.jpg
4da2ead56a38f4a5979831ba549cbe24
5fa8855419b3f4de63d7df2370619364fbdcdc65
2226 F20101123_AAABXI manian_v_Page_040.txt
90c0b72a155e8f46a647a1b5ce1bb38f
d0ac53d74fd72742b3e8563629818e0d14efcf72
2158 F20101123_AAABWU manian_v_Page_023.txt
5027c5b140d34990fee60952fd7ccb2d
51faae765fef023764919f3de029fcca16e1cb8f
32097 F20101123_AAACDD manian_v_Page_057.QC.jpg
4ee66167fcd44ce0c38b13cd7f3f33f7
d57f76a60e4089d1f79899928a1227e4244486b7
22816 F20101123_AAACCP manian_v_Page_050.QC.jpg
d626633dea89a79dfe649f09fd10fe68
41ce605a7dc6a2e524f4380bdf39f1b43fb5828d
2182 F20101123_AAABXJ manian_v_Page_041.txt
c9de3d22bcfc411e473d5261dc35c9fd
636326697c6a6703de0a604532184f6d231cfbe0
2015 F20101123_AAABWV manian_v_Page_024.txt
ca266411cd0373a8ec0f03838608bda5
3c93d8c1d95ea89afb084b4be79eb5cd14459c91
6885 F20101123_AAACDE manian_v_Page_058thm.jpg
5d1273ba3cc95124a5b77bb72ccbd1ab
74cf5cec04743a1f5485af122322c683248943e1
2009 F20101123_AAABXK manian_v_Page_042.txt
6ed335dcf005241c077d5831a6c90a78
0b272b122ce86c52d768a3ea9cce626f44462d06
357 F20101123_AAABWW manian_v_Page_026.txt
f6e532440e87bb5cda5c047968185f65
fd90a29efb63406e1752a578a20da0856243b04b
29344 F20101123_AAACDF manian_v_Page_058.QC.jpg
a0071c3a0eb3cea0666844d9c40e51d9
552e7c46522365dcd4d3dbf022b357e701e7ef1d
7004 F20101123_AAACCQ manian_v_Page_051thm.jpg
3f6f42c186d569d897a4ca70dc3097ad
f532bdc5f801a4e9fc02c239237724b864cea0ad
1790 F20101123_AAABXL manian_v_Page_043.txt
02e10c4dfdb4a6830e4a612919f027f8
d8cfaa87947b6e7b774613d6dd53d478837c82a8
1874 F20101123_AAABWX manian_v_Page_027.txt
12da0c72d071d77282897e8d8ec7f058
f46b33b70c7fff002ad2de4ea5f5115bf99eac20
28088 F20101123_AAACCR manian_v_Page_051.QC.jpg
b7281b0054b9a08910aba35e6b427cb4
1b4e2cf05726678ed2fcc4ba07facda0b6ce7028
F20101123_AAABXM manian_v_Page_044.txt
e93136805448f64f58a61ed29a71f50e
b8218110173131e0b7bf458410ab97cfab218045
2179 F20101123_AAABWY manian_v_Page_028.txt
9024fd7638ce284932954da61519a3ae
22ff8ac886a524a68b7da9f78d413a36c96b4795
5293 F20101123_AAACDG manian_v_Page_059thm.jpg
f30712061d5f4606c97160ae03f85322
73151b328f76d2b519a37de61ff8c36186ff5d29
1757 F20101123_AAABYA manian_v_Page_061.txt
92eccf452a5db447bcf332bbb2110c24
8de08cd6a34f1e242f37e8249b895098e02c0972
7455 F20101123_AAACCS manian_v_Page_052thm.jpg
7bb9b56dcf34a154d8cf5f853f61b375
44f83d5e679a3913b4ce6024809016d310633fb0
1614 F20101123_AAABXN manian_v_Page_045.txt
1e9d5047248a26476f4f9e13117bb1df
08b0dd95ae72849af43dae2ee94ca74c9e13f499
1689 F20101123_AAABWZ manian_v_Page_029.txt
52358b2feb7fa1baea55398c14bde217
f48d9fe761ad28866a90cb6c5f4013f4a90e3fd6
22053 F20101123_AAACDH manian_v_Page_059.QC.jpg
1e88cf918da309e41530d881e5fd0964
2e4bf1e30d81fa1f7b42f831535a4c74e58cdf72
1397 F20101123_AAABYB manian_v_Page_062.txt
fecebeabfee6767829bdd70d736a75f3
8cf3b73c6fb51987ce9e2e48a43330b353beaeec
31369 F20101123_AAACCT manian_v_Page_052.QC.jpg
f2dad440e9aa5472fe033a99f9deaded
f8c0bab5e984a1291491aedf47041fd21864672d
2107 F20101123_AAABXO manian_v_Page_046.txt
273f57b51add5bb53f6acd8922505440
991ea24e80daa5d552359416e26db476951b0026
17178 F20101123_AAACDI manian_v_Page_060.QC.jpg
ea36c69a2f38ee8ff1be98df6aca2aba
ba59b9aecd5fceb44cd65382ff5219e8997cb706
1407 F20101123_AAABYC manian_v_Page_063.txt
12fa6659a50283a97235a8ba6c2df0e9
9647b7d75e5570dd3761f89af40f405eb42354af
6552 F20101123_AAACCU manian_v_Page_053thm.jpg
4c62fe9b8cc458155eeaef1a4896ad47
c1ffdaada0d68e3a56d2bd87c63906a18f4d3f07
1791 F20101123_AAABXP manian_v_Page_049.txt
d20fec6ea37040fea3855806eec41ec6
f41f0b39048b2570fb7626eee006cb59ab402a54
6109 F20101123_AAACDJ manian_v_Page_061thm.jpg
cbf4861dcc350a2176c07ab085efba27
3f1256cc99ac1f664bfd9c1ee4303225066790e4
2092 F20101123_AAABYD manian_v_Page_064.txt
8dfd3d5ce9ba3cd3bbfa4a1e6bcc835c
51b06a044565aeadfea7877cf9ff4611683e2b96
27331 F20101123_AAACCV manian_v_Page_053.QC.jpg
32fd0a3ce058791d49970e04d1d25d80
1e6f3b93895a656e33f0aaf5a596c0cea38b75c8
1460 F20101123_AAABXQ manian_v_Page_050.txt
eca8f10ace5ecd9a80684b04e73f9a6b
c27ec105376f714fb7f0ec80e7d9276d04cca002
4985 F20101123_AAACDK manian_v_Page_062thm.jpg
76f97b75db95dd9f64929652e101f48c
3e6643030cd56f94fe918487e22c3f7f4e8a4273
1796 F20101123_AAABYE manian_v_Page_065.txt
bce0be4ad7c2882c5db1fe4311ecf840
b7f850fd2f980e06ca83bf412c68690b35f846d4
6718 F20101123_AAACCW manian_v_Page_054thm.jpg
82fc988abab71885c29e105b261a21bc
5387853273e306b28b35e850687ecb3cf9d2a266
1835 F20101123_AAABXR manian_v_Page_051.txt
20c664756da715789e8c703f5f11d538
7e8b1ffa761c4fa028c355640de33a1e67fe4d63
27677 F20101123_AAACEA manian_v_Page_071.QC.jpg
a0b4809445c3ac55158b305527513efa
67d02a4666ba9fa476bcb8200f85bc49056fb588
19146 F20101123_AAACDL manian_v_Page_062.QC.jpg
fe03125c7248b030924207b616fbb372
e7505d1129c9999abbb23d90b773fed9dac7972e
F20101123_AAABYF manian_v_Page_066.txt
e378a414dddc8806840d168d27f16902
31896dda6295a2fc7ecc01f14e3511bd521a9f76
28246 F20101123_AAACCX manian_v_Page_054.QC.jpg
c7bea35cdee7094bcd62dde6ab570551
eae14799b133f17add42fdcbb373bb34b1a57e17
2132 F20101123_AAABXS manian_v_Page_052.txt
13b2cbc3ad58ab8934b380c3fedcd77a
2447a034d52982819c63e51dee6ec9edd423d3c7
6421 F20101123_AAACEB manian_v_Page_072thm.jpg
737bf4a2203f89cf2de1ebfe90bf7a62
b8a54a8fa968665de66ef0b64ee850a1db439030
5680 F20101123_AAACDM manian_v_Page_063thm.jpg
765eb14432a7939d4987e957e61be29d
103105c4cb643a1d2b7d81ad142689a39f103667
1684 F20101123_AAABYG manian_v_Page_068.txt
3bb9b775c560a95044de77aba7d1a87a
f326e4722878716c05acb650a26ec80cf940eabd
7575 F20101123_AAACCY manian_v_Page_055thm.jpg
9d771e4f51cf40e0f9f81d6ea3a22e7d
cdfad80f20e892feaa3a9661cccf9643f556fabf
1727 F20101123_AAABXT manian_v_Page_053.txt
20ebfec1fbda0d0e76ec4d1b15c8825c
3affab81d1d5f62ae51964a981af939149496d77
24511 F20101123_AAACEC manian_v_Page_072.QC.jpg
49137bf1e3a7039c917ba88f81a7b7ac
ce49ce179f7e37e03f4a6ae331129cd192cbc634
20750 F20101123_AAACDN manian_v_Page_063.QC.jpg
18c626fe66d4765d0996a683ca026973
a5c2e2ad3f80f628aae8afcacc25f1808b8e7aa7
1877 F20101123_AAABYH manian_v_Page_069.txt
d4a8cf107ec9c845a6ee3381d4518b22
c04ade572de72c3a942803eab61ee7610418f090
31609 F20101123_AAACCZ manian_v_Page_055.QC.jpg
dee682e26c6f3d4356aeb3ad9f06e26b
908186ff1922ba4ee16649a6a1ce663ae764e8a3
1897 F20101123_AAABXU manian_v_Page_054.txt
22a0a3e97576fc2d157c344af6d12e7b
3053b57c59f2231adb6c6370b806df4bbddf54a9
7036 F20101123_AAACED manian_v_Page_073thm.jpg
bd84fdba2c88e58d5a3e17bb76126f6e
0b9cb4d1907114ff9d24d9b5bcf249a8353a504f
7118 F20101123_AAACDO manian_v_Page_064thm.jpg
f6fc2523e034eb5f46dacebf39f734e2
1c4a8a42537ed65314f61ad540d857c657eee053
1752 F20101123_AAABYI manian_v_Page_070.txt
d5e4559172b638edb50dcb44f3ebca23
db167d86a26c3f74cfe171cb06a2493fcaa1dab3
2046 F20101123_AAABXV manian_v_Page_056.txt
4f8915100b8137679ab5ee02a398ced3
d4b7d564acf9a608dfd49c19f979aa058e4dd4aa
28287 F20101123_AAACEE manian_v_Page_073.QC.jpg
b57956b969305953d27d85091ef5ae48
92f9bdc385be95eab798b6d56fc34ebc7667d7d2
29437 F20101123_AAACDP manian_v_Page_064.QC.jpg
3a6c3ca643be3d4077f74e69077a06ee
98a6d056c3391d6dc7fb7af338e19229a79ded0c
1852 F20101123_AAABYJ manian_v_Page_071.txt
f4b23ed131790bf29d2562b83d66eb09
6c8053b6fb67d0f0f5d11425659dd25e4801d467
2084 F20101123_AAABXW manian_v_Page_057.txt
582b68186f95ca28471cacc40ef780aa
b0d36aed39af5a8bf76ba06440fef410b9bd3862
4463 F20101123_AAACEF manian_v_Page_074thm.jpg
1b0b04f65d4965e1733f553b11a0eb4c
3044b83ca17d99ebea98e58498d281fbe27018ec
6550 F20101123_AAACDQ manian_v_Page_065thm.jpg
bbfa411a0c27bd036bef1be2e65f3c83
b0f8a9fb8b725ef78c8831f1d7cd1661af3b8cf9
1563 F20101123_AAABYK manian_v_Page_072.txt
5e45e7db3618b24b075250e11e44c1d1
723bdf2000d18e0b0f1b8b11e70986b2782fb5f4
1910 F20101123_AAABXX manian_v_Page_058.txt
2a504a22334313d87ac5d48747f72256
83e75a8bc07bdf52c670b78784b7d8ee4daec97a
15326 F20101123_AAACEG manian_v_Page_074.QC.jpg
2bf7ce6a61d32c9def2a6be0f2212fa8
1a94ea21a80f89f5f40baebdbc687f7503511b2d
24234 F20101123_AAACDR manian_v_Page_065.QC.jpg
12a029bd37c3fd51a966707726c70579
0e2f3dffb7555786fe363797e949195ab1250983
1827 F20101123_AAABYL manian_v_Page_073.txt
f4abf27ae744ea2ed07b41e500c6db1c
c543f15b1cf58d3bd7e5df9628b0fd07c62700e9
1396 F20101123_AAABXY manian_v_Page_059.txt
3d49f4c63188fa5c5604d4e0949af6b5
b860c45393eacfa08a2fbc05e73afd21233360ca
1706 F20101123_AAABZA manian_v_Page_090.txt
5cb20b1a3f28e7e965f8c1b95ab4c494
342fb4f5a9440dbc245a7116eaf619706caf2b4e
6599 F20101123_AAACDS manian_v_Page_066thm.jpg
86d8ca30b9c847a7932d4a27c439e377
18245c4ed6fed3a35a5468bf7bad1fa49fe9ef0d
1218 F20101123_AAABYM manian_v_Page_074.txt
fb51d8e6fe24b3c73de72a5bd150d580
80be02d2827bf89c216bd8db92e50a93e27a3e63
1686 F20101123_AAABXZ manian_v_Page_060.txt
522fe9200ba2a6f5be40cdb2d7a1daa7
ee2be6f69b8709e4a613168670eaec35fcac977b
6022 F20101123_AAACEH manian_v_Page_075thm.jpg
0cc8ac488ddc9ca6b264b83e513b1e3b
872d6d6249eb0a367e4bd9848f5d3f7c1f11474a
1372 F20101123_AAABZB manian_v_Page_091.txt
cfd206e5526f158f93797f7774e861ac
9b32d58bd36afa06ac606fa0170fdf8f22a06704
25528 F20101123_AAACDT manian_v_Page_066.QC.jpg
76a40333ce42f4bc63a741f53ed4150d
5ec4d03ba8e8b46d6778ed04b203811b8b672ce8
1513 F20101123_AAABYN manian_v_Page_075.txt
13a665d3a0c6e40429abdadbd8c8d33f
a4a223aafe025b4fe2dd9abe87b28ea152c36dd8
21752 F20101123_AAACEI manian_v_Page_075.QC.jpg
69dfebe9e046caa82cbb1e90caac84c4
950324dfd1abe16b46b4d41d5cff916bbb49ee4e
2013 F20101123_AAABZC manian_v_Page_092.txt
c8b20a810fab386fe3fe84a906cb8260
b65a4b9d958b017de6b1a7381ed07db683e8f69e
6515 F20101123_AAACDU manian_v_Page_067thm.jpg
35e16db2c86f47a734a02c0e4835bbaa
01e27b9e3b3678360a4f8fa702980391a0e2526d
1828 F20101123_AAABYO manian_v_Page_076.txt
1bc3a3788abfb743dc593e82e7491d37
55f52130c49843b3c52a5f465f4d180c4b01ba23
6551 F20101123_AAACEJ manian_v_Page_076thm.jpg
ae944e066185dd6b7978365cf999e3c6
935f371a19ac24836af89486b9110c92a298948a
1800 F20101123_AAABZD manian_v_Page_094.txt
866e44bf62a8aabcba1219259ba8fcdf
41616cc218e3639e2ffd2350c9ecac5b5e25c26d
24744 F20101123_AAACDV manian_v_Page_067.QC.jpg
8da82512f66fdd789870ff667fb36678
a9ce756da8dcca00fb14f0dbece107a1e288058f
1715 F20101123_AAABYP manian_v_Page_077.txt
8b4ce9cdb61f002c5b4d416d1e3a2d25
da63dc7afe8bcb3d3c5bab2a78b2ed027766f3c0
26576 F20101123_AAACEK manian_v_Page_076.QC.jpg
b34f1abac6bdfdc672f38a915f850683
be31033baeabeb37fffc66e4e1c4e13fdedc1f0c
1950 F20101123_AAABZE manian_v_Page_096.txt
e67a2e4f366619c6e734b73dfe5a7e47
8e44ce5ffbefebd919fe1057474ec02b818e24a7
6840 F20101123_AAACDW manian_v_Page_069thm.jpg
a90d493df983f365e5fb2753ff8d009b
9f2f3b77634bdca1e3b246f1be47430541b08225
1490 F20101123_AAABYQ manian_v_Page_079.txt
b27795cec5a044b38f649a699905f5d1
6e5721d8f67f106f644ffbe163a1e0ef36d631c1
6587 F20101123_AAACEL manian_v_Page_077thm.jpg
8a19c730ab94f48b437548ef2391b4a9
368fa2df034a8c8b7944906918d31b246adf8619
1780 F20101123_AAABZF manian_v_Page_097.txt
a2e4337deb0f3922eeab01bcf0afe4fe
586c66083cb8e33c34276e1ac8bdec12462d1c55
28533 F20101123_AAACDX manian_v_Page_069.QC.jpg
733d425377dda52b9000e7eedf75467d
b5b46dc96fb8913c7c7c71152d13f2b1a9b23eac
2014 F20101123_AAABYR manian_v_Page_080.txt
357823f23aabd365ae7237ed1cfc9205
bb6979869fc4a5cdcc8411a67440fc7c1d670e3d
26028 F20101123_AAACFA manian_v_Page_085.QC.jpg
44090607438fafb9c5a1ba6256bc4f22
6ca7bf30cdca0d8c775ad5b5471212cb18878e6b
26206 F20101123_AAACEM manian_v_Page_077.QC.jpg
99e1ffcaf6dc7be81128576709132c4d
d3409bb4da94e7d4cb874da3ccb49b7c4bb23c46
2033 F20101123_AAABZG manian_v_Page_098.txt
3ab5a2a4da9833cd4c550078a3334bf8
dd00928c1a3be4b047e81bd57fb6495fb88efe50
6638 F20101123_AAACDY manian_v_Page_070thm.jpg
09a8bc8c50a8278f9ab0b17790cac5cb
0bd754f549da760e2840171374019decb0762694
1772 F20101123_AAABYS manian_v_Page_081.txt
64c8b3fae4217209bc6715e8f786e740
f59f53606ce20f3952335f3101700c2b9674087c
5495 F20101123_AAACFB manian_v_Page_086thm.jpg
fdfbc38e4303646b03dccb1302be0b6c
dadafd0a06e6949a63ffcf3850f7639e98a9cec3
5218 F20101123_AAACEN manian_v_Page_078thm.jpg
592d6b305c513b2822929e44f5367246
f952addf81d0987640d35837c40823134bd1695c
341 F20101123_AAABZH manian_v_Page_099.txt
192aad7382b58e0d5a8cd29f1c7e45b4
a5a0417c5004fe23fd7d865a66775ffeb423962f
26049 F20101123_AAACDZ manian_v_Page_070.QC.jpg
1da60fefb8aa44968a5128043d9cadca
1aa021cf335da447036d25d1c0c5c9789657bb92
F20101123_AAABYT manian_v_Page_082.txt
d0b53b721535a672ea830d4353d262b7
0a265e8cfca940494d7c04ce15df40d4346c7c8c
20003 F20101123_AAACFC manian_v_Page_086.QC.jpg
b7a0a585d79a63c917145acd71f6da70
f49bd5651951e897c9769e0742d0602c12deb63f
22037 F20101123_AAACEO manian_v_Page_078.QC.jpg
786828d098c667d513cbf46a46d855af
ea732aab45124ad5cdfe53757e4cd1cc3637cdd8
2027 F20101123_AAABZI manian_v_Page_100.txt
3196ff945ecab3383ec35bde0db2aed6
fd66a7c7f53ee34bdca4318ee8eb501347269406
1503 F20101123_AAABYU manian_v_Page_083.txt
35e44b5170ba472a742b1f01d68f76be
8a6a202aee0a89d58d6609194d7b54c6850dfb75
20964 F20101123_AAACFD manian_v_Page_087.QC.jpg
aa93e1ab8db6e3e6d6c2d17fbadb3fd7
acacf83adba3facce26f85ebbf8aaa4939731124
21562 F20101123_AAACEP manian_v_Page_079.QC.jpg
f1a4b168c1cb76dc4023a962bcd20189
39ffbd0bd7a0ce1cc0355703dcb44f717d7eca09
2332 F20101123_AAABZJ manian_v_Page_101.txt
54b3abf5413d98e7ab1c2d3275c899b4
30ca5c14f6cc7a99b14c42a030854d7dc920bf5e
1580 F20101123_AAABYV manian_v_Page_084.txt
d10633917eae01f81604f42e698e2522
55c58dcfc471190024344b83264d336b30c014c5
18857 F20101123_AAACFE manian_v_Page_088.QC.jpg
ff46b419ff8b18fbeb903aba63fb988a
ac0171ece5454bba84fed80090307d828ee7a470
29753 F20101123_AAACEQ manian_v_Page_080.QC.jpg
0cd02ab8fa2641e81265735ecf530e26
9c5c86f9b92f57c798f7067e16eb00ff59473526
2257 F20101123_AAABZK manian_v_Page_102.txt
436d7e5812284f20c97779785f87f053
b11b6ada6af74bc8d886e642c428a216b4e7a937
1763 F20101123_AAABYW manian_v_Page_085.txt
7bc5f7aac13625f5dd9fc6f80c3e11f0
af7bbd3c14a24c91f88c088e1c49587d0d869cf6
5522 F20101123_AAACFF manian_v_Page_089thm.jpg
e9723df20dad109b7adc784ee963d33b
13da886363dfcf23eb042b2f89550813d9909e16
6565 F20101123_AAACER manian_v_Page_081thm.jpg
62b49bfeaaae7f2002d3c3a69582f397
f900ada4543d71624d1342e790d8d85acba80ae6
2419 F20101123_AAABZL manian_v_Page_103.txt
c77eebc1d38ad6d9aaf1afb7037d054e
562323313af183f4c42aa1640182ede6501c709e
1344 F20101123_AAABYX manian_v_Page_086.txt
db57c29276656b388652b6411e86b3bb
bf4c834244d1a239012ade1e3b6b1cfed692fe68
21632 F20101123_AAACFG manian_v_Page_089.QC.jpg
45c2bc087720139f1b6cd3b0cffae611
b5847db5ea67ae67bf1d345ce108bbeaeaa38ca0
26979 F20101123_AAACES manian_v_Page_081.QC.jpg
ae68faa2cfe96ed3a4496dd95336006a
c247b5645b0f8706fa8f9ce112a0045552a6059d
922 F20101123_AAABZM manian_v_Page_105.txt
6fbef74995c1fe18693afcb49fbf1659
d538ab4ce56d77a266d6bfa4000797a08fe3e71c
1373 F20101123_AAABYY manian_v_Page_087.txt
2c0699a25a44e1ac3822d0b11a4d61ad
dbc70b88875e1ffcf3d3a62eed3dc8a1170bef61
6260 F20101123_AAACFH manian_v_Page_090thm.jpg
cff8d35b52eac9ee3980422988984758
2451435b7283d820daf298386d705d9209a65cb7
6242 F20101123_AAACET manian_v_Page_082thm.jpg
d2a6acaf0fdfd6d3d3f1c8bcc19392e3
8b4f30c3c88fb973f5292d86d461d491de92ebf0
557239 F20101123_AAABZN manian_v.pdf
450c2e651dfb3f5d4452974af40fec70
c92a40dc030f2960e72b7137cc5c8af180d08a1b
1558 F20101123_AAABYZ manian_v_Page_089.txt
09a3e01f22c6e2a0f3e01ebc196942f9
d530930561083c73a5f0398d68bda52260936648
25324 F20101123_AAACEU manian_v_Page_082.QC.jpg
bc59d0f6ad71496cdda4721342fa529e
a4a5f6e5a1c088200e08372ce399a5329320194c
2079 F20101123_AAABZO manian_v_Page_001thm.jpg
e42a24d7de32aba7261401c9e3a530df
a94eda0d19fba561c4518e0b5204290c37e268b5
23751 F20101123_AAACFI manian_v_Page_090.QC.jpg
9500580a2b0170064e611d365c661c8e
1dcf7b1af49afc147102b84e1347bf8760fb7281
5544 F20101123_AAACEV manian_v_Page_083thm.jpg
8ff9c272015aef70454f445967f827d5
736f03ce039a8e617858af7b96e72dda086279e0
639 F20101123_AAABZP manian_v_Page_002thm.jpg
c6551266c38ba004a071e0f6010b1143
b6de028471f5f5f768e0bed29658a10dbdd4f06f
18926 F20101123_AAACFJ manian_v_Page_091.QC.jpg
af6f9fd76c75334d5526e258a7361e94
88b2dcb9be4506f16f18016d8671d49634ec6f77
20991 F20101123_AAACEW manian_v_Page_083.QC.jpg
cc7fab903151a6821ed9a6e0e8a82e08
b8e1a1afeb16b3d4b6e7e6a85c886f1a342b7702
2002 F20101123_AAABZQ manian_v_Page_002.QC.jpg
504b6b398d72622ff32a36d8c0df3004
9bfdbfb07a941ad7fee68cbe9f58b41c54d02279
7063 F20101123_AAACFK manian_v_Page_092thm.jpg
1c20a51a439f5d34d42df97bbab8d8db
23b7cba09c800ed7348dc8bfffeb402c3af1aa33
5074 F20101123_AAACEX manian_v_Page_084thm.jpg
9fdafb9ad16c59a4f2fee933cdc709c3
00e54e7926f51871cad7c172dae9ac101250fcb9
2586 F20101123_AAABZR manian_v_Page_003thm.jpg
3f5e6957638de07f0f054bb7fc415156
2ddc4e1377513a56090a1c9a53a1491553574211
32582 F20101123_AAACGA manian_v_Page_101.QC.jpg
2df07cf669b54ac9985e6ec4e2c275b0
1c6a973a0155e395610807c78262074e42165c3d
30538 F20101123_AAACFL manian_v_Page_092.QC.jpg
1a47b8674a5546c5df8f6d57fc2812ca
8db8776933131d07e08496afa9f92532cd6bfa86
20256 F20101123_AAACEY manian_v_Page_084.QC.jpg
af970f049a37f9d525671bc1fe53e148
a3457c2fa271e285102bedae63e12cdfd39817af
5302 F20101123_AAABZS manian_v_Page_004thm.jpg
773273c1a6eb4a79f4520179150708a4
9b7170d0e9883aa2a2604a9f5d72e2a63c2b8eab
7274 F20101123_AAACGB manian_v_Page_102thm.jpg
b60352e7a7512ca7a0b42e58219c364b
bb9ebdf09c42c6f9b89c7f10ae8060cb11e4c1c2
8797 F20101123_AAACFM manian_v_Page_093.QC.jpg
f77abf24e11b83762334fa347a4ba587
8ef78ffc4008e226877d7f90eaa1ddc138997b3d
6696 F20101123_AAACEZ manian_v_Page_085thm.jpg
d7960dae1d93089a50e4f8f45481b3ec
5c6502f8aefa8fa2131c4904758ce44da1197ae4
25792 F20101123_AAABZT manian_v_Page_004.QC.jpg
f1706df24b7e72d4d2040346d6a4feeb
b4539d3bdcc370075b34adf6b850af20a7061826
30494 F20101123_AAACGC manian_v_Page_102.QC.jpg
957bcd5960bfe3c9bc907cb308243d0d
2043ab58873589f0f996d987cf0af947b58fdd85
25826 F20101123_AAACFN manian_v_Page_094.QC.jpg
bf00e33b06e57fb844a932480646def8
c9855242af1507b43805f8ec8db5eeba1ab84ac4
6439 F20101123_AAABZU manian_v_Page_005thm.jpg
020e54a387a52b43200268769ac0d827
c8f1dd6af7c3fe2d883ab6bf65c4d0a7cb1713e8
7456 F20101123_AAACGD manian_v_Page_103thm.jpg
2043485776f14357618dd95382c546e3
b867c976b9eeaadf2192387de731acc4650a5120
7438 F20101123_AAACFO manian_v_Page_095thm.jpg
90d713c08d7efa6843f6e3255a252b52
8ddead20018ab2b38ac5e96bcc94bfad3783714e
32830 F20101123_AAABZV manian_v_Page_005.QC.jpg
eb10fcc3511560c5c1529a0365902fe1
763cc56b11214661d655274df56be20d767535bf
32150 F20101123_AAACGE manian_v_Page_103.QC.jpg
b271c1d4ee24fa55c96fbc5f982261fa
d9f888f66e9f79d9969aab0af5365f8e63e17b69
32662 F20101123_AAACFP manian_v_Page_095.QC.jpg
9d978e7d190ed256afe33beb182f358e
c078c10ea0f2cf5bd2e64a986da35a45564c2496
2640 F20101123_AAABZW manian_v_Page_006thm.jpg
fee021606be44f282ded65e097e06733
3d459c585100b47ac360cdeed3296496242a39b3
5489 F20101123_AAACGF manian_v_Page_104thm.jpg
586ada9069df0f13abb707b5889d8abe
9f6c4a05a04a748c61a82b30e9a2cdbd330a2602
7205 F20101123_AAACFQ manian_v_Page_096thm.jpg
825d7318f0875dcfd4d4dba1ad45770d
c70f89a76b93529da240bc247e3f24cc57b4d08f
12043 F20101123_AAABZX manian_v_Page_006.QC.jpg
3f6ebafa261b9ed5f27d4c3857afb30d
dd3efed94a8dc8f6ce5d7be52c6d47df5575baaf
23085 F20101123_AAACGG manian_v_Page_104.QC.jpg
153502d38460bf3581e45def2b366da1
4ff207a8cd8af4c65e2a849e0df6a77a450c4e72
28882 F20101123_AAACFR manian_v_Page_096.QC.jpg
5647fa631d1694cc903f37bd4ceecf48
84975d3b8ec770b5b55740d174e1433992334b28
8300 F20101123_AAABZY manian_v_Page_007.QC.jpg
57d8227b6cde2ab0f852de91a7136276
f3ae861b8ed775b416479042abbe23ad092508b8
3470 F20101123_AAACGH manian_v_Page_105thm.jpg
2cd74a8443b005594c15f5062445ef91
77b58811454e4b549c6270d22c15c9918b70ae33
6555 F20101123_AAACFS manian_v_Page_097thm.jpg
23d664fb654961e2a5f704b36ef4b4cc
ed382c27ea7531c2e363783ccca0c0b2d654f62b
1737 F20101123_AAABZZ manian_v_Page_008thm.jpg
0ed16c661b9e98720f8398409cc32e16
473bbcfcc295daf875e2d4485f6fad245d64735e
14956 F20101123_AAACGI manian_v_Page_105.QC.jpg
7da4498a758791870fba8ad32035b606
431a27b8a782b77ff8516f015121a19ddcbd05a8
27306 F20101123_AAACFT manian_v_Page_097.QC.jpg
0bb0c79fd87e781f8ea56c70dccd7f5e
5d808509bfac55299d607245fa384a1b61b7a580
6687 F20101123_AAACFU manian_v_Page_098thm.jpg
435af5b68e5ea6648e4d92393ff0fb9d
f59efb7f49c39f7561b34d7150d31f070a034a82
121896 F20101123_AAACGJ UFE0011941_00001.mets FULL
5e1936703506d51f9419ffc140187566
71f1c2800692d8fb1d9d16878f0dbb978ae60a4c
30181 F20101123_AAACFV manian_v_Page_098.QC.jpg
a125dd4d427992ade599fe0145314051
6f94a9752df103641892fa66318be4a69204d5a8
4628 F20101123_AAACFW manian_v_Page_099.QC.jpg
8aab8929342afa08081d922b531f8ba6
8ca5bc976fdfa56f2172892027480fcfa3d8c5f8
6799 F20101123_AAACFX manian_v_Page_100thm.jpg
50469d4c9ebaaf3c4c0b4fe1aef8f42e
0cfdcb0dc6c64792815136f75c33038514e3c8b5
26931 F20101123_AAACFY manian_v_Page_100.QC.jpg
a144613664893376daa5203b2b49315e
0ac2b5330150a0529b285df71d2c06470e798486
93703 F20101123_AAABEA manian_v_Page_081.jp2
1c3ac20dc30eb876f151ab89318f4796
675ed20f2807471d3b547c315d2994c28b3b3cd9
7793 F20101123_AAACFZ manian_v_Page_101thm.jpg
5acf7391a4af6018c3de71664eea7de7
4a6812efab7b888bd4c33e8d3075b27c2ae85e1c
88253 F20101123_AAABEB manian_v_Page_017.jp2
ee9ce40d2d14ac8f4a37600117c623a4
1ad6a60c856bc1a1ab33b2a28259bdb3194c8040
25271604 F20101123_AAABEC manian_v_Page_005.tif
21393c773108376a509b5dd5c274cf3f
e27e36f8a818771697efa2ecc57604acc140b797
1053954 F20101123_AAABED manian_v_Page_087.tif
377d0e85331b1357fa5d7d25580590b8
6b85e91a0bb7f7037f44f73a0506d0d58ca31824
96792 F20101123_AAABEE manian_v_Page_025.jpg
5261551d09aca55b0b8fc15367fdf1e1
8255f8e45752b1c9806d6887ccd0de8eeb9d357e
111404 F20101123_AAABEF manian_v_Page_040.jp2
59e7f9336422ac2486f0081d9242fd2a
2370ca4c8e4c46cfca2fe2a180fa075ca5720416
7224 F20101123_AAABEG manian_v_Page_025thm.jpg
bbd8ac228b7d34cf1e707e29ffa2e531
9bdee26d8be9bc6234f1c50670dc3cd6ba47d94f
F20101123_AAABEH manian_v_Page_007.tif
696e92b699fd65b0681431f444306bd6
b5e70bccc44e57f70d4ab87897d6b54e1d8ec4c1
43201 F20101123_AAABEI manian_v_Page_061.pro
3d5cbe731f43de3a5db4331c5c84c889
79757edc1f26dd5c2ea0e1e1ebf004e00d3deb4d
5170 F20101123_AAABEJ manian_v_Page_079thm.jpg
938ac29788688114027cadbad2298a9a
9096cef20b0aa49c05a1fa95f9c16016f4a8a3a5
1734 F20101123_AAABEK manian_v_Page_017.txt
8af98eb20c37733fb766f4a29aeed512
e03289c93c9c9cdd8a18c1a2831a22cae4d9ee7c
108226 F20101123_AAABFA manian_v_Page_022.jp2
23fa1adf3ce8845691d4aa481da6f126
f9f8b7b2db4fbf8ec201530cb14b3ded872dbc0f
4897 F20101123_AAABEL manian_v_Page_088thm.jpg
cab33b3463238239ac4d9bac8b339487
accbf272a90dcb9884e9280df1a59c39258db865
F20101123_AAABDY manian_v_Page_052.tif
a1e350f5ad2ba8295162c487423cd76c
e35ad0aa4efdeea06e7806a45755ea8788caafa4
7290 F20101123_AAABFB manian_v_Page_080thm.jpg
170cd7a27eb967fa8995a995d1f42555
b96986a50a75725f61aac13a8bae9777421138b9
2225 F20101123_AAABEM manian_v_Page_007thm.jpg
b8391df1c89eaf8786f0a698ee2cd8ca
8b4307392fb3b2fe99b487a3645087687916b03a
1971 F20101123_AAABDZ manian_v_Page_025.txt
a942f08b76b23226bd3d7de21be4633d
c48a0fe65cefe20587965ee3a13961a76fb740d8
6076 F20101123_AAABFC manian_v_Page_094thm.jpg
d983305ebdbda9d688488b658c0c7c34
a3476dd66dda4e350b8665ea1d6a69d9b5d658f8
113428 F20101123_AAABEN manian_v_Page_044.jp2
5ea42193060f3d33a97e1e42eee9c280
172d70c37a7bd37dcd51d422d96108c3f5afe99e
F20101123_AAABFD manian_v_Page_032thm.jpg
28b7b0ea7ca0b11fdf096508d35cc468
71bbbf24b8411a80b6f5d9df550ce4bd785d7a17
F20101123_AAABEO manian_v_Page_044.tif
a0c92e0d01625f218b8c72d514423ee5
63ddd5fd74e1e82cfa0a3bfe420d5999ad124ca4
41404 F20101123_AAABFE manian_v_Page_104.pro
e5c848439593d0b79f2f03bc4cc63e85
7eea97d2a14a5c3d4d957f302dd4cd1ff25e436c
108725 F20101123_AAABEP manian_v_Page_036.jp2
00c7ee282a5e5a5d3c41da019d22a10c
77015a762da742ed1690e25067a294edd77f1bc2
F20101123_AAABFF manian_v_Page_029.tif
cd791d7ea87f9ca96c617dfb8c5a6b1f
ac74a2fcf98c6dcfb7e7e5686d29c75b198dcde1
F20101123_AAABEQ manian_v_Page_065.tif
d04d7e8d16eb4b5bedc2f82484a41550
e108506ba94604e0ee3b5648abcab6c972e6c87b
F20101123_AAABFG manian_v_Page_010.tif
71b652e1db000f4658fe995e50d58d2c
2f828399ab4b6b3f5ffbc32f9d9bee938bd06f1a
5030 F20101123_AAABER manian_v_Page_091thm.jpg
bc1ef2e337bbab645ff679b3d8255e08
6093418eef664c79e29de74bff05be2962f0bebc
61041 F20101123_AAABFH manian_v_Page_062.jpg
d21f0853af9784bcf76f76bad0b8b714
7c70e2a7ac4bbe0fda0427a209fb7dfa4e95da8c
50263 F20101123_AAABES manian_v_Page_080.pro
b08985e1833a024c755219567964aa36
780fa3b0f628a2750d7bea67d1c009f271e9070c
6020 F20101123_AAABFI manian_v_Page_043thm.jpg
21b52af42a6b2e8c603da9f268e76322
ef33e93788f801ccc0b2941c0e2ed0ded3bee52c
7197 F20101123_AAABET manian_v_Page_001.QC.jpg
5febf5d12fae64017e4b51c6e2de4276
e98686b768ab7a2aaa21fcaa48de5c9194255b92
1302 F20101123_AAABEU manian_v_Page_088.txt
65868c0e54cde73935fea0e9a6d0e14a
cebad92f3fef81565a8e534fc211347950168c96
10693 F20101123_AAABFJ manian_v_Page_003.QC.jpg
94cec54071d996f82ed168823a7633cd
174b3733bbd612928a2d67f6f609a3fb8b0e5e94
40271 F20101123_AAABEV manian_v_Page_016.jpg
6ed5bd84a2f848b1ab61719740d54adf
68b4686da66af0b970baaeb1017d46d9ffc88a39
F20101123_AAABFK manian_v_Page_055.tif
6c0add677271d51bbfa626c5938182ef
09b8b7465c75481d85410b260395e8d890024007
F20101123_AAABEW manian_v_Page_026.tif
ba81783ffe1560fe00f3d382c1a9bce4
1df012aa8a54bf12540c2feabb1f2dd7f2f40d90
F20101123_AAABGA manian_v_Page_040.tif
34aafa26bc54b05e8421397716de7542
687ed7b7843c4973d260beb49cfa3ccede092b44
99451 F20101123_AAABFL manian_v_Page_056.jpg
bd86dd19ef10f973acc42b7d2ae316c0
a6ec49821cadbd727afb3fb94354144bbb35090e
6544 F20101123_AAABEX manian_v_Page_020thm.jpg
7237f34d14f25fc0485de8fc9d35dace
c931d56d3284a411647c6ae60d07266a324aa41c
34566 F20101123_AAABGB manian_v_Page_078.pro
29528555c00dc280e7c5a1935531904c
a653044f4a57ff6d34bc166a1b1778b991c7b119
7609 F20101123_AAABFM manian_v_Page_039thm.jpg
ba4436cadef5e9a16caeb9fe8f235019
7c8f3ca876c26f72e6b073067a95968cfb6727df
2259 F20101123_AAABEY manian_v_Page_055.txt
1e415965203e43494f9cbf8682bcfe56
21634ccea67baba33fed104b425ce20ac4072ac5
30965 F20101123_AAABGC manian_v_Page_040.QC.jpg
6d70c1ec8cb7075fbcc7f4eb133db0e0
d8a2c2e279a23557fa6a618467b89231a921ac4f
48872 F20101123_AAABFN manian_v_Page_024.pro
65e0a6382cd06c19da270456eb121b2f
e3f1536862c612e54a265adb0b9b4c9c7a566438
6546 F20101123_AAABEZ manian_v_Page_024thm.jpg
e4ce41c64f913a986d10de4e85ea8622
2fbb3fa19b39c375ac7ef729f1e27fcc326a90dd
7046 F20101123_AAABGD manian_v_Page_018thm.jpg
71296c7c65bd002d20671c55f2ad59f8
667d7c47189c689fda23c1b4e3e3b0fa386b4857
1304 F20101123_AAABFO manian_v_Page_047.txt
100ed99f1418c762ffefd14c328778dd
b004167a0177685e20804d9e42c17f7df236de90
38633 F20101123_AAABGE manian_v_Page_045.pro
22ebe3df053f783cf0cf0782bbacef38
88e5c937da3c1f2b4114183bc1614993831798c5
32208 F20101123_AAABFP manian_v_Page_044.QC.jpg
70bd44a7fdf94252d8c40a5ff28838f0
c250dfbfa2540ae3c13bf7d456b940706522c547
42917 F20101123_AAABGF manian_v_Page_082.pro
e33613da664186471b5978eae0547846
b42c30b917ddcca27f165f9e00002ff7b840502e
5506 F20101123_AAABFQ manian_v_Page_008.QC.jpg
92383fafd18a997b6a7d6f539c8794f7
556b319da99ab3afd1a76c6452cd96261745f5a1
58619 F20101123_AAABGG manian_v_Page_019.pro
5bfb03bbd09895a96c00bda6e03dcddb
8f1039710b278b668ac3f67badd39d6dc6fb1fc2
6713 F20101123_AAABFR manian_v_Page_049thm.jpg
035fd60bc8554a9b21fa856f27df2c30
007ce627497c973ef7d02416f0775c8df5c190dc
F20101123_AAABGH manian_v_Page_068thm.jpg
bff2962e02dd378c9505f97af7a74060
f883a692970a90a4c958f85d0e45a1beb09c7677
41615 F20101123_AAABFS manian_v_Page_085.pro
949e4f9e2f1b4adb5115a23e5fa29830
af31d015b55af0a117a0b194da600b97b26dca1e
46788 F20101123_AAABGI manian_v_Page_011.pro
bb675a64afd52859ff146bca1c945196
2df58e9b2ba07f0483adaf40970cbf828d9288e7
80436 F20101123_AAABFT manian_v_Page_065.jpg
22ecc0473e2d23f6f0c241ea48a7b158
e626acb5ed5741209885bc37d9bd781370adf121
2206 F20101123_AAABGJ manian_v_Page_095.txt
02a95d14e88a732c612bb198b46ecc23
242aedf168f0f1d677a346515de059dd396aae45
1528 F20101123_AAABFU manian_v_Page_031.txt
942f894f319163ee5eae98b19869845b
4f65a03343ab9fa5a134518b25da2658979e4b50
30853 F20101123_AAABFV manian_v_Page_042.QC.jpg
40cb33ecb552a8e509fe86788687ef5a
8533ae0ab24e1ea970ff8354916490f4c8f6ccb2
6866 F20101123_AAABGK manian_v_Page_071thm.jpg
f25bdb370cd87c3297f70ce32a41536a
d9cb890c92c929fc7b6209171d353a9998f182a7
F20101123_AAABFW manian_v_Page_035.tif
6e03e8eb8dce2d7c567df2b2467e3a70
1576e262dab3cd7eddb95024bf46edcce6667bd6
1305 F20101123_AAABGL manian_v_Page_099thm.jpg
b674791c08fa5c104a35f8aa8379ebb6
2ac584df78dc235c31398d280ad13c3b6fc414fa
95247 F20101123_AAABFX manian_v_Page_058.jpg
1e6f262d4b1f6a8555dd79511d169aa6
9b5b9454c1fc7329e034bfe715f4ff595c4cdaff
1998 F20101123_AAABHA manian_v_Page_035.txt
960044455df33c4473bfc4bd35fd5d3c
361c0ecc57cf64001f0503339f4b86f2f80ecc05
115811 F20101123_AAABGM manian_v_Page_028.jp2
406e59c6802490c75f9ec623bda40fea
5cf80fa2c0f74676e10b2a9d412e92f212b49957
67599 F20101123_AAABFY manian_v_Page_084.jp2
891917cbcb51b45abf5ba974aade0898
f5a08d4b1903d2c13ae8f9f2b2838aabdfbc7a63
50715 F20101123_AAABHB manian_v_Page_022.pro
bc1a26d810a8f9200e18546aca5dcf0f
239366faa4ebd253d1f916444b3b6cfcaf2c66ac
38520 F20101123_AAABGN manian_v_Page_072.pro
7af08913197ca6d41dfd7e1f6cad20ec
01819320d36954317fe7a86b9042cb656d77bff1
1203 F20101123_AAABFZ manian_v_Page_048.txt
0c4a30db8a8f4c4199eebf0cc6bcd711
a8bfa9bff543b22f464a78f9da9ea870d3c6a3a5
4049 F20101123_AAABHC manian_v_Page_060thm.jpg
2d8cd849178edc9122ad915a6b6b93fd
428f62b678156e6020e40e164bc2bbd36dc540d0
63160 F20101123_AAABGO manian_v_Page_047.jp2
2e1e8312a6619479693afd558bbfbab4
a34d4524495b731afef4dc069a5a004dcfa98bdc
18482 F20101123_AAABHD manian_v_Page_026.jp2
6f09467608827c8e6c4b6894a4fe0340
1f73f9e5ed221cda5930be166bba03bb2f7ee869
1682 F20101123_AAABGP manian_v_Page_104.txt
6de3c770d59eca2fa8b6f255395c959b
4572e512554fb1d34709fc9b2f8329822f166644
63742 F20101123_AAABHE manian_v_Page_063.jpg
7d42be63b8ad5cd890b6f835b9be0b45
0f265fd5a0798155dd27c0b57b6fd827756a8eb3
1637 F20101123_AAABGQ manian_v_Page_067.txt
6d77c1529789dd5710881fa69c24da3b
68ca3661a4ac4ef28688b35167ba68b4949e9183
96883 F20101123_AAABHF manian_v_Page_030.jpg
df4bb6de7daffe73c8c63f0dd763acfa
64ac3812c3917b3963a7ce09a5110de18d6ed930
2248 F20101123_AAABGR manian_v_Page_093thm.jpg
f365d74e91d556b6407e0ca5b5d15ccf
57e9c7cb5b8e68c0091780572126e4cf22044026
50723 F20101123_AAABHG manian_v_Page_034.pro
6a70b7e40e7c8d842bb0792af47f7718
6d14807a06db17c6106ee1a51c3d4d41a748d4c6
583 F20101123_AAABGS manian_v_Page_093.txt
f0341e96bfbd2b3728da2ea1c859d4aa
3a40d56e2a64f2f707fbdb9fe27c9a1b52f7093b
F20101123_AAABHH manian_v_Page_028.tif
d2905f4fbaa845dfa59eccb3140eb449
29afa7e32adebad1337944d4efa28bbd93502235
89186 F20101123_AAABGT manian_v_Page_068.jp2
773dab4e4adb3cde4b8de207782de6d7
981dd1b21a5f0e7e660138debb62cb62a61108ec
61830 F20101123_AAABHI manian_v_Page_084.jpg
090f5e332c676a5bd7b3e7dccb4e8eea
610b1bddac3990b490426841e3e21ac393c232ac
6803 F20101123_AAABGU manian_v_Page_035thm.jpg
b10532dec6a24c98e9565192c29796a8
b348e2cfafc1bdab191fbe5750a7267b157fc8b2
1423 F20101123_AAABHJ manian_v_Page_078.txt
f57fddd00a2b36c6529ebd97fd2935cd
bf49a14ded528eec8d69b0914bf898e906367ab5
5269 F20101123_AAABGV manian_v_Page_087thm.jpg
a2a439d1991cff5a63ac5cc863b72581
57a5d5cac549b31d2d44231a0dc7c5050b42df8a
97031 F20101123_AAABHK manian_v_Page_037.jpg
219cab7b1d4c743fd066ef19eea0ef96
f233ea24ff5a7e708236da9bdd16721fac243fb0
86858 F20101123_AAABGW manian_v_Page_012.jpg
c6b765057e0d7a1b014b7a6f591868d0
25bbec084e8ccdb332ab483b8baf3a7b236acfa2
30232 F20101123_AAABGX manian_v_Page_015.pro
36aca85c490ae415b6c85d3cd2414288
2a99fb0ed0ef222e10ac3140f420c0a295207e66
104626 F20101123_AAABIA manian_v_Page_041.jpg
b2d70c7e3b9774d5d33897257d1131bb
814359a9d121d165af22e969d9c09704e8f06fe5
54796 F20101123_AAABHL manian_v_Page_040.pro
f59168008d03c1dad1eb629a62d37c43
009cc37db12faacb8cc6e64111223c9868d28ad4
F20101123_AAABGY manian_v_Page_008.tif
06d2c3715806887e3f6a6626fef9bb9b
3c893af44313f1171caf89b94d060bfb4fd5d5c8
F20101123_AAABIB manian_v_Page_105.tif
3e354846b54502bea45303ed80464f02
bb7c06d116cde29f7413bbb698c43e62cc80d90a
24473 F20101123_AAABHM manian_v_Page_074.pro
b43acc72a1fe71dd6f18cd1f7f54e447
b4548c03a047909ce2cf02f0fc8ab8ff63a49c9a
7515 F20101123_AAABGZ manian_v_Page_044thm.jpg
8521c15935a2014aab60a38d66baf277
e3e895e7eaa2324162722cfe5885bded635e4753
443 F20101123_AAABIC manian_v_Page_001.txt
f64044cb66197324122d22fc900773a8
f30c03e2c25909fa643d79dc71788a4ab5648133
1054428 F20101123_AAABHN manian_v_Page_047.tif
fe9316dcc3d6207f74644517fa8b0c00
91b5f588592be5356bab05de58f7ef7d3de354b5
157972 F20101123_AAABID UFE0011941_00001.xml
93c6df53e62c1932f13f313926ef91a4
6fb23dcb79ecd89beaec13cbf594175421beef9a
33172 F20101123_AAABHO manian_v_Page_039.QC.jpg
cec65b25ed8a5474103b162f43a94f13
7ca7a49d033e48a7c790e3f73f31724b13a7f8a9
F20101123_AAABHP manian_v_Page_022.txt
f2b8d36674f85ed8d33760bd90d2b345
e6142723a43d5553ce6d7106d03a31e52d2e7dfa
98360 F20101123_AAABHQ manian_v_Page_022.jpg
f77f66493773ae077a21725a1b1a956e
25c0af5dffe08ee9c5ec87dad1f5c6932e96be35
24555 F20101123_AAABIG manian_v_Page_001.jpg
4a82b3ba527e8897831b89c153474955
f6edd0b1a9c988fe22e79e5b4cfa78f75433a263
6299 F20101123_AAABHR manian_v_Page_050thm.jpg
59a823f4adeb5f6b12385857369824a1
48d9cbc52f3cfb4c0fb0d7a0ed616f6e518a006a
5345 F20101123_AAABIH manian_v_Page_002.jpg
6fd688d474ffda7a37bbb88eda985e10
bce13439ea411bb5cdac10a30c0662bc83a0afd4
F20101123_AAABHS manian_v_Page_063.tif
af85bffb5f37b30274261f0383571cef
c9f2d61af4bd93447d2e0f39afd4878bb81dd7e6
32787 F20101123_AAABII manian_v_Page_003.jpg
c8cf05326678a24e858514f7aa091fc0
123c20e06a11f9ad547614556f0e9282f841ea38
66448 F20101123_AAABHT manian_v_Page_062.jp2
0d6349733df9666f185aba827b71dba0
80157d101cc3d286da3a1aa21b03325b6da347d9
93557 F20101123_AAABIJ manian_v_Page_004.jpg
ed32108e0a77394023cff74933ee5edc
a7f28c7151fb57f6edb91f5c3232b94099f1429a
26915 F20101123_AAABHU manian_v_Page_061.QC.jpg
962fa23cba34fb62490432d1bb56178e
dcc283b41547d564bb46f768be1db0f3c8aa21eb
120640 F20101123_AAABIK manian_v_Page_005.jpg
2be0a609ba0d93d89f1e345f397bbed6
d1b9bf9c6c1a440d78e02fa8d01f0136dfd97a20
F20101123_AAABHV manian_v_Page_084.tif
6b5e976d1e30d7391ee0c624d3762d5a
4a2f5e986511760a1626cd824fb305d2d8db6fbd
41767 F20101123_AAABIL manian_v_Page_006.jpg
052962e797cf84520d70ffc4271528e2
715a46f57f034ae7bfc1f0bc3e384c74c05cf554
6984 F20101123_AAABHW manian_v_Page_037thm.jpg
21b78f541d14b83334be45cdadda7948
ab53e24a101414114176013329a5711d7ba8850a
108130 F20101123_AAABHX manian_v_Page_034.jp2
c790a05b2b162e39e0a7988334f97913
4398719ec57e7d68c84853041bfc0d0bce93efa8
94198 F20101123_AAABJA manian_v_Page_024.jpg
fe74d7a2383c0fac730f2ef2f344a69b
69f3b9d635a792aabd8719c73ce68d67ff736276
26787 F20101123_AAABIM manian_v_Page_007.jpg
c90bcf1cf8fd74349585f51547bf3470
ad5966ba0f1766f99c5c291fb6e3e9165732c973
49652 F20101123_AAABHY manian_v_Page_098.pro
1c6acbedeb1fe770cd68f9eb63fc1c2e
a287bbb34a38ebc8b6ffa791e132e3c8dd2bd345
14945 F20101123_AAABJB manian_v_Page_026.jpg
aca9515546542d839f368fde8a802767
f46dbc0acfae296bc7e31a8a3a2898b1cccd47f1
17639 F20101123_AAABIN manian_v_Page_008.jpg
f2eac9a50f903f6f4399edf6a3576aa9
21f7bc27aa61813c100befd63705c19da203fead
24789 F20101123_AAABHZ manian_v_Page_068.QC.jpg
a8e919c64dda413b5d10f33494f8e685
394de774a435980273f8e55efa18dfacc9f348f7
81180 F20101123_AAABJC manian_v_Page_027.jpg
8236dc7d18835c7ef9b968313398561f
ec3a91324edcdf8fd267ebafeb305d2590a6e0a6
90251 F20101123_AAABIO manian_v_Page_009.jpg
44ebffcafa591baa3509f131e6e4e179
41d3fc2bdf1692853ef618c03206223b5867afff
104990 F20101123_AAABJD manian_v_Page_028.jpg
4c7c4fedf275196e6674980490c062ff
15e5b588628ec134e06d5d58e871d91d553cd2db
12019 F20101123_AAABIP manian_v_Page_010.jpg
0cac1441cc57268d5e66b02736c52c8e
a93a33b04cf805aebc7c5e9e47ee62b6b3661749
71889 F20101123_AAABJE manian_v_Page_029.jpg
b42f2fadb2772e5c2833f86f3c7a35f2
a060774e4b0311ff38d837a48dca73dd8dc28bf5
89058 F20101123_AAABIQ manian_v_Page_011.jpg
50c5aaca1cd915bde9af2f95a6dabd99
2715c6a6b6cc6f175e9e33b2631433fe89d3a199
72254 F20101123_AAABJF manian_v_Page_031.jpg
d45a74017c09f4d35a2f0d3614365b49
4a9abaa5157e9c3f92fba2d8fdb98d448b119db1
116170 F20101123_AAABIR manian_v_Page_013.jpg
c1615042fbb8b82f768556303bc0dfad
0375e794422d3f0f9c4e3df63f919a50694c35a7
87780 F20101123_AAABJG manian_v_Page_032.jpg
fabdbf53ddc4e52e943513b88d896689
4c228a5580c43002c81f54d46142a3d16e90be7e
95687 F20101123_AAABIS manian_v_Page_014.jpg
62421bdb484a8b91d67a7b5e3a696859
870e8870c96deeb39d400af7420ef7d270f2e317
94584 F20101123_AAABJH manian_v_Page_033.jpg
afcaf7cc42b9d045de98d696e5345464
f50ead0063e6b5c7249cf11a7e254da46355325f
69918 F20101123_AAABIT manian_v_Page_015.jpg
82d6bad4d6e179355ecfecc7a4d70e52
24a4e7f958842b9a51cd524ea35c154653f4d916
99945 F20101123_AAABJI manian_v_Page_034.jpg
42697a08e1328d0419d6456d28616472
0294486f11f91915be16928428423a9a911d079a
79613 F20101123_AAABIU manian_v_Page_017.jpg
06bb7160f14ae984d58b0da44fd85c7f
ef232db417aae9956a6c68601a60d9582d67984a
94492 F20101123_AAABJJ manian_v_Page_035.jpg
3ccba6a0ee0f4ab7865101e1696100f5
7fa67d38573942e8024ad582163558846f9ed3fd
97307 F20101123_AAABIV manian_v_Page_018.jpg
ea561cb2d6146576e27e4a7334f19f3e
560cc353c4ebff64d60befabe0cf4670c9219b0c
101053 F20101123_AAABJK manian_v_Page_036.jpg
6e68991b1ce81b122f278fd0a45b992d
933f1f883510e5be72994e30592a999f126b72b9
111420 F20101123_AAABIW manian_v_Page_019.jpg
ea4816966cb0eb0e56519a53f9b6fd53
7116d52ee0f5b9cd11b86a3201fb5c175895f6ed
85483 F20101123_AAABJL manian_v_Page_038.jpg
118de8f4147a58da6bf74bd1b7f61c1d
92e808a114d021109ac504aed9cb576d569dc832
87402 F20101123_AAABIX manian_v_Page_020.jpg
8595a04287a8449b8b5f58d26bd41619
a81d78272af1a5739010c61a13c1d307f0d9fd97
89396 F20101123_AAABKA manian_v_Page_054.jpg
c1f44dcbb34d97f2d9b2f65f50c4b40c
05c503ad500f9e2ef707b0fa2ad455892074b200
106855 F20101123_AAABJM manian_v_Page_039.jpg
f5f834bdc892bd9f523b97b6fa9f26c2
36bb87c68e9ea148b6c674ea3f4924e63e171299
41466 F20101123_AAABIY manian_v_Page_021.jpg
b09f2cb1396bceebf728c95349061bef
29fe32775225675c0dac318c5cbe9152876eaf82
105784 F20101123_AAABKB manian_v_Page_055.jpg
5b291155dc0b079941b087f72cdebd72
fc76cd3edd65836daca3170e49494d39adf34f0c
103880 F20101123_AAABIZ manian_v_Page_023.jpg
b2bd7c710bfe3a21585ab411fb710187
66fee38567b6bbc84f5ed83652629e103116dec0
103455 F20101123_AAABKC manian_v_Page_057.jpg
b9d2784b7d2387a8a5058a285f94fb70
b713911cc25d66d107cef594dbeb481f4e8afb1f
102706 F20101123_AAABJN manian_v_Page_040.jpg
b77e15b3d67c08eb92c78d00de64c48e
f7234ddc93e7bac3e9d01bc27903a94fcd0242ff
70680 F20101123_AAABKD manian_v_Page_059.jpg
466cd67b6f16431ed244642c4b2ba449
8627dde6e094c38f85d4ce28343ab2f0c1a8bce5
99652 F20101123_AAABJO manian_v_Page_042.jpg
c009e7b8e4d4cbf8fcf07b6894afcb11
44cd67b565ffcecc6906b3228d09354d4c742770
61586 F20101123_AAABKE manian_v_Page_060.jpg
3b908a68f982e4e29c7a8a4edb7b632d
3c409893f97e03db00dfe14e87be526116e07757
81750 F20101123_AAABJP manian_v_Page_043.jpg
11bbc07d1d02e27b78cc92928b32b465
c757d140ab30914a89054327a0d3397e63d48736
85854 F20101123_AAABKF manian_v_Page_061.jpg
4e96396dcc360e81a58c77d25028d18c
75c24f6934b55c6cb1572197ef432d82aa6605ae
103817 F20101123_AAABJQ manian_v_Page_044.jpg
0af66446a8a300e07603754a3997c7b5
0781370e0da960bf586b5d2896d49f33e7dfd2c0
97429 F20101123_AAABKG manian_v_Page_064.jpg
304f4d0ee2ea3543e471ff9ba68d01f9
68b497ec4783c171ef030bf014af565cc196370f
74444 F20101123_AAABJR manian_v_Page_045.jpg
c8ae69003b013dbb9e168182595b8a62
df0cac4cb3e3d177861929d7da6c0e2a5de634c2
79838 F20101123_AAABKH manian_v_Page_066.jpg
de1afd79307e973e76d3682ae8437c7b
6f2597aba25d12021c99c2adb0be2fc0ddab93ad
99364 F20101123_AAABJS manian_v_Page_046.jpg
563c205dd33019c4bf330766a4b6d2df
2a5a46400a1cf13c1a2dec382a25d86088d2dfb9
77637 F20101123_AAABKI manian_v_Page_067.jpg
48c9bbc9930a0b0c756e242018cc78f3
e9d89216d0a9282c3c0942903e03bf6e489510ac
41579 F20101123_AAABJT manian_v_Page_047.jpg
6887a7e7099688fbec29a26917439239
9938e54039310630aea498f81bc52fd74352cb1d
78979 F20101123_AAABKJ manian_v_Page_068.jpg
f855f4a3833f500bc3327f16a690053b
e453b871e72a5f1e54cea7837ecf2fcf8cc872ff
29046 F20101123_AAABJU manian_v_Page_048.jpg
753315f2f0c9ee8481c829dda832c376
ffcd0203c26c4704c590afbacf85966c1311fa77
89617 F20101123_AAABKK manian_v_Page_069.jpg
98195b600983715856c878c6627ff042
8e0431f6619e2d63fcdf76fce5c85c9c7c39235e
90425 F20101123_AAABJV manian_v_Page_049.jpg
c151cd3591b03cefb5e4ecf2bec4be7b
4e6be27a94668a5a600f7b074237956b050a2f2c
82827 F20101123_AAABKL manian_v_Page_070.jpg
a5b88180211b62fc70e960b97cb054d5
d68842c2ebf221bf508dc1d69500c712b4a1dc99
77985 F20101123_AAABJW manian_v_Page_050.jpg
2ae6257137f82aab41c3101df2f62fe8
b17f10b7a39770e5cc38bb7e22df80ffb1a37161
62596 F20101123_AAABLA manian_v_Page_086.jpg
d811916f2dbb6db6eb68bfd681e98b54
b7f058e5442858623e7617be79379868a83d8829
91403 F20101123_AAABKM manian_v_Page_071.jpg
c5f5fa684958cd53fa742447bd078347
5fb45ba63c8316086ccd8b688fd0e09c8aa327b9
86583 F20101123_AAABJX manian_v_Page_051.jpg
12446270de82247531797af312399c94
15703c216b8e5ec2ed409ebe8e9cfd072cedbcb9
66986 F20101123_AAABLB manian_v_Page_087.jpg
e63842ae165a5c0fefdba0d81a9b6f3e
4a12bb1143592782cf15385dc9238e65a33c74a7
76834 F20101123_AAABKN manian_v_Page_072.jpg
0daa9dea84003a86afb473205b2d60b5
e4b1d5dc9b5e1f14014aa80b6df2bcd5be5548d8
101248 F20101123_AAABJY manian_v_Page_052.jpg
5fca089549eb14f96c1f8f53e5923e45
c68df6c8f16f03c619e29fb579974ba815d821b2
58113 F20101123_AAABLC manian_v_Page_088.jpg
543e1ed1ae8fe61680a3aa6d2d26aceb
c995fceb6135c5e097c02a7a91ad7178e3d6a02e
85788 F20101123_AAABJZ manian_v_Page_053.jpg
055ea9cf40f4d7a6718cfce4c055acd7
9db4a91ddc7387ddccdf2715c4ec72c216be4e9b
64826 F20101123_AAABLD manian_v_Page_089.jpg
68fb28f7f516ad26f86948997716e58c
56d6f96921ce5eb645e93873421cc9024f13b0f4
89280 F20101123_AAABKO manian_v_Page_073.jpg
e96b46ed2048f15dea3ba00dba0bd230
09f2c7b67b90d74b7261a7e65891bd6160a453b2
79470 F20101123_AAABLE manian_v_Page_090.jpg
b30febf451f2605872b06e84c93dee96
0be7981d18e68594e606cffd1000dab2c56e98e7
46234 F20101123_AAABKP manian_v_Page_074.jpg
dfa144d8fee9b1161bdd37f5a9a662dd
d5e5785bb2164a7d352c7732d6eed7f86e00b0c2
61241 F20101123_AAABLF manian_v_Page_091.jpg
d102dd4bc903c37fd0cc9ed51f52cfa7
1ea551d48919117d4df434f6fc72023314809aa6
69321 F20101123_AAABKQ manian_v_Page_075.jpg
34da184198cd47bd3a733d0531ba30ec
28904ef16d2a9099d2f9388dc8e84dd85a5fbd30
97490 F20101123_AAABLG manian_v_Page_092.jpg
c98df483ad06f2b001d75dd29c898787
185647fed9c741d93c81845f1ca55d4e6d53dfd6
87197 F20101123_AAABKR manian_v_Page_076.jpg
d5d2c0072b6bf82c860072d45eaa75d0
f94e1f5d3f40762137ffbbd217b04592ac1a1cae
26600 F20101123_AAABLH manian_v_Page_093.jpg
54619df2e4d09a8c91735c7cc5b69fae
e611d13985aa7f4c0da2adb8718c702ceeb76065
84950 F20101123_AAABKS manian_v_Page_077.jpg
ab8361fb14bd9fbe5b439f508e543080
44d7d1468774b09329dfa3e83cc20ad2c5755210
81788 F20101123_AAABLI manian_v_Page_094.jpg
c7101a262cbdb945881d020740a2d8b3
ee60519aa91d056c6fd3e052a7992d604e7c4be7
69606 F20101123_AAABKT manian_v_Page_078.jpg
762959313567b4f3800568a7a23fada2
6e16cc0592a94a14240532ce5a7a623ac747b3ef
104516 F20101123_AAABLJ manian_v_Page_095.jpg
1d95453691852f5c799931cc5da3d6cb
869398765b0d6704c9f45735308700ca6bb6d5ec
68310 F20101123_AAABKU manian_v_Page_079.jpg
610227ed895bb5527aa32dc6b055ca5a
03e3bc91c563c974a4b2e874f7401de03d7a7daf
93253 F20101123_AAABLK manian_v_Page_096.jpg
e1b8391fc64066b49a34075bb8e376b8
1088229230639dc4d802db66c2815b572f62cc80
94146 F20101123_AAABKV manian_v_Page_080.jpg
b6685eac9d4eeb455db9d5cf53864606
ce294479a264f45552faf1972d75095cbe214b08
86344 F20101123_AAABLL manian_v_Page_097.jpg
6eb38adb94fd34c1a8090299884d638d
4306efd314b3cefddb4754d9d1d6d860f3385ffc
83918 F20101123_AAABKW manian_v_Page_081.jpg
3efe3dc8ae6c1149cbf8c5fb20efb8b9
27222abe0338f1676f51d88bcc5a636b5efe2d26
95635 F20101123_AAABLM manian_v_Page_098.jpg
a6971b5db329f68e872ba2dc4d193537
0589b08052ba8ff21fc7334c28ca197e85798a7e
83570 F20101123_AAABKX manian_v_Page_082.jpg
6f5b18afd53e5b8a3a4b225258d9cb78
9f3d7e79da08e42cf4fa33bc17b18e9198f602d8
400239 F20101123_AAABMA manian_v_Page_007.jp2
e3515d3e5acc732cabafe0d9da3e9622
96c61a5427d9b1d5dc4fcac9c81e6abf940e8407
13605 F20101123_AAABLN manian_v_Page_099.jpg
634f969974563e26a159402e3adcde99
0112b714a740748e0cd0d2a6ee57dc44dc0d3540
64734 F20101123_AAABKY manian_v_Page_083.jpg
74a8493f64997f2d617a050eee4853fc
0052971de742a54f0a3c6baab1d8d68c2b37bc5e
214911 F20101123_AAABMB manian_v_Page_008.jp2
27a456d5ce2d7bd3f365c7dc96954539
40532a0ab31b7da289571555a6c57f98d9a30905
98471 F20101123_AAABLO manian_v_Page_100.jpg
b47d8a330aea7ba0e19ada396f74e87e
53165105e20056f384b9b40943ce192ac21bc369
82391 F20101123_AAABKZ manian_v_Page_085.jpg
1f1b68fc5ce36430d78524a06c6e6590
8f9df83cf5fe945c41961e8a3f0afae328f27cc3
95327 F20101123_AAABMC manian_v_Page_009.jp2
e2f1e508aa4760e027b7be4278cb4470
68204af2833a72cba75794d6dc98b74ddf5e276d
15572 F20101123_AAABMD manian_v_Page_010.jp2
c14353dc307b607849f9701384cbd32a
b4d1ab9911a344b6b7be6d0b571d46c8a967bc12
112543 F20101123_AAABLP manian_v_Page_101.jpg
cc811f0597ee28c3aabc48504c39da10
ba3d4e15b22a79091e2f87a864072c938e40978f
99131 F20101123_AAABME manian_v_Page_011.jp2
82457d1f1395153fcea19d4dafab920a
73d340925bd151bf0b50100d1de83067a9c9ac60
109702 F20101123_AAABLQ manian_v_Page_102.jpg
fedef83329c4183ace809147322a20cc
3b007a86f53c21a8f1165c032ec08c357f1622d5
96417 F20101123_AAABMF manian_v_Page_012.jp2
756c8fffd5be7178565aa8462643ced9
a671a4e73c2a6723fea23f3d4257646d34b81c87
118076 F20101123_AAABLR manian_v_Page_103.jpg
10cd0a0066ab70d5aad2a71e8ae6cb66
e84e689f816ae3d8081790fd57bee4deec0303f1
126065 F20101123_AAABMG manian_v_Page_013.jp2
150de97d16d550d461ad22d7f0b71e19
9cc1bcbc5b7b6b89230354cccdf5f1e8a5c9f84f
82153 F20101123_AAABLS manian_v_Page_104.jpg
49dc320cf667733b679d7dea29934577
3e94a0e0449e40255ef89f023b3f62adbbb4288c
103290 F20101123_AAABMH manian_v_Page_014.jp2
54744e8ccc9516b91aa93ba3e1728a91
794da381d1c5bef72dd94656a83686779e10cc8e
47805 F20101123_AAABLT manian_v_Page_105.jpg
21442b7ed66be1766a7833bf0365cdc4
ea60cd3eb70532ece8c42c73b8ed9a42b6de6b60
75012 F20101123_AAABMI manian_v_Page_015.jp2
a3c586dbb3990c120893573315172a3d
3754b97237eb887e603a58c10596992c1288032b
24434 F20101123_AAABLU manian_v_Page_001.jp2
c36a765dc2e19052afe1c0fdbff64828
f54a322ca16748f54cae1938d42e331c9e3112b1
41924 F20101123_AAABMJ manian_v_Page_016.jp2
65250f5fad7ab381e2b41c96d214e190
6357a46f3e6ac4611080a6e46b099e31b83d2e56
7025 F20101123_AAABLV manian_v_Page_002.jp2
509cd9d76e76078a9a0286355195d39a
0f71383e17faeafb1130163c1adf397a69db5044
107294 F20101123_AAABMK manian_v_Page_018.jp2
e307d444403d1b851f2e71206df9dcf9
95706d3f9548a7bac086ae3ccc465164afb5eabc
35488 F20101123_AAABLW manian_v_Page_003.jp2
3218ace5f79b70b3da12fef24da8e6e1
7f707702dc66545918d6275b50ccac2f08ddf713
119907 F20101123_AAABML manian_v_Page_019.jp2
c1ee2dc8e90a809d377248d7363c417b
6e8a9607ee4287e70518b99494bc78cdde6cc014
1051973 F20101123_AAABLX manian_v_Page_004.jp2
78a99e324185a4a7ca30b02c22abbd71
0e895e9f00fbd3505bf7178a586a724d5587d406
116273 F20101123_AAABNA manian_v_Page_039.jp2
7b5d0bea9b62d898e28706c15fdbea6e
fbce86ad471829963ab9cbcd2bd9e03e068ac0a6
97343 F20101123_AAABMM manian_v_Page_020.jp2
69bd198db27aeb5892a5b852dac8d6b4
4a3e2612ec45f21973deb612112c78d7ffeb21a1
113581 F20101123_AAABNB manian_v_Page_041.jp2
ba3225c7a79fedd922192e929e6468ea
76760a84702e2518667b816f9a10d402a19fe137
28277 F20101123_AAABMN manian_v_Page_021.jp2
0ba5100f607d46b963aa55948d2a0877
9a00bc1896cffb0ab7b9ac7bf72fef6ebbe5a0eb
1051986 F20101123_AAABLY manian_v_Page_005.jp2
c0a0ff1119f7ec52987ff5a609511063
731e4bc458ae4216454bd76ceabc354d586468bb
107282 F20101123_AAABNC manian_v_Page_042.jp2
92ccee6cf9273158de45c092e3ce2268
a19d55e4ef43dd4f15fb63a6681931a15197bbc5
114086 F20101123_AAABMO manian_v_Page_023.jp2
d9ede526231fc8abbeb9290a6fc12bd0
385d9a0b422d477cda873b4338bf2fc3e918374c
623884 F20101123_AAABLZ manian_v_Page_006.jp2
4a1f178b64ab235f2e337f28aeec8944
e6acd2185d1571b0c861bee7f59000b907088558
88488 F20101123_AAABND manian_v_Page_043.jp2
a10a82740cd5fdc21d82140e4154d651
8c25c64d92e403d731cc38b69f0ad393217f324a
102559 F20101123_AAABMP manian_v_Page_024.jp2
8244ed1346ccd8e765f273d5f0636332
48a8fb214cc87159fa67cf073fd723334fe946d1
81733 F20101123_AAABNE manian_v_Page_045.jp2
9b1310a473c2c96c363b5e4ae168b067
aacdf33c2748b831c0fd7b14237914bb5af22863
105556 F20101123_AAABNF manian_v_Page_046.jp2
ebbc3bc784066f2b9536c6cd66ea94cc
be657d18f0d42e873e140d06fbabce696e5e5c51
105034 F20101123_AAABMQ manian_v_Page_025.jp2
f319f45d417f25aae062a639b24af6c4
68486dd83103761ca58ae8beb88f43ada0c9bda6
45303 F20101123_AAABNG manian_v_Page_048.jp2
ee818c9ca555d296c372bd42a8ad1b0f
dca927d9ab0446a0d5cbe63d0d440936a55d9dd0
91210 F20101123_AAABMR manian_v_Page_027.jp2
73cd3bc3893fda99d2a27941d999c3e3
8f977e8e067f7d01707a12e9f682075967bbeadb
95386 F20101123_AAABNH manian_v_Page_049.jp2
63e710107bc237c79ad7dcf7ea94dc01
21d550d98efd57c9e608845157bdbd1606ba3eab
78370 F20101123_AAABMS manian_v_Page_029.jp2
bf3d36e94b12cbce6efdfecd9d632fae
235f5e65959c9e290f932637c5097c6a3dd47e34
86722 F20101123_AAABNI manian_v_Page_050.jp2
b95977b736608f1f916d4647026ed8ac
21407e0c109f09fdd5555047c180bd6f4c2ed280
107882 F20101123_AAABMT manian_v_Page_030.jp2
806bb3eb5e6db283952c830862158e2b
98b629696e497768b3c09ade5f1c6e373677f603
98752 F20101123_AAABNJ manian_v_Page_051.jp2
0fb84086e536ee69f68a6d42371672ce
47b402b6c55080face9088f352f37016cfa6f29b
78412 F20101123_AAABMU manian_v_Page_031.jp2
7718b59c6b14e41c2841c5a537206cf4
18efd0c3fd197eb6addd062c01d03c86240a58a6
111864 F20101123_AAABNK manian_v_Page_052.jp2
c06c7f540a3e4222c2c85b41f425f68e
bbc41c00327015f1f4aaa1a8bd24754585a5d1c9
94323 F20101123_AAABMV manian_v_Page_032.jp2
ce38df466f7ebddf122d2db4f246d83e
beec16ab1797164cda158cd19438ce61fcb93d88
94850 F20101123_AAABNL manian_v_Page_053.jp2
3d9a60ded705b058589f07988de7460f
89593fb2f7a6aa7e717b61690e96f1e21bec057f
101572 F20101123_AAABMW manian_v_Page_033.jp2
c28e1c420b2590a46d200f6bca17e4cf
7f76cda438007d5f5eb86c2921403b1cf8507411
92418 F20101123_AAABNM manian_v_Page_054.jp2
fb0e04744d39a106da4377f2ac3578b3
5e67948c7f49e948cc183f4149e349ba6f748f9c
105639 F20101123_AAABMX manian_v_Page_035.jp2
57b220a714e71cd4bf4083d8a8b4da9c
e5574365f234fe3f0e80623f34629921bfd62510
91549 F20101123_AAABOA manian_v_Page_070.jp2
fde7cfa1afdd6dd1c11b1fb237f68802
8740814fe5b079aafad3e5e959270353f9ff3343
116876 F20101123_AAABNN manian_v_Page_055.jp2
59c77d14180eb251aead7a80c460ddd2
910564e9dd46698224ae5dbfd5bb7ab15b7604d5
105931 F20101123_AAABMY manian_v_Page_037.jp2
d890a6f75617f5569fa65fbd3fe7f915
ee672a6246052c6958874ea19ee9a1e044c43d40
101602 F20101123_AAABOB manian_v_Page_071.jp2
2b83ac51b9b13153db829df7c737fd6c
70e6200a284bf7cc4fe44ffea9f0d6962a5c87b1
106164 F20101123_AAABNO manian_v_Page_056.jp2
4d04fa0ab64d58c6283777e9515772e3
0bf4a1123d71a26d01888acab34511030962ebfc
92417 F20101123_AAABMZ manian_v_Page_038.jp2
f05019094e139cd64c9865c323adae96
99c6c1b8c04668de0ca7f8dadaefb80d0c534b9c
83092 F20101123_AAABOC manian_v_Page_072.jp2
f5d6658d0f0f09673f110d15e863ca29
0f40fd7d38d01c8e62929d0c2d7cf874b265ea54
112238 F20101123_AAABNP manian_v_Page_057.jp2
e7e90e0a94295f5c364a08b1a1ece1cc
165c1ffb7e25e5c7d172f9a95060a897bcad6569
100000 F20101123_AAABOD manian_v_Page_073.jp2
7eaec44f21dc484ec15c300b6b272177
d23198edfe460f2cd930accb0ddc96fcd4e1cacf
101891 F20101123_AAABNQ manian_v_Page_058.jp2
fd61e7dfeea732b31d6b1e760c8eca39
7e0833d9eacd5d17369df723f3572d866fae6298
50738 F20101123_AAABOE manian_v_Page_074.jp2
00557cdff379f28dc5bbcf40929f5494
b2f2e65a21b37dba30aba47b4eed36ead49753dc
74587 F20101123_AAABOF manian_v_Page_075.jp2
4c08e4aa7154de175596198f7dc7bb9f
32f7799b2d8fce0333c3380bb8bb4c4d0dbb9163
76105 F20101123_AAABNR manian_v_Page_059.jp2
73ef9e1d1520f67b5320b9dd8cffa72b
7d31b4f31ad1bf229442f82d9e885b3ac4a077a5
F20101123_AAABOG manian_v_Page_076.jp2
d0fbfd90b880d9e18aeab832382f150b
61c87fab434dc3ff13faca22b48b1d4635263c68
99799 F20101123_AAABNS manian_v_Page_060.jp2
3fbe1f13dba75da7c0336358231624f7
fe1a8b1f5867d3282f3ef8e649491c75ee98e71f
90182 F20101123_AAABOH manian_v_Page_077.jp2
d140125ff8531948fd79ae71d2ec79a1
b0ee15dbbc837f1425a01ceb8d9358a17fa3f829
91886 F20101123_AAABNT manian_v_Page_061.jp2
2a25fe29873f90af0575962645fd702d
500780f768308927ae95747d4ebf9767bff47ee8
74854 F20101123_AAABOI manian_v_Page_078.jp2
64854d8220de3291ddc6a6040a617bee
22902ca97518c3c3be7e2aafaa7e5884b34c6ce3
69047 F20101123_AAABNU manian_v_Page_063.jp2
544ca93e7212c0d65f484d5cbf358a26
487164af45edb1362e35ae18d9dd09a3e76357e3
73994 F20101123_AAABOJ manian_v_Page_079.jp2
c4f0cecf2e686dbaffa5957ce866cc25
007160de515d2dd750c494ffefb12b57fb067937
105459 F20101123_AAABNV manian_v_Page_064.jp2
649219cae193d3490162272c63e87044
0752d2d0655a6707ef6e323ee4016116deb9ccc4
104192 F20101123_AAABOK manian_v_Page_080.jp2
115479cf4f26059aee83f35773b6344b
8ee887f1037ba84124d803d1b94913f6a9589db0
92831 F20101123_AAABNW manian_v_Page_065.jp2
05183200feee24b119fdf7a116d5cbe5
0a17a737b3ba3450437efce0fb35e06ceebde984
88512 F20101123_AAABOL manian_v_Page_082.jp2
805fdd002dca533f07e63ad60f978b12
942f04ed8d4d7030ee04a132c2745444f19b342b
94270 F20101123_AAABNX manian_v_Page_066.jp2
30620b33ed06cf3a923606f50fff2d0b
2007bda472c1503537ce3c00ae63a738b4ee3f48
104484 F20101123_AAABPA manian_v_Page_098.jp2
3345b58f8f3cc82ac74a54eff425f297
bcc135e0691741fce5591352e1eb2fda723f1ee6
71627 F20101123_AAABOM manian_v_Page_083.jp2
e903f6689ff57c26d12ff1cfe8a0f1ca
749237a44d5daacf311941495e311e8467f1c903
91859 F20101123_AAABNY manian_v_Page_067.jp2
a6aeb824345cc2e044d8a20aac7501d0
c7c195ad63728b66a974d8a31479a178a7a2d54d
16541 F20101123_AAABPB manian_v_Page_099.jp2
8c1e6a6f91a0f049702a9b94b939967b
a09d88f0d3cb0a94dfdfe9483ada583cbe5f5944
90392 F20101123_AAABON manian_v_Page_085.jp2
ab4f19146ccc57e0ae57123279e0d3bd
c40334170da53b91ee637d29f116329359345025
97055 F20101123_AAABNZ manian_v_Page_069.jp2
73b1eef1200cf780f94fffeacd2666d3
b66347d92eff5b05e154e0e13526d907466b87e6
110256 F20101123_AAABPC manian_v_Page_100.jp2
f99f5b7451031bfeafa93c6664008f75
9d7de9f293631e3df65d4a16346b7ddcea73a0b4
67786 F20101123_AAABOO manian_v_Page_086.jp2
0f781592ba47ff8fc5cdb1889e78deb3
fa0633a550997df20ca603dbe917ce02d53f29e3
123374 F20101123_AAABPD manian_v_Page_101.jp2
65633cd4a2acc329fa5119e5078d61e2
a419951ecaec2646e867c3742c8682e43f02d5e8
69658 F20101123_AAABOP manian_v_Page_087.jp2
ccb59b15a08369d4f03d09703ed9c9b3
1cb7a5ca32778335005d96259b1a3f8a151bebe3
121427 F20101123_AAABPE manian_v_Page_102.jp2
2b32064139b86efdb5e70be9c09ecd22
349521bc55db18725a6e2dbc83bccfacc08da135
63251 F20101123_AAABOQ manian_v_Page_088.jp2
9706b5f7e4d254ac427de5ec0e06729e
8fc0fab1bcdf1b11cc0c90a540e492892528bd96
132459 F20101123_AAABPF manian_v_Page_103.jp2
3fa7ecfaa60fe88d45ece26dc11704a4
2c6ff58c168e093bd99a273518bccb53bf1e6f2c
74178 F20101123_AAABOR manian_v_Page_089.jp2
3e62144be3dc78f0fca9e72bec3fea15
abe93db8dd8e98821d5c4ad53aa18df105f4fdb5
91913 F20101123_AAABPG manian_v_Page_104.jp2
8d0293025d20106aa4d1a8ce3f220128
259cbad72c7a3b40304e0be944007f01195b9666
49985 F20101123_AAABPH manian_v_Page_105.jp2
3e25026dcc9e90d0195e5651abf7ffc0
57dac7e011b108b3d4b67b346dc5d4e0c1ce8116
84276 F20101123_AAABOS manian_v_Page_090.jp2
3cadc3fdd11d05bcb5792f51ad79234d
fb5b285018d73da06ae7e4387d9d0ca466c35bb1
F20101123_AAABPI manian_v_Page_001.tif
981ca3047064710987fc357dfb8cc382
f24f29fc46ea8afbe3f600cc21cbcaee09dbfa2f
65043 F20101123_AAABOT manian_v_Page_091.jp2
791c3da63086303ce7b3bb833ff2d407
fc8aaee89c119155c8e0d7ee2543eb18efbb2201
F20101123_AAABPJ manian_v_Page_002.tif
a98646a5eb0545aab0f1e82cd1a386fd
b3dbc4d8330f9c63602529bfefcc3cc909ec8cd4
105130 F20101123_AAABOU manian_v_Page_092.jp2
5683fa7ce5ecb817e6a989244cc72560
88937c4e03b593a932d82baef8f8c53e9977ae02
F20101123_AAABPK manian_v_Page_003.tif
8824dfffd65de92fa1b488575ba01c1e
20f80cc117dd46734b26e42385f2f14c823ad2f4
29431 F20101123_AAABOV manian_v_Page_093.jp2
3cbb76a86b3e64bc910cfb5b93e47438
8b013eca0c1378d9f209511d74ec8f81728981b6
F20101123_AAABPL manian_v_Page_004.tif
a15b468e9a3407066247d4004ce72781
ae9a22434a56bf8d5f543c117a1a46184a627988
90406 F20101123_AAABOW manian_v_Page_094.jp2
0579a0d0eb1fbb7b30ce5cf48ef68256
4772f80c517da53a70a582aae123786a73c2924d
F20101123_AAABQA manian_v_Page_023.tif
a8708f2de2a35dbfe09277aed0b21dae
85969f7725bcbaf63c13763adbced0bb59ff3897
F20101123_AAABPM manian_v_Page_006.tif
946419f75e7ea977f5c10317e2813057
dcced77faf7b03ef23926298e93926c22d358ef5
112412 F20101123_AAABOX manian_v_Page_095.jp2
f714fead924f5263c59eccabcb3ab9ff
aee9b38dc2ce45032902060556b00f7680c5f56a
F20101123_AAABQB manian_v_Page_024.tif
0054ee7d08861fa0c5c55e450f7b8a44
25ed050f27b121684ace5e46677030118bff13a6
F20101123_AAABPN manian_v_Page_009.tif
a6b54b7db524552cbae5dba2925d0664
9548c2632adf11cedb77ba8fb3855006ae10c478
101122 F20101123_AAABOY manian_v_Page_096.jp2
eb42c4b7b34555d341fa247ac0918586
03bbf1e81f98f3a53e326afa3c43124bb1ea8a6e
F20101123_AAABQC manian_v_Page_025.tif
dd27b31ba0fc0e25f2fc669e934b0c56
0b599b656d2cbf3bfe3ec5ce54126200ff31b998
F20101123_AAABPO manian_v_Page_011.tif
d05fecfe58f16ed61acb877ab14a507f
a81b1ea707141af9ec7dec3f56a79c4e9b0fed73
93514 F20101123_AAABOZ manian_v_Page_097.jp2
cfa2df720e057cfb679561ff4e38b361
dff5f9f53a97023189bfb23a8c5e224c74b11385
F20101123_AAABQD manian_v_Page_027.tif
b8804189f7d59193be52e59792deb88c
0d4c3024c300fdceb68bd4333a7f4fffb92905bc
F20101123_AAABPP manian_v_Page_012.tif
6981544551d0dc6862993ba77d65a945
81f94a2da76f597e93ab12d42c9ccf013ac74dff
F20101123_AAABQE manian_v_Page_030.tif
0ba24d887588b7f2d14d84a863b209b3
40bd5033ea05686a70ef4e87fff9d0fab7012d1f
F20101123_AAABPQ manian_v_Page_013.tif
e5f85fcb25d73b484bf1d032d17a1bc7
5d7c249bf57bd8295350fa90206c572213ed631a
F20101123_AAABQF manian_v_Page_031.tif
df66141b6484db6034c5a72351deb1c0
de4f36f40b46ad74e24513edf2f7ff3ecfb3b68d
F20101123_AAABPR manian_v_Page_014.tif
619cb03a2c894f449cec14c286e52884
5869755d71261cd8a3d628d2a04c0af8648e822c
F20101123_AAABQG manian_v_Page_032.tif
0d271d50bab8b7801d27d22c9b9a29cd
d1d8fb8e77dfe35a0860567972c3e1209d111a7b
F20101123_AAABPS manian_v_Page_015.tif
6f3a2f285b5ab9b1bfcbbed11122386e
fba04bc3be3a7a5ac97a4e0b2749f68b36e11938
F20101123_AAABQH manian_v_Page_033.tif
49093015934891c9110104b8618d37eb
99a7a7a74d6c96b2e717eaf64a8adb396363fca0
F20101123_AAABQI manian_v_Page_034.tif
dd067f6b275bd4ed5432639d6f2ff70d
86e042373f8f3b23d19775627b1e2c5c50b5803c
F20101123_AAABPT manian_v_Page_016.tif
6b64a6328cbdaec846bb9fe5b6e400a6
b654a45e4cde502c67de54bca4d65e254303a1c0
F20101123_AAABQJ manian_v_Page_036.tif
f3d8583446ae875eaff998b85a0259fc
3f26251f71af4c8e1ff3d10d4c10f8ece0b72dd9
F20101123_AAABPU manian_v_Page_017.tif
571f0526efef6d20c27c7aeb2be894f5
e9f9fcb845ae8fed08bf0e53691ca234eb2e2186
F20101123_AAABQK manian_v_Page_037.tif
79328d7e024d4d0774bc4cd2ed1ad3dd
3dee89d5e9f755f59c983f827823bee51728aa37
F20101123_AAABPV manian_v_Page_018.tif
ef9c24b2480221dfc3f0f2a89cca98cd
f46a0d43d9cee6ac79fc83bf920ba6c2133e82bc
F20101123_AAABQL manian_v_Page_038.tif
e877e45b8c9812db3ce464bdd851eac5
8ef3cfe052f5c02b879a3882cf1aec326751f5a0
F20101123_AAABPW manian_v_Page_019.tif
b3a9cf7a62705e1cd10d833758d1f7f8
4490b7410fbc045bf234ae196ede4cc205b53075
F20101123_AAABQM manian_v_Page_039.tif
be9a94cb9a71fa118a8519b396bffd1a
df34bf07a685e5e44cd8ea8d1275c614dec0ca15
F20101123_AAABPX manian_v_Page_020.tif
939ef09a6419b14c4ebb4d9d51674510
f8a1550f363c636f07b04f6f9039a810179874e9
F20101123_AAABRA manian_v_Page_058.tif
a03f554cefda0e7377afe1b85063c469
7756b7fce842b4304b7087359c9a1e795b22749b
F20101123_AAABQN manian_v_Page_041.tif
515b06dc1dbc46c6bb575aa992585745
a73aa6254ffa51bc8febc5ad2706fd0b2345e760
F20101123_AAABPY manian_v_Page_021.tif
053d2038677355c5fdaa3490cff0158a
58ca4d4ee5dc0c1775e4c71e251bc751de02d4b2
F20101123_AAABRB manian_v_Page_059.tif
32f1acaccefbef8ef5ae9243f2db5772
2f7398fbeb036419abff49baf7b2653288c65dc5
F20101123_AAABQO manian_v_Page_042.tif
1e20ba93d85edf978b770f89d012a4e7
1adae81ca528c8bcc58eddb681d168dd47d09952
F20101123_AAABPZ manian_v_Page_022.tif
7ddfaf11c4ef1758ed2e94477248d8fe
fe3732660009004fbe0fd49fe71be036057a7691
F20101123_AAABRC manian_v_Page_060.tif
738b82cebc80f9cb50231dad7c71d1bf
ac55290b94f2c155fff009b213f63db36587bee7
F20101123_AAABQP manian_v_Page_043.tif
5ffad8db5ea683d6449470f0d676ed19
19fb8f988b7441f48be21f319925b9c65a8c39dd
F20101123_AAABRD manian_v_Page_061.tif
a77102f115d72a91bb6cdeee88957eda
2f3803db1058ded8a8d953b6c5d0c1320024b48e
F20101123_AAABQQ manian_v_Page_045.tif
1f7fd113c1a3f3ee433e0899668f88fd
cccd20214c41dbcd1b9a41f77e759a1b84262549
F20101123_AAABRE manian_v_Page_062.tif
f94cb51c145626bbbad521b7a7ed76bb
b2e93204df65563291e9350978d62d661faaf12d
F20101123_AAABQR manian_v_Page_046.tif
d50d0a89f3095c8911e37c8e91958e6e
6a2d3559f388768fb6d3eb165385aaae1c643e08
F20101123_AAABRF manian_v_Page_064.tif
6ae5f82310867b5f2991d03a41551c70
dff2f315d0ec8b27b90a3bc69261e36323a6f1d7
F20101123_AAABQS manian_v_Page_048.tif
1c5b20345f67c1d52420f47cb1543854
5488e5612ad75eeaed4cd947b9d9c55a7f01f698
F20101123_AAABRG manian_v_Page_066.tif
1ca92a271afc763f691cc3916ddfe8d9
61ac77918002467f49d2681f7de0927f6c79dfe6
F20101123_AAABQT manian_v_Page_049.tif
a5a6976da7254ff0f8b6d5909e4c78ba
ef476b6294ddbd2ca5046882f7dfb3eeef5c4065
F20101123_AAABRH manian_v_Page_067.tif
b0857cdc8dd32ee17758b9ec872b9c04
5af0f4b1a1525fe28810a7136c268c0b367319db
F20101123_AAABRI manian_v_Page_068.tif
0eed683017c9e63cd04aa9e1452ce039
7bbc439c3895ee0669a7f6342a6b811964025588
F20101123_AAABQU manian_v_Page_050.tif
afcf2237a7b17f20886da27e41f20805
34e3ce362b84cd93ca2cdc8734c3eb7f0dee646c
F20101123_AAABRJ manian_v_Page_069.tif
3c748e54cca42f817157fcad5b908f6f
01e9e1a650192d9d30060d7bf1389ddfa081897f
F20101123_AAABRK manian_v_Page_070.tif
f03aa16404664cc021b17d568a28e271
c31d23cf42e0b7d105acefbdb8eb1c94231bf1e4
F20101123_AAABQV manian_v_Page_051.tif
cf36ac739fcdb9863700dcb5ea7949e6
1bdf295fa215c8b65747250ddebe0fac04216e67
F20101123_AAABRL manian_v_Page_071.tif
4d43a2c8b0bf655b4872907a736a5b8a
19a270bf121fcdfa0597912fa4c20e67f28c0ae8
F20101123_AAABQW manian_v_Page_053.tif
7a2ad38380106fb570066d3d894b252b
99235aac2c1ff89894ffdceecaf1a8f98010a4bd
F20101123_AAABSA manian_v_Page_088.tif
c6da796c6f8e48a0ca496fb96d3b3bae
92e592e326534704725e7e8915c15ba232d80ce4
F20101123_AAABRM manian_v_Page_072.tif
23b7714081a9e3b3c74bcda0099947fe
66434b67705bcf867ad4bb8cfb1cb665980ebf10
F20101123_AAABQX manian_v_Page_054.tif
4f7e9baf3513dbdd01e063cfdebf27a7
a86278a962d082c5325b5d78b7c309adabab91c7
F20101123_AAABSB manian_v_Page_089.tif
3205c71733d048535cb2b29f4b80e798
9344a541c469c3d590d8da5a6ba55fd0cdda3eea
F20101123_AAABRN manian_v_Page_073.tif
af828806b7487fbe9a4096bbf55f20c0
9b5002d4d8d54cb97d30dd9b9a3fa7b7482a57ac
F20101123_AAABQY manian_v_Page_056.tif
626920dfb5d5fcda44a58bf9bfa1ac1f
b3447f31387761a7ba29e64eee0f1b8bb75678d0
F20101123_AAABSC manian_v_Page_090.tif
89929ecd2cbf9da74553b667ddb8bd07
a2b2ba66c69bb039ec382ef9d9d4829207fd6935
F20101123_AAABRO manian_v_Page_074.tif
5384c72d6ccec18935cfaac33ee6f610
59ba477cbc700465ada53d00472fd92d01fc0a34
F20101123_AAABQZ manian_v_Page_057.tif
7c64e9dcef5162c7062966beb1a8ebad
8bdca372796749464e6ac30271247dde645e4a1a
F20101123_AAABSD manian_v_Page_091.tif
843be18b1c5f2a8e2a8073517a53e2ec
da69404abffa46443dbe7f63430f7888bb1a692a
F20101123_AAABRP manian_v_Page_075.tif
141210ad41fbf1c8c54bdabe651f5250
981ba3ee2bb1aa5d1401478487c6e7244467231f
F20101123_AAABSE manian_v_Page_092.tif
bb847bacf57a9c7ec14e0b9f70749eb4
fbd6355445354a67491280e7b3d308ff42534058
F20101123_AAABRQ manian_v_Page_076.tif
5e53f322c353ed8daa2c7a03ae2ba177
74c3732c0e0d7e9e04cf623ec57a160713cd2eba
F20101123_AAABSF manian_v_Page_093.tif
0ef785770c4418a1c553c3bf668dc2f5
41b29a0053407394bcbcf0826e8dd6562b8454b9
F20101123_AAABRR manian_v_Page_077.tif
208335cdf89da1057181952fa2127f11
36030f704071a5c97343fb57957e4750aba137a2
F20101123_AAABSG manian_v_Page_094.tif
416c6a8673b12d7b72caaf619ed3af6f
4e416667f720eba47a1205eb0160c4860001c85e
F20101123_AAABRS manian_v_Page_078.tif
2483da74f47a08e170bb753a2cdc82ca
c8a2ee6c7e8489fb65f9bb5bb4e62e9f9db34d5f
F20101123_AAABSH manian_v_Page_095.tif
6c180e05bf14c6c84a27705066e5b97e
902f74df25f549fe718cdc656c36210c654479c6
F20101123_AAABRT manian_v_Page_079.tif
84884725cfa356b5852b32eddb3607d9
9c4b82a6c936c6994489ddc3ff45eb85ed74af13
F20101123_AAABSI manian_v_Page_096.tif
0346537a42a4585440aed828a02e443f
56cc82466d325f4c16b14e3e710dfec751e64768
F20101123_AAABRU manian_v_Page_080.tif
367ee19cbef8e6de5f92a7bc0d76dbe6
0c51b0c356288741dbe36f4c701b8ce2ecc986ae
F20101123_AAABSJ manian_v_Page_097.tif
a019be067c4486ae84cef55da19be934
5f092b647b3d41eed3e9be11926d57ad7b25e2dc
F20101123_AAABSK manian_v_Page_098.tif
6b8c61ee4915fad3921c0904ddc52475
032f6136c0d8242a587e4ec0796d4454788836aa
F20101123_AAABRV manian_v_Page_081.tif
0c9f4587ab4308756dd71a778020be04
60b2ee000d6582c7ab00cd0fb5b47af655712843
F20101123_AAABSL manian_v_Page_099.tif
313d2d199132f8ab314cbde96ec0d7c2
81f957b5da2a7b7d4550d91d5da5772584e1b19e
F20101123_AAABRW manian_v_Page_082.tif
61d5333276ec8265451010be8a162782
8e0c569bcfa9b65bf032d73999337751e3e98ae7
F20101123_AAABSM manian_v_Page_100.tif
3ff97b9c8553a260fb08ea180a658e3f
868770eec7be5dd4c0b618000539f2e377e04ed9
F20101123_AAABRX manian_v_Page_083.tif
8b1cd704b73103cd456f84ff2d75ec1e
0aad2e16ea371dc46a351cfe92f912d3c4b08fb2
5698 F20101123_AAABTA manian_v_Page_010.pro
ba5c9e5b1f2d7e4ac05e96165bbeeb84
9e33803abb681f75fd6649ecf97c22e904821423
F20101123_AAABSN manian_v_Page_101.tif
7a7216a6476e3793ea8b4751ace26e7d
3038530465ad744990e7909336c4c0dd0f4e8b97
F20101123_AAABRY manian_v_Page_085.tif
c9a00bef8fda106d1c1ffc1898d12650
d42895809d967da6bea2b2f5c4d930c3ccf4dc16
44827 F20101123_AAABTB manian_v_Page_012.pro
0401c03bf4227f5f27680f1a412c5840
a2d5463f17121867d1ef1fc2e2da164c5135a717
F20101123_AAABSO manian_v_Page_102.tif
509678dde2161b8d3852ff69884027c2
a3e63e2a5c1c3cce4acdf954a5dd42ea244b37ac
F20101123_AAABRZ manian_v_Page_086.tif
798ba91c5c041df3e9743a3ae4c35c0d
1cdc1f28063c394413903e182734c2c216ddc866
62736 F20101123_AAABTC manian_v_Page_013.pro
14a36d06f22a73b2a46452f2948f0730
d1ccfa9c337670ef51d3d1b3e1aab7be8b2677d6
F20101123_AAABSP manian_v_Page_103.tif
c6f0add57e2eed2f09be81550903291e
4dde70a843be68d18b4a6db749bd0230314aefbf
49991 F20101123_AAABTD manian_v_Page_014.pro
9078429b20dd762ebcb438a18952358a
3ca49b8fe8e08150c8286848e5912f37027ca9b6
F20101123_AAABSQ manian_v_Page_104.tif
2b2e2170c5dcd8346d20146efd487932
ad2986a18ed781dc11d38373e0b2b056dfb64cd6
18195 F20101123_AAABTE manian_v_Page_016.pro
223e8b00b4bb389043658ba869964592
63aa370615b5324bd4236fe81e83ea250ea6a9cf
8003 F20101123_AAABSR manian_v_Page_001.pro
2dea859e1e8df752fe70a1d56156b08f
a2d207c550d160fbb4c04ed52abbbd9f5c2b28be
40958 F20101123_AAABTF manian_v_Page_017.pro
50efdfb2454b0bccfbb4b20bdf4bf2da
51cd5bfd0837fbf36031f26ecefebb85691bc0dc
F20101123_AAABSS manian_v_Page_002.pro
689936239a8d47ee79e84868a49fd95f
6abe939a69fc02918cbdca8ae52516d01704673e
52337 F20101123_AAABTG manian_v_Page_018.pro
9e138aaaf44c1b962729d2507c7051ef
22f9447ea026e39e9f237b9bfe835fa512cff349
15408 F20101123_AAABST manian_v_Page_003.pro
03e5c890b641fbd3fe59c0d9d3ab9865
5247c90dd3ad9498e82140a6031efc39454df4cd
45563 F20101123_AAABTH manian_v_Page_020.pro
1615271770c2d44aab6b9bbce171c5cb
0b78fe36545560d5e597a9fa8e8c1aba0f102a7f
48878 F20101123_AAABSU manian_v_Page_004.pro
b98b4e0b0cdfb9cf2000b27f86a605f7
4a4482150c0627eeb7b364545b2824c07533339b
1486 F20101123_AAABTI manian_v_Page_021.pro
ab4529bf1dd107269cd479ebe031bf59
556b2e67abcf08eedc91162d1aa91a86f243cc09
66269 F20101123_AAABSV manian_v_Page_005.pro
5ebd2c62d03b9039cbb7fba342bf646c
a00d2154042f42e6edb3f6fd120dabc141698b4c
54734 F20101123_AAABTJ manian_v_Page_023.pro
303d411de8bef8000e55a13a166608e5
e90e6c1e53ce2abb41115a10685a25980f4a6816
48722 F20101123_AAABTK manian_v_Page_025.pro
366113d9794e0a495679ec2e70a0c96a
f74938e153c34fa0bc8e9cd19b6c46ca1b484046
18194 F20101123_AAABSW manian_v_Page_006.pro
cbc51641ea001626da710cd53ec77766
bbd8cada7b65c168e02d0064541376cc168ccf9b
6969 F20101123_AAABTL manian_v_Page_026.pro
e5569110519edbcfd9cece22be6ed52d
a9da603517a76052965e48f11568e114425119f6
10498 F20101123_AAABSX manian_v_Page_007.pro
8b2e5ce1d0a1407ea04663552ca5649c
1b1f6fe7d363ca1a890d6f40274670d693ab572e
41766 F20101123_AAABUA manian_v_Page_043.pro
0e115ec474e076ec49b57261cda8ab0b
a47ddf1a17b4458b714966efc681ed1260db01b1
42986 F20101123_AAABTM manian_v_Page_027.pro
29600a98e5172f748b023b49c22d683e
fe868714ff554d98b749a7098aa8756866f193cd
7202 F20101123_AAABSY manian_v_Page_008.pro
a709bbd7d745ba57f1015897a8da4b3e
092092083ab90e542581b703731d2889165b2d8f
54629 F20101123_AAABUB manian_v_Page_044.pro
ea4cd27b193aa39646258439adcc9b24
4024b35cdfc32cbafcfa97edbe224f1d297072a7
54755 F20101123_AAABTN manian_v_Page_028.pro
3b49a06f41f53aa6962d059f0e5d79d8
fabaf2e3780144718f2060d269baa7ee64e3c984
44845 F20101123_AAABSZ manian_v_Page_009.pro
ab741dc3e614dead288a62604510c766
aa3f7209f03c6782a1db4dc70641f07258fae127
49877 F20101123_AAABUC manian_v_Page_046.pro
eb6fb7b7dbd174d1f34a4989692288d9
0e738d8eb52785e6063b3ab2fc859dd71115d678
36396 F20101123_AAABTO manian_v_Page_029.pro
20606c337e4b66d3c35c273c65612a98
80cb9aa42c9c0d65b74fedc69557194c58a20220
30717 F20101123_AAABUD manian_v_Page_047.pro
5afd55cd430c005a8b6bae710fd7544b
67168a9fe979d9742163294c2f234dedbf54b675
50405 F20101123_AAABTP manian_v_Page_030.pro
568b3a4059a67c5bf4a0fa62cdf18ebf
e9c944f6420dfa1fde004148aae22564c89558f8
22534 F20101123_AAABUE manian_v_Page_048.pro
a6ac204624fb457822211e21d40b05f8
e12192eba9fa0b2986843bd0bf4f8a99eac707c7
35691 F20101123_AAABTQ manian_v_Page_031.pro
746897c9ced755a29256fa90bf656cd2
6b141f70c16fe8c9ef65d75dbddebb52b4d79dc4
42360 F20101123_AAABUF manian_v_Page_049.pro
bfb385a2277366a37d1a7ef34deb762d
0b941ea4c3db086e2493d109efeeb437eb743904
44401 F20101123_AAABTR manian_v_Page_032.pro
a8660393d1c6823a28dc93bb77f0d73a
7b346129fd95c50317feb274275e841135bdb263
6290 F20101123_AAACAA manian_v_Page_009thm.jpg
31b3fe582fceedc94cce4c2ff96cd295
b9ee0c8ac972d5298154e41470da9d6701799cd8
35454 F20101123_AAABUG manian_v_Page_050.pro
227761b9f5aefeffc53d2c51a8fab22e
70192f607e9e3062a50e43fa093d21a98f84a829
48714 F20101123_AAABTS manian_v_Page_033.pro
5426402aa7dc2be35898ee9d8a5d8fe9
832cb97d3efbc682df021acf1954fb5d2d9a834a
27603 F20101123_AAACAB manian_v_Page_009.QC.jpg
919a701bf85e3946535df883d5253911
c6731a846a062e54400d31160c17f5a2c3a6eb8a
44759 F20101123_AAABUH manian_v_Page_051.pro
a418a86f451ac8923266f3705ad30fda
309d2d929de631ea84fd171ee70a728e1b36eda2
49697 F20101123_AAABTT manian_v_Page_035.pro
fdc452e059087246959555574c4e2060
c1b8137829fdd6d04347a30cf55404747c9ce5bf
1257 F20101123_AAACAC manian_v_Page_010thm.jpg
857b4270de4af188c0305c01d55aa605
a74455ffd9fe7ea0922e3c46fef53c4f9709342d
53236 F20101123_AAABUI manian_v_Page_052.pro
d2dde5986c53da0413039f98d93cd02e
a1667ecfa62d61f8df58390b39dd6d9dcf51dd7f
52579 F20101123_AAABTU manian_v_Page_036.pro
06e95c07fc81c7c46779b8262df33139
84af145e1c9740914b1cce62e9516f8861a802c6
42943 F20101123_AAABUJ manian_v_Page_053.pro
c83a380573460611d84a1029f1ec3660
2327a861944accae2e436af6fe2bd14fd1afa90b
49993 F20101123_AAABTV manian_v_Page_037.pro
7a639940c14c947fabc0f8f327762bfb
87aac7c8710360d2e8573bbe95de7b4a01e06a3f
4169 F20101123_AAACAD manian_v_Page_010.QC.jpg
d3e91d809f07d29135d3c49d4ea09150
fdbd89a4307317a8fbee33e067ec7cc75ecc815a
43710 F20101123_AAABUK manian_v_Page_054.pro
5e2af9cf64009f596014773abc15e882
76615de56ab1f0636e188fdc3a5f68aedb8b4960
42696 F20101123_AAABTW manian_v_Page_038.pro
876e6bd464c62fccbeb6463eac2f6de7
cef08346b7aa810db673776bbaf7fd42562e32b4
6416 F20101123_AAACAE manian_v_Page_011thm.jpg
00dcc923f0c32bb76585c3bbad83cc30
5e4552f6ce317f5ccd3592fbe389e56db7341585
56090 F20101123_AAABUL manian_v_Page_055.pro
8b8e6685e49f497196f5eb2fdc2702f0
1fcdf0af317b359e9abca69e958d8756775b2e24
28302 F20101123_AAACAF manian_v_Page_011.QC.jpg
1973e6aba46b7f90a41df8e3f3936fd1
444f0b5e81e9fd8b42fb1384dd2b5408b3b507f5
45740 F20101123_AAABVA manian_v_Page_071.pro
30f6e953cb84d745309c22f86f1d48c4
0d72396e30616fdb060810231a3984c122656838
51729 F20101123_AAABUM manian_v_Page_056.pro
d9373e7727321d8520c21e01f27efeeb
5d2557a78577720c12e580db910745108a0a3496
55359 F20101123_AAABTX manian_v_Page_039.pro
fa030d3a95ae8a7efe3d58e99a3b5971
83da6e132bc77c287211927c6a1bb76430366516
6400 F20101123_AAACAG manian_v_Page_012thm.jpg
1a2193f481dc2a399b91956dade400d3
9271f78eb1ebe66f4669b782fe1cdd7fbbb01b62
45618 F20101123_AAABVB manian_v_Page_073.pro
28347b1819d39d7f05decd7c6e02d184
cce02aa1f69ea6ef61be3a8a7e038df75b3018eb
52911 F20101123_AAABUN manian_v_Page_057.pro
49f27ab921928df16d59b394a8abbf7f
2bcd0cc10ffbc8428e5b3866264a7f8c90765863
54462 F20101123_AAABTY manian_v_Page_041.pro
ad393e5aff75c68cdf94bd283af2431e
573b8d3645d042acd66e800b794d9bd6b8b2b5e1
26894 F20101123_AAACAH manian_v_Page_012.QC.jpg
19efc3e6ad2f8e4cc7da5e7ce655023b
ea6cf1605f3797f063c2085f6c896bd829bd70ed
34740 F20101123_AAABVC manian_v_Page_075.pro
7b45a9c4d5916945edc263a35685e3a8
9bba99c947ec9c4b9a58ab9f97b4891923de0686
48149 F20101123_AAABUO manian_v_Page_058.pro
e7c7dd8ecec771a2430fc1462a1e489b
7f553f36da8d0a97b22d1c0f137ca44dee25813d
50666 F20101123_AAABTZ manian_v_Page_042.pro
1ace5709d56b92c902b3cd42e0662d17
5d38efa96d55645fbfce5f3a9690e5153e540f21
7742 F20101123_AAACAI manian_v_Page_013thm.jpg
c59d99b4e005d3ad91c2f3d83508e587
7799a027de12b94567c5781c9eeb9921d3a0382c
43936 F20101123_AAABVD manian_v_Page_076.pro
91e81c1dc1105d7c478161ce02816bcd
a844b6102e1d8d76a15c894bf530b4fa26c53c67
34462 F20101123_AAABUP manian_v_Page_059.pro
15971ec9fbd9ac2510ae30fe4b5d68f1
df32587b0339edfbaa28d7766a5c699e8e23e245
33137 F20101123_AAACAJ manian_v_Page_013.QC.jpg
cb067e885dc76b862e737c4949adb43b
3df46aa8c59d0055de79431f6ec7e1b60b7a0b0b
42138 F20101123_AAABVE manian_v_Page_077.pro
8ff8c3c21ea7c45a250524ee9b338d07
9238a8b04faf61c346d16a2cd2b8469b0ffaf5bc
41901 F20101123_AAABUQ manian_v_Page_060.pro
ef42a6447a6385fdd92d0358b0cf800f
2d3be695485d011715035d1f36adc1b2f71f9db3
7054 F20101123_AAACAK manian_v_Page_014thm.jpg
ef302fd1ce1423fc281a5a2c069e80e5
ff6e83dd5d8a1ab724e0043863864798f4c0fb4b
33858 F20101123_AAABVF manian_v_Page_079.pro
9b398d34b83cc902481fa4ca0a9ef2b6
173b8f63c73705518b20226e6910de2ad261e489
30690 F20101123_AAABUR manian_v_Page_062.pro
824756614a52d29d713919be80578b79
3820dbdf7a57b68d782af426a894881deb5faceb
7441 F20101123_AAACBA manian_v_Page_023thm.jpg
69b074e56ac5343761d00489ab0abb89
0d01507fbfc24073e6000a4d7b734f0b60ddbe10
29364 F20101123_AAACAL manian_v_Page_014.QC.jpg
aa368ade85efd69a1c51491f065f1f6c
a9ee5ad302651c6a4fadede35a89038c8cb99e15
44239 F20101123_AAABVG manian_v_Page_081.pro
ce83c5c469b92711388293cbbd58e622
c8bc42f5682bd3adb2669b24d2b6eee1816f147b
31808 F20101123_AAABUS manian_v_Page_063.pro
ea98bbe0ebe80b159ec9843af163b6dc
aaab787f827499204af4a5caa8b18f922a6df6e1
32492 F20101123_AAACBB manian_v_Page_023.QC.jpg
e9c9d2d28e99e37fc4882c073daebda7
1133d4f48a1abd1c354dc6c108d454d9d09cc2b0
5954 F20101123_AAACAM manian_v_Page_015thm.jpg
3b1e100e4df9952ca7c7c18efa6f9b8e
8706456cb3c8aae5b9bec0d4bb179256da50af54
34052 F20101123_AAABVH manian_v_Page_083.pro
5720b8317c9d67923ee364def8b5c7ea
38c5bc1428de5de715be32612a3e498c8b24b291
51140 F20101123_AAABUT manian_v_Page_064.pro
d7041462d6677e391371b50c373fdf07
08133b160d9c84cbf310d35842a04b9efa790a1e
27160 F20101123_AAACBC manian_v_Page_024.QC.jpg
72fa449e302555c67178c8a28b4625d8
6adff280003e0857e554168a9c70349641894941
22168 F20101123_AAACAN manian_v_Page_015.QC.jpg
13cc5299a5a1e5f263510bd2a3b7ca88
81a9e9eae70516cfacfc7cb28e87f7c0466f8bb6
31221 F20101123_AAABVI manian_v_Page_084.pro
94517ddf7f32ca19274555aa8579654b
f1b1ec50d6b357020274663e5243ef07d66ccc21
42884 F20101123_AAABUU manian_v_Page_065.pro
655910b1dd78d7fdb0ab9c96cb36f7cc
a5e3acf7a6490c1e134584b10fb4e5e21281652a
30799 F20101123_AAACBD manian_v_Page_025.QC.jpg
cead2ce6f056ccd2914e4d395cfda5bd
b8c41f94252e44b7872de894ee9dc894dc4363d3
3124 F20101123_AAACAO manian_v_Page_016thm.jpg
6857bbe5edcf05e85a250fbcb6bce6a1
228720238e7fa0448a906d08535c0d0d01013115
31383 F20101123_AAABVJ manian_v_Page_086.pro
4bdfa2ec4ee230023c4ba9c3277b163e
0e6c4e704164ea236c161f8848f65d885f233e71
44212 F20101123_AAABUV manian_v_Page_066.pro
53b440535b7ab2313886bc4d4d53c001
fd7a2edd66afe89a2633f2edfd3e72b52404c2d6
12869 F20101123_AAACAP manian_v_Page_016.QC.jpg
b23e33201f74beeb8e1eb438b3dc2232
af3b16e72120c69bda8cb64a19ca01563cf0e4b7
32041 F20101123_AAABVK manian_v_Page_087.pro
b3f096ca00b224eabf2f20fefc5aea27
514b8eb048a14431250e9e0f2a8d5266115268e7
40234 F20101123_AAABUW manian_v_Page_067.pro
35e99ce3dabdf68147d5460fd693f404
13ec0af842ff884a5aafe15755674ecefef2e97c
1391 F20101123_AAACBE manian_v_Page_026thm.jpg
82fa42b9b0e4812f5f9c283843da8972
c33071fd6ea4057b4ae9eec307a88beaff81212b
5717 F20101123_AAACAQ manian_v_Page_017thm.jpg
3baead07e2152b5d8f746f41817bb0c3
6f851a4a1c890970a61f8356dc6668caccbfb62f
29311 F20101123_AAABVL manian_v_Page_088.pro
d4ac8406eeaaab4a4bf45eb6f96bae3d
6c2864dc6cf614620437473c47d457cf7a2025d8
41657 F20101123_AAABUX manian_v_Page_068.pro
fcaf3021c6eb7650eadfe1bcfbd26b29
52c322096a68c63f7aa65c5e15027c3f84852d40
5088 F20101123_AAACBF manian_v_Page_026.QC.jpg
0bf8abc34822d24ad278f5727b3ba69f
1f66fe51a8f7909a1b1dcb7ec5031bd5ab1ff770
25201 F20101123_AAACAR manian_v_Page_017.QC.jpg
925bf6748c00dd36958cf2cfac7209cd
eaac78695c19cc8452ee1b13a40f34047773a144
34070 F20101123_AAABVM manian_v_Page_089.pro
946d6ef918a58a955f6a184ae8abec02
e7604a5c081a8e36c03110f37be7c1c60100a482
6170 F20101123_AAACBG manian_v_Page_027thm.jpg
147fcdffa0bf5325382630267340f53e
224aea3407e2925ac585b72d547cdc09c06214bb
22022 F20101123_AAABWA manian_v_Page_105.pro
01d39b29fa343dbbbf430314b1754d28
fd5c9ce59b2f94d15f5de5e46040ea7353b95dfc
26782 F20101123_AAACAS manian_v_Page_018.QC.jpg
dea23bf928d2734fa30e53b61fb64501
036ee36303d0c57535ef5b0f3400494f2bbed157
39802 F20101123_AAABVN manian_v_Page_090.pro
e69a08216d8a9f0129b402d6a5a4b633
fdb1d7967f9fef1719c441ab139dd33ccb214695
46556 F20101123_AAABUY manian_v_Page_069.pro
bbb2097a1ffa58bc1052d297144a5913
e98756193dff1b0499c1b9012fd7b646a25f6d0a
24868 F20101123_AAACBH manian_v_Page_027.QC.jpg
3c34400a9f66eb7607c4d953d2fc60d3
3b67a20977f40296915d8cedd859f2c7ce217044
91 F20101123_AAABWB manian_v_Page_002.txt
7fdf5fdbc77ed015c9304f1c392f2186
dffb790ab66923291d3dfa009794a51b35858b00
7646 F20101123_AAACAT manian_v_Page_019thm.jpg
5eed143fb0c17539e1e8ebb3b95f63aa
3fe7f40365b1e00f64d59073d7ea3206e13e696c
29748 F20101123_AAABVO manian_v_Page_091.pro
5832a3b7613eb999896debf3de9fd570
19cece02925252d7386cfe785c5ea09b4e477f22
42941 F20101123_AAABUZ manian_v_Page_070.pro
930cf245da7a7f18cc8fdee024175ff9
2097270c529a5e5005f1464907a7c855fd709ee9
7496 F20101123_AAACBI manian_v_Page_028thm.jpg
c45bfa60739021ab1c62a6bbd510b347
c999be5cf52eb2ffaf3b86fa019ed2caf26e13a0
665 F20101123_AAABWC manian_v_Page_003.txt
63073993520610e820a959a3a5869cbb
dfef0275e2d919e14ed185ae39e8943f97141148
32918 F20101123_AAACAU manian_v_Page_019.QC.jpg
eaf3fa9c4f2e8c22f3254d0d30bcfe01
382d34024721021d3d14cc3f387e4056bd055195
50076 F20101123_AAABVP manian_v_Page_092.pro
e58d6af33db965a6bbffae7420b81329
752f34bdd5e9a08616b4e0eeed17b4ca78dd257b
33123 F20101123_AAACBJ manian_v_Page_028.QC.jpg
3f9c0b8e96596961c3f73a7a5bdd3aba
3f98c9b33b626fac8a3466f3a850e92b582ea4aa
2181 F20101123_AAABWD manian_v_Page_004.txt
c61971c9a5d86ee9b59229a964c17cdc
50b269e03732ae8cbcec554ac1d39115058be6ee
27758 F20101123_AAACAV manian_v_Page_020.QC.jpg
26b9ed381aeece89d2a4c60236732baa
558c47097ce2056649cacf7626fa99dcd295e881
12500 F20101123_AAABVQ manian_v_Page_093.pro
dcfb52acecb08f47dc0db7e0fc02b332
be6b3600fa64718d8b5b3a12d68cca9e815b316a
5663 F20101123_AAACBK manian_v_Page_029thm.jpg
113e4f9a555c020ca6de054f0bf7afa1
7427bf1690f5692022c9e8292c57a1c9fcf24e91
2939 F20101123_AAABWE manian_v_Page_005.txt
a887afd765886b71ca6d3867270a7bb9
831f719c99653c48a7cf6c7454562d91c3150f39
3911 F20101123_AAACAW manian_v_Page_021thm.jpg
c958935ad7965e6dd967c32125436a27
ae57702d2c89ac2697bfe8452a4ead5f67ec83a8
42732 F20101123_AAABVR manian_v_Page_094.pro
ae586cd5b30d7a64b7a6ec6888b0e42f
f7885073d23bc3a0c2e93aae76d5e48bcc7a55dd
26195 F20101123_AAACCA manian_v_Page_038.QC.jpg
6471ed2d9aa23b5afb4e6758dbd737a1
a25347b9c8474fdb8288c3af09cf07f0a9bc9781
22490 F20101123_AAACBL manian_v_Page_029.QC.jpg
7a93edbd344e4f5420726f6df8e13dad
5f716b4d734a1ab30551feac947fd777a6db4603
781 F20101123_AAABWF manian_v_Page_006.txt
017dcf6fea18fe5cc6526ea6ee66679b
e2a2d4b9cbbb6bd0b14178d3f0f1121ab65b585d
13511 F20101123_AAACAX manian_v_Page_021.QC.jpg
5b7785346d64cc9cd3bd781ef8d9d9fe
c6dacbc70f1150800ada5d81a4f25064d1714bbf
54549 F20101123_AAABVS manian_v_Page_095.pro
316d38cce679ba8c74582ef513cd0e5d
9bfe8cbc5aaeca4d678e95ef883df7110436c08f
6971 F20101123_AAACCB manian_v_Page_040thm.jpg
7f67b069d545775fec6b0462d2c5bf8d
86651196d8b9af3cffa9d0b8271ec64e82d78dc0
7454 F20101123_AAACBM manian_v_Page_030thm.jpg
182acda69217c57689e15dd8e30918c7
9461385dd6de900eb358a8b9b73abe813d674ea4
514 F20101123_AAABWG manian_v_Page_007.txt
5915018a524724e4dd77ab64895eeb55
debe26e31ef2106d2ab36493f1bc3917bdbde354
7124 F20101123_AAACAY manian_v_Page_022thm.jpg
46364b74246f611a222c0c307733c794
92cc466bb7ce283d95b44cae8648c748681f5902
7550 F20101123_AAACCC manian_v_Page_041thm.jpg
b513e2f1c415c0d8a8669a1fedb53334
fd9d5f01f706f9208f4213d2dd86451abdaaccac
30310 F20101123_AAACBN manian_v_Page_030.QC.jpg
d9a8d413ce4ae83d4438d50588cf805e
a80067cd9ddf34796b8d193f6467c77565a18421
364 F20101123_AAABWH manian_v_Page_008.txt
0046937ceb8268396d031a5013299b45
b409d531abacbef28f44e36d5ec15ddc78e715bf
30629 F20101123_AAACAZ manian_v_Page_022.QC.jpg
d6571fcf414559397b542906b75c63c1
19fa6b9f4f41b227cfed42d9c3ee3b92b7c978fb
47867 F20101123_AAABVT manian_v_Page_096.pro
3c8d90f03628dd9ececf030df56265de
81ec154e8de2295e628969b558fd60e658acd353



PAGE 1

VOTINGENABLEDROLE-BASEDACCESSCONTROLMODELFOR DISTRIBUTEDCOLLABORATION By VIJAYMANIAN ADISSERTATIONPRESENTEDTOTHEGRADUATESCHOOL OFTHEUNIVERSITYOFFLORIDAINPARTIALFULFILLMENT OFTHEREQUIREMENTSFORTHEDEGREEOF DOCTOROFPHILOSOPHY UNIVERSITYOFFLORIDA 2005

PAGE 2

Idedicatethisworktomyparents,S.V.S.andPadmaManian.

PAGE 3

ACKNOWLEDGMENTS IwouldliketothankDr.RichardNewmanforgettingmestarte donthis project.IwouldliketoexpressmygratitudetoDr.SteveThe bautforhiswillingnesstohelpmewheneverIhadaproblem.Iwouldalsoliketoth ankalltheDCS groupmembers,pastandpresent,fortheirinvaluablecontr ibutionswithoutwhich Iwouldnothavebeenabletocompletethisdissertation. SpecialthanksareduetoSalilGokhaleforhelpingmestayon trackduringthe laststagesofmyPh.D.Finally,Iwouldliketothankmyparen tsfortheirsupport andencouragement. iii

PAGE 4

TABLEOFCONTENTS page ACKNOWLEDGMENTS.............................iii LISTOFTABLES.................................vii LISTOFFIGURES................................viii ABSTRACT....................................ix CHAPTER 1INTRODUCTION..............................1 1.1Motivation...............................2 1.2SampleScenario............................4 1.3OrganizationofthisDissertation.................. .6 2DCSOVERVIEW..............................7 2.1Introduction..............................7 2.2Defnitions...............................8 2.3ATypicalDayatWork........................9 2.4Services................................10 2.4.1CoGManager(CM)......................10 2.4.2NotifcationServices(NTF)..................10 2.4.3DatabaseServices(DBS)...................12 2.4.4DecisionSupportService(DSS)...............12 2.4.5AccessControlServices(ACS)................12 2.4.6SecureCommunicationsServices(SCS)...........13 2.4.7DistributedFileServices(DFS)...............13 2.4.8ApplicationManager(AM)..................14 2.4.9Tools..............................14 2.5InteractionWithOtherServices...................1 4 2.5.1InteractionWithDBS.....................15 2.5.2InteractionWithCM.....................15 2.5.3InteractionWithDSS.....................15 2.6Summary...............................15 3BACKGROUND...............................17 3.1Introduction..............................17 3.2AccessControl.............................17 iv

PAGE 5

3.3AccessMatrixModels.........................18 3.3.1HRUModel..........................19 3.3.2TypedAccessMatrix.....................20 3.3.3AccessControlinUNIXOperatingSystem.........23 3.4Role-BasedAccessControl(RBAC).................25 3.5DistributedCompartmentModel..................26 3.6AccessControlforCollaborativeEnvironments....... ....28 3.7TrustandVoting...........................30 3.8Summary...............................31 4THEDCS-ACMODEL...........................33 4.1Introduction..............................33 4.2TheDCS-ACModel.........................33 4.3Operations...............................36 4.4CommandsinDCS-ACModel....................39 4.4.1Constraints...........................41 4.4.2ExpressivePower.......................43 4.5Comparisonwithexistingmodels..................44 4.6FeaturesofDCS-ACModel......................45 4.6.1DecisionTemplates......................46 4.6.2DynamicTypeBinding....................47 4.6.3DynamicsetofAccessRights.................47 4.6.4DynamicsetofObjectTypes.................48 4.6.5FineGrainAccessControl..................48 4.7DCS-ACModelSolutionforSoftwareProjectExample.... ..49 4.8Summary...............................51 5SAFETYANALYSIS.............................52 5.1Introduction..............................52 5.2Defnitions...............................52 5.3AttributesofaState.........................54 5.4Proofs.................................55 5.5Summary...............................68 6TRUSTANDVOTING...........................69 6.1Introduction..............................69 6.2TrustandTrust-Worthiness.....................69 6.2.1ApproachingTrust.......................70 6.2.2DecisionTemplates......................72 6.3ARLProblemAndStates......................74 6.4TrustAnalysisofDCS-AC......................75 6.4.1StateGraph..........................75 6.4.2Ad-Approach..........................77 6.4.3Pay-As-You-GoApproach...................79 v

PAGE 6

6.4.4HonestPoliticialApproach..................80 6.5Summary...............................82 7NEXTSTEPS................................84 7.1EnhancingDCSCommands.....................84 7.2SpecialRelations...........................85 7.3RoleHierarchy.............................85 7.4Use-CasesandScenarios.......................86 7.5Multi-UserCollusionAttacks.....................8 6 7.6Time-LimitedAccess.........................87 8CONCLUSION................................88 REFERENCES...................................90 BIOGRAPHICALSKETCH............................95 vi

PAGE 7

LISTOFTABLES Table page 3{1PrimitiveOperationsinHRUmodel................... 19 3{2PrimitiveOperationsinTAMmodel................... 21 4{1ExampleofDCS-ACMatrixFragment..................3 6 4{2SpecifcationofDCS-ACOperations.................. .37 4{3DCS-ACSolutionforSoftwareProjectExample......... ...50 vii

PAGE 8

LISTOFFIGURES Figure page 1{1ClassLibraryScenario..........................5 2{1ArchitectureofDCS...........................11 4{1ComparisonofHRU,TAMandDCS-ACmodels............44 viii

PAGE 9

AbstractofDissertationPresentedtotheGraduateSchool oftheUniversityofFloridainPartialFulllmentofthe RequirementsfortheDegreeofDoctorofPhilosophy VOTINGENABLEDROLE-BASEDACCESSCONTROLMODELFOR DISTRIBUTEDCOLLABORATION By VijayManian December2005 Chair:RichardE.NewmanMajorDepartment:ComputerandInformationalSciencesand Engineering Thisdissertationpresentsavotingenabledrole-basedacc esscontrol(RBAC) modeldesignedfordistributedcollaborationthatallowst hegrouptodecideand implementgrouppolicies.Thismodelcanalsobeusedinmany middle-level systemsthatrequiresupportforgroupvoting.Theprimaryg oalsofthismodel aresecurity,scalability,rexibilityandsimplicity.One ofthemajordrawbackswith manymodelsinusetodayistheneedforanexternaladministr atororauserwith \god-level"powerstoimplementthegrouppolicies.Weover comethisbyallowing subsetsofuserstovoteonaccesscontroldecisionsthatare deemedimportant. Thistakestheburdenofgroupmanagementfromthesystemadm inistratorsand allowsthegrouptobetrulydemocraticandautonomous.Inth isdissertation,we givethemotivationforthemodel,formallydeneitandgive anexampleofhow itcanbeused.Wealsodenetheaccessrightleakageproblem whichweuseto analyzethesafetyofthemodel.Werstprovethatforasimpl eversionwithout anyvoting,theaccessrightleakageproblemcanbedecidedi npolynomialtime. Wethenintroducethenotionof trust-level anddiscusshowthetrust-levelof theusersaectthesafetyofthesystem.Thisdissertationi dentiesthreesimple ix

PAGE 10

approachesbywhichamaliciousentitycancausegroupmembe rstovoteina mannerthatisnotinthebestinterestofthegroup.Wethenan alyzethesafetyof themodelundereachofthesethreeapproaches. x

PAGE 11

CHAPTER1 INTRODUCTION Distributedcollaborationismorethanjustabuzzwordinto day'sworld. Mostusersloginfromlargenetworks,andoftentimes,theco llaboratorsarefrom dierentadministrativedomains.Insuchascenario,acces scontrolcanbecome anadditionalburdenonthealreadyoverworkedadministrat orsandusuallyis dicultwithoutenforcingmanyrestrictions.Onastand-al onemachine,access controlismoreorlessstraightforwardwiththeoperatings ystemprovidingsimple discretionaryaccesscontrol(DAC)mechanismslikeaccess controllists(ACL)or capabilitylists(CL).Mostofthesemechanismsarebasedon theaccesscontrol matrix(ACM)model[1,2].Variousmodelshavebeenproposed formulti-user systemsandthesemodelsaredenedwithwell-knownabstrac tionslikesubjects, objectsandaccessrights. Therearesomemajordisadvantagestothecurrentmodelswhe napplied todistributedenvironmentsingeneralanddistributedcol laborativesystemsin particular.Mostsystemstodayarerunoverthenetworkandh aveacentralized nodetohandleaccesscontrol,whichresultsinasinglepoin toffailureandmore importantly,asingleadministrativeauthority,whichisn otalwaysdesirable.Many practicalmodelsrestrictthetypesofaccesses(forexampl e,Unixhasonlythree types:read,writeandexecute),whichdoesnotrerectreall ife.Inaddition,each objectinthesystemcanhaveonlyoneowner,whichmightnotb ethecaseina collaborativeenvironment.Someofthemajorproblemswith classicalmodelsare discussedinsection1.1. TheDistributedConferencingSystem-AccessControlModel (DCS-AC) discussedinthisdissertationhasbeendesignedtoprovide asimple,powerful, 1

PAGE 12

2 implementable,scalableandrexibleaccesscontrolmechan ism.Oneofthemost importantfeaturesofthismodelistheuseofgroupdecision -makingmechanisms (voting)asapartoftheaccesscontroldecisionprocess.He re,importantaccess controldecisionscanbereferredtoavoteamongaspecieds ubsetoftheusers, therebyallowingthemtoself-administerthegroups.Manyc urrentmodelsrely ona\superman"whocandoalmostanythinginthesystem.TheD CSapproach modelssocietymorecloselyandalsoprotectsthesystemaga instmalicioussingleuserattacks. WeanalyzethesafetyofthemodelintermsoftheAccessRight sLeakage (ARL)problem.ARListheproblemofdecidingwhetheramalic iousentitycan executeasetofcommandswhichresultinanunauthorizeduse rgainingaccessto anobjectinagivenDCS-ACinstance.Weapproachthisproble mbyrstsolving itforasystemwithnovoting.Whenthesubjectsareallowedt ovoteononeor moreaccesscontroldecisions,itisdiculttodecideonaye sornoanswer.We assignatrust-levelvaluetoeachsubjectanddecideonthea nswerintermsof thetrust-levelsofallthesubjectswhocanparticipateint hevote(s).Letusnow considerwhyweneedtheDCS-ACmodel. 1.1 Motivation Mostaccesscontrolsystemsinusetodayarebasedonthetrad itionalaccesscontrolmatrixmodel. 1 Thisproposalconsidersaccesscontrolpoliciesina distributedcollaborativeenvironmentwherethetraditio nalmodelssuerfrom thefollowingproblems(afewmoreproblemswithcurrentsys temsaregivenin Greenwald[3]). 1 ACLandCLcanbeconsideredtobeapartofthetraditionalacc esscontrol matrixmodel

PAGE 13

3 1.Systemadministratorsareusuallyoverworkedandunderp aid.Acentralized serverthatcoordinatestheentiredistributedsystemwill notworkwell. 2.Ifthreesubjectsarecollaboratingonadocument,undert hecurrent paradigm,anyoneofthesethreecanunilaterallydeletethe object.This isnotdesirableandamoreusefulpolicycouldbetorequirea tleasttwoof theauthor'sapprovalinordertodeletetheobject. 3.Itisdiculttoobtainaccesstoobjectslocatedinadier entadministrative domainwithoutgettingthelocalsystemadministrator'spe rmission. 4.Eveninsystemsthatarespecicallydesignedfordistrib utedcomputing[4], likegridcomputing,thestandardpolicyisforeachdomaint oberesponsible fortheobjectsinitssite[5].Now,ifAliceaccessesanobje ctfromanother administrativedomain,acopyoftheobjectisusuallycache d.Thelocal systemhasnoideaabouttheaccesscontrolpoliciesofthiso bjectandwhen Bobrequestsaccesstothesameobject,therequestisforwar dedtotheother domain.Ifthelocalsystemwereawareoftheaccesscontrolp oliciesforthe object,itcouldhavemadethedecisiononitsownandsavedBo balotof time. 5.Theindividualgroupsofcollaboratorscannotsettheiro wngrouppolicies. TheDCS-ACmodeladdressestheseissuesandprovidesaveryr exibleaccess controlmechanism.ThismodelwasdevelopedforDistribute dConferencingSystem (DCS)[6],adistributedcollaborativearchitecturethata llowsusersfromdierent sitestoworktogether.TherstobjectiveoftheDCS-ACmode listoprovide rexible,implementableandfaulttolerantaccesscontrol. Thesecondobjectiveis toallowtheusersofthesystemtoself-administertheacces sprivileges,i.e.,allowa subsetofusers(whoareoftenthestakeholders)tomakeacce sscontroldecisionsfor importantobjectsonacase-by-casebasis.Thisisdonebyus ingasetofdecision templateseachofwhichdenesthesubsetofusersthatcanpa rticipateinavote. EachentryintheACMhasadecisiontemplatepointerwhichha stobeexecutedinordertoarriveatadecision.Althoughthemodelenf orcesnoconstraints onwhichdecisionsrequireavote,weexpectthatmostentrie swillpointtothe Always-yes templatewhichalwaysreturnsa yes sincemanyrights,oncegranted,

PAGE 14

4 neednotbereferredtothevotinggroupforeveryaccess.How ever,forimportant accesscontroldecisionsthesystemcanreferthedecisiont oasubsetoftheusers whovoteonit.Thisallowstheuserstoexpressaccesscontro lpoliciesforsome accesses(likejoiningthegroup,accessingimportantobje cts,grantingaccessrights, etc.)inthesystem. Theuseofdecisionpointersalsoimprovesfaulttolerance. Itprotectsagainst singlemalicioususerthreats,sincemanyusersmayhavetoa greeforthevote topass.Inaddition,ifsomeoftheusersareunavailable,th esystemcanstill takedecisionsbasedontheusersavailable(unlessthesyst empolicyspecically statesthataparticularusermustagreeforthevotetopass) .Therearemany real-lifescenariosinwhichsuchmulti-userauthorizatio nsarerequiredandareoften handledo-linebeforeoneoftheparticipants\informs"th esystemiftherequestis approved. 1.2 SampleScenario Considerthefollowingexampleofaprojecttobeimplemente dbyateam consistingofa projectleader (PL)andmanysubordinates( architect s, programmer s and tester s).The architect sworkonthedesignandoncethedesignisapproved bythePL,oneormore programmers codetheproject,whichisthentestedby the tester s.Thetesterscaneithersenditbacktotheprogrammersalon gwitha bug-listornotifythePLthatthecodeisacceptable.ThePLt henreviewsthecode withthereviewteam,andifapproved,theprojectisrelease dtotheclient(referto Figure1{1). Givenbelowareafewcompanypoliciesapplicable. 1.Theindividualsconcernedmaybelocatedindierentbran ches;condentialityandavailabilityareimportantforthesharedobjects. 2.Thearchitectdoesnotneedaccesstothecodeandtheteste rcanlookatthe codeonlyaftertheprogrammersareready.

PAGE 15

5 to client Code released Problem Statement Design Document Bugs-ListCode Code Tester Team Review Programmer Architect PL Figure1{1:ClassLibraryScenario 3.ThereviewteamconsistsofallPLsinthecompanyandtheme mbersdonot haveaccesstothecodeuntilitpassesthetestingphase. 4.ThePLcanaccessanydocumentrelatedtothisparticularp rojectatany pointoftime. 5.ThePLalsodecideswhoworksonthisproject.6.ThePLcannotchangetheroleofanemployee;forexample,t hePLcannot assignaprogrammertodothetaskofanarchitect. 7.Therearemanyarchitects,programmers,etc.inthecompa ny,andonlythose involvedindevelopmentshouldhaveaccesstotheobjects. 8.Theprogrammersdoaninternalreviewandsendthecodetot hetestersafter everyprogrammerhasapprovedit. 9.Thereviewteammembersvoteonwhetherthecodecanbeadde dtothe library. ThersteightrequirementscanbehandledbyRBACinastraig htforwardmanner usingconstraints.However,specifyingconstraintsintro ducesruntimeoverhead [7].Requirementseightandnineinvolvegroupdecisions.A lthoughtheabove exampledealswithasimplisticscenario,webelievethatth erearemanyexamples

PAGE 16

6 thatinvolvesimilarissues.TheDCSmodelisdesignedtohan dlescenariosofthis nature. 1.3 OrganizationofthisDissertation Chapter2givesabriefoverviewoftheDistributedConferen cingSystemand chapter3providesthetechnicalbackgroundfortheDCSacce sscontrolmodel. Chapter4dealswiththeformaldenitionoftheDCSModeland discussesthe featuresoftheDCSmodel.Chapter5discussesthedecidabil ityoftheARL problemfortheDCS-ACmodelwithoutvotingandchapter6dis cussestrustin votersandthetrustworthinessofaDCS-ACsystemwherevoti ngisallowed. chapter7mentionssomefuturedirectionsofresearchandch apter8concludesthis work.

PAGE 17

CHAPTER2 DCSOVERVIEW 2.1 Introduction Intoday'shighly-networkedworkingenvironment,support forcollaboration andgroup-workhasbecomecritical.Theavailabilityoflow -costWideArea Networks(WANs)meansthatmembersofagroupcanbegeograph icallyscattered aroundthecountry(oreventheworld).Thereisagrowingnee dforecient architecturesandapplicationsthatfacilitatecollabora tionbetweensuchmembers. Asystemthatallowsuserstologonfromdierentlocations, toshareobjects,and toworkonthesameobjectwithothermembersofthegrouphasb ecomeessential insuchcases. TheDistributedConferencingSystem(DCS)seekstofulllt heserequirements andmanymore.Thesystemisbasedonarobustarchitecturean dprovides distributedleservices,accesscontrol,securecommunic ation,noticationand groupdecision-makingmechanisms.TheDCSwillprovidebas icdistributed collaborativeapplicationsliketexteditors,graphicsed itors,etc.,andcanalso supportthird-partyapplications.Thescalablearchitect urecansupportmultiple sitesandobjectscanbereplicatedtoensurefasteraccessa ndavailability.One ofthemajordesigncriteriaisfaulttolerance.Thesystemi sdesignedtohandle networkfailuresandsystemcrashesbyrestoringfrombacku psandcontacting othersitesforthemostup-to-dateinformation.Weachieve thisbyreplicating theobjectsacrossmultiplesitesandalsobymeansofbackup serversforeachsite whichcantakeoveriftheprimaryserverfails. 7

PAGE 18

8 2.2 Denitions BeforegettingintothedetailsofDCSandthevariousservic esprovided,we rstdenesometermsthatarerequiredtounderstandthearc hitecture: DCSinstance ThisisacollectivetermforoneormoreDCSsitesthatshare resources,communicateDCSspecicinformationwithandst oreinformation abouteachother.AnyuseridorCoGregisteredatonesiteisa ccessible fromallsitesinthatDCSinstance.AninstanceofDCSmaycov ermultiple administrativedomains. Site ThistermreferstotheDCSserver(s)locatedinasingleadmi nistrative domainthatprovideservicestotheusers.Sitesthatareapa rtofthesame DCSinstancecancommunicatewitheachother. Collaborativegroup(CoG) Thistermreferstoapersistentortransient groupconsistingofmembers,objects,applications,andaD CS-ACsystem (consistingofroles,objecttypes,allowablemember-role bindingsanddecision templates).ThemembersofaCoGworktogetherontheobjects anddecide grouppoliciesforthatCoG. User Thisisanentityinthesystemthatinitiatesactionand(int hecontext ofaccesscontrol)requeststoaccessobjects.Thistermusu allyreferstoa humanbeing. Member ThistermwhenusedinthecontextofaCoGreferstoauserwho isapartoftheCoGandhasbeengrantedrightsthatarenotgra ntedto non-members. Subject Thisrepresentsanactiveuserprocessthatisallowedtoper form someactionwithinthesystemonbehalfoftheuser. Object Thisisapassiveentityinthesystem.Userscanperformvari ous accessesonthem.Examplesofobjectsaredocuments,lesan dDCSsystem specictables. Application Thisisaprogramthattheuserlaunchesfromwithinthesyste m toworkontheobjects. Collaboration-ware Theseareapplicationsthataredesignedtosupport collaborativework.Thereforetheseapplicationswillhav eabetteraccess controlfeaturesthantheregularo-the-shelfapplicatio ns.

PAGE 19

9 DCS-awareapplications Theseareapplicationsthatarespecicallydesigned toworkwithintheDCS.Theseapplicationscanusethefeatur esofDCSlike eventnoticationornewaccesstyperegistration. Role Thisisanamedgroupofsubjects.Rolescanalsobeviewedasa collectionofjobfunctions.Aparticularsubjectcanbindt oanynumberof rolesbutatanypointoftime,thesubjectcanbeboundtoonly onerole.It mustbenotedthat role asusedhereisslightlydierentfrom role asusedin Role-basedaccesscontrolbecausethereisnonotionofarol e-hierarchyinthe DCSmodel. Objecttype Thisisanamedgroupofobjects.Aparticularobjectcanbelo ng toonlyoneobjecttype. 2.3 ATypicalDayatWork AtypicalinstanceofDCSconsistsofmanysitesandeachsite consistsofa primaryserverwithoneormorebackupservers(whichareran kedfrom1to n where n isthenumberofbackups)toensurehighavailability.Thepr imaryserver sendsperiodic heartbeats andupdatestothebackups[8].Ifthebackupsdonot gettheheartbeatfromtheprimaryforaxedamountoftime,t helowestranked backuptakesoverastheprimaryandinformstheothersitesi ntheinstance. Similarly,thesitesexchange heartbeats andifasitedoesnotrespond,theother sitescantakeoverthemanagementofobjectscontrolledbyt hefailedsite. Eachsitecontributesresources(likediskspace)totheins tanceandallobjects arepartiallyreplicatedtoprovidefaulttolerance.TheDC Sarchitectureisdivided intovariousmoduleseachofwhichprovidesadierentservi cetotheusers(section 2.4).AuserlogsintoaCoGthroughasiteandisboundtoarole (basedonthe user-rolebindingsmaintainedbytheAccessControlServic es).TheDistributed FileServicesprovidesauniformviewofthe DCSspace ,whichactuallyconsistsof objectslocatedondierentsites.Theusercanlaunchappli cationstoaccessthese objects,participateindecisionmakingprocessesorinter actwithothermembersof theCoG.Itmustbenotedthatsitearemanagedinthesamewaya sCoGs.That is,Oneachsite,thereisaCoGcorrespondingtothesitecont ainingallsubjects

PAGE 20

10 whojoinedtheDCSinstancefromthatsite;theycanformandi mplementtheir ownsitemanagementrules.Thefollowingsectionprovidesa briefdescriptionof thevariousservicesandtoolsavailableinDCS. 2.4 Services ThearchitectureofDCSv.2isshowningure2{1.Itisbasedo nvarious servicesavailableinmostnetworkeddomains(likelocall esystems,TCP/IP, cryptographicpackages,databasesystem,etc.).Sincewea reusingJava[9,10],the sitesneednotallrunthesameoperatingsystem.Abriefdesc riptionofthecore servicesisgivenbelow. 2.4.1 CoGManager (CM) Thisisthemoduleresponsibleformanagingthecollaborati vegroups(CoGs) [11].Thismoduleinstantiatestheothermodulesandthecli entsinteractwiththe otherservicesmainlythroughtheCM.Taskslikemergingtwo instancesofDCS orsitesorCoGs,andsplittinganinstance,asite,oraCoGis handledbythis module.TheCMinteractswiththesecuremessagingandthecr yptographiclayers duringuserlogin.Theuser'saccesscontrolrequestsarero utedthroughtheCM. TheCMalsoallowstheusertoimportandexportobjects,addn ewmembersand startsub-groups(sub-CoGs). 2.4.2 Notication Services (NTF) TheNTF[12]providesasynchronouseventnoticationtoreg isteredusers. Userscandeneneweventtypesandregistertobenotiedone vents.Subjects areautomaticallyregisteredfornoticationiftheyaream ongthevalidvoters onadecision.Thevariousservicesandapplicationsrunnin gintheinstanceraise eventsasandwhentheyoccurandtheNTFmaintainsaglobalan dlocaldatabase inwhichitstorestheuserstobenotiedoneacheventalongw iththedelivery method.

PAGE 21

11 ACS NTF MACE, A/V sharing, Whiteboard Applications Group Multicast AMCMDSS DBS SCS OS FS DFS A A DBMS JDBC UDP TCP RMI Crypto Secure Messaging Site Messaging Figure2{1:ArchitectureofDCS

PAGE 22

12 2.4.3 Database Services (DBS) TheDBS[13]makesuseofabackendDatabaseManagementSyste m(DBMS) [14]tomaintainthetablesofalltheDCSservicesandapplic ations.Mosttables arestoredaspartiallyreplicateddistributeddatabases. TheDBSusesgroup multicastandensureseventualconsistencyamongallmembe rsitesbyusingvector timestamps.SinceDBSusesJavaDatabaseConnectivity(JDB C)[15],wecanuse anybackendDBMSsystemlikeMySQL[16]orPostgreSQL[17]. 2.4.4 Decision Support Service (DSS) DecisionSupportSystem[18]isamodulethatfacilitatesre solvingissuesbya groupofuserswhohaveajointresponsibilitytosuchdecisi ons.Votingisoneofthe toolsofDSSwhichisdesignedtobearexibleandfriendlysys temthatallowsusers toinitiate,participateinandterminatedecisionswithin thecontextofaCoG.It provideson-linevotingandhasautomatedvotecollectionm echanisms.Itallows memberswhoarecurrentlyo-linetobevotersinadecisionp rocess.Theinitiator ofthevotecansettimeconstraintsandspecifyvotingparam eters,voters,reporting stylesandreportrecipients. Thisservicetakesintoaccounttheuser'srole,weightassi gnedtothevoteand accessrights,etc.Ithasseveralfeatureslikereminders, requestforstatus,change ofvote,shortcircuitevaluation,withdrawalandterminat ionofactivevotes,which addmorerexibilitytothedecisionprocess.Italsoallowso thermodulesofDCSto maketheserequests. Themodulesupportsdierentvotingmethodslikemajority, plurality,and ranking.Userscansavetheirrequirementsastemplatestha tcanbereusedinthe futurebyanyonewhohastheaccessrightstodoso. 2.4.5 Access Control Services (ACS) TheACS[19],asthenamesuggests,controlsaccessto(CoG-s pecicor instance-specic)objects.Itmakesuseofdecisiontempla tesoftheDSStoprovide

PAGE 23

13 groupdecision-basedaccesscontrol.Thisputsthecontrol oftheCoGinthehands ofthemembers.TheACSstoresitstablesinadatabasethroug htheDBS.The ACSallowsapplicationstoregisternewaccesstypes.Thisa llowsmorene-grain accesscontroliftheapplicationsupportsit. TheACSinteractswithalltheothervemodulesandprovides various servicestotheusers.TheDCSarchitecturerequirestheACS toallowdecisions tobemadeonaccesscontrolrequestsatthesourcesiteitsel f.Thiscoupledwith thedecisiontemplatesmakestheACSaninterestingstudyin itself.Themodel usedhereisnotspecictoDCSandcanbeusedinanydistribut edsystemthat supportsgroupdecision-makingmechanisms. 2.4.6 Secure Communications Services (SCS) TheSecureCommunicationServices[20]ensurestheconden tiality,authenticityandintegrityofallmessagespassedbetweensitesandcl ients.Toenforcethese importantsecurityproperties,itisnecessarytoestablis htheidentityoftheentities ofthesystem.Theentitiesofthesystemareusers,hosts,an dservers.Theidenticationoftheentitiesshouldbedonereliably,thatis,its houldbeauthenticated. DCSposesagreaterchallengesinceentitiescommunicateth roughmessagesand hencealltheentitiesmustestablishtheiridentitiesandm aintaincondentiality.In DCS,identityisrstestablishedusingstrongauthenticat ionandper-connection symmetriccryptographyprovidescondentialityandinteg rity.TheSCSisalso responsibleforcreationandmaintenanceofkeysandcerti catesforsitesandusers. 2.4.7 DistributedFileServices (DFS) TheDistributedFileServices[21]providesaDCS-specicv iewoftheobjects locatedatvarioussites.Itallowsconcurrentaccessofle susingaversioning schemewithimmutablesharedlesandisdesignedtoprovide reasonableservice inthecaseofsitecrashes.EachCoGisrepresentedbyadirec toryin DCS-space andsub-CoGsaresimplysub-directoriesunderthedirector ycorrespondingtothe

PAGE 24

14 parentCoG.TheDFScreatesandmaintainsmultiplecopiesof allobjects,thereby ensuringhighavailability. 2.4.8 ApplicationManager (AM) TheApplicationManagerisresponsibleforregisteringand invokingapplicationsthatareavailableforeachCoG.Theseapplicationsco uldbeDCS-aware(like MACE[22])orDCS-unaware.TheAMmaintainsalistofapplica tionsavailablefor aparticularCoG,anddependingontheaccessrightsoftheus er,itmakesthose availabletotheusers. 2.4.9 Tools TheDCSframeworkprovidesafewbasictoolsforcollaborati on.Theseinclude instantmessaging(Gossip),concurrenttext(MACE)andgra phics(Ensemble) editors. Gossip Thisisasimpleinstantmessagingapplicationthatisapart ofthe clientGUI.Itallowstheusertobeintouchwithhis/hercoll aborators. MACE MACE[22]standsforMotherofAllConcurrentEditorsandis averypowerfulconcurrenttexteditor.Inadditiontoregul artexteditor features,MACEallowsuserstolockvariouspartsoftheles andshareviews. MACEprovidesaveryne-grained(byte-level)lockingmech anismandthe usercansettheviewrightsforothers,i.e.,theotherusers canseeeverykey strokeorreceiveupdatesonlywhenthewritercommitsthech anges.This allowsotherusersto\lookovertheshoulder"ofthewriter( usefulinpair programmingamongotherareas). Ensemble Ensembleisaconcurrentgraphicseditorsthatprovidesobj ectlockingandspecicuserpointerview.Multipleuserscanwo rkonthesame gureandeachusercanlockoneormoreobjectsandsharecurs or,allowing otheruserstoseeexactlywhatisgoingon. 2.5 InteractionWithOtherServices SinceweareprimarilyconcernedwiththeACS,whichimpleme ntstheDCSACmodel,letuslookatACS'interactionswiththeotherserv ices.Asmentioned

PAGE 25

15 earlier,ACSinteractswithallthecoreservices.Outofthe se,DBSandDSS providevitalservicesrequiredforACS. 2.5.1 InteractionWithDBS AllACSinformationaboutaCoGarestoredasrelationaldata basetablesthat arereplicatedacrossallsitesinterestedintheCoGbyDBS. WhenanewCoGis created,therelevantACStableshavetobecreatedontheloc alsite.Whenever asitewantstoparticipateinaCoG,itobtainsadumpoftheAC Stablesfrom asitethatisalreadyintheCoGandcopiesitontothelocalda tabase.Any databasequerycanbehandledbytheDBMSatthelocalsitebut updateshaveto beforwardedtothesitethat\owns"theentryandthenmulticasttoothersites. 2.5.2 InteractionWithCM TheCMcontrolstheentireconferenceandinstantiatestheo bjectsthat providetheservicesincludingACS.Moreover,mostuserreq uestsarepassedonto theACSthroughtheCM.MostCM-originatedactionshavetobe checkedthrough theACSforaccessprivileges.Forexample,ifauserwantsto importanewle,the CMwillhavetocheckwiththeACSbeforeproceedingwiththei mport. 2.5.3 InteractionWithDSS TheDSShandlesthedecision-makingprocessandistherefor ecloselytiedto theACS.Ifarequestrequiresavote,theDSShastobeinvoked andthevoting processinitiated.TheACSmustbeabletocheckthestatusof aparticularvote. Whenavoteiscompleted,theDSSshouldnotifytheACS.Simil arly,theACS mustbeabletoreportalistofactivevotestotheDSSiftheDS Sdecidestodelete obsoletevotes.Actionslikedeningnewtemplatesandmodi fyingexistingones requireacheckbytheACS. 2.6 Summary Thecoreservicesdescribedhereprovideaframeworkfordis tributedcollaboration.Thethreetoolsmentionedarewhatweconsidermini malapplications

PAGE 26

16 requiredbycollaboratingusers.TheApplicationManagera llowsuserstoexecute otherapplicationsfromwithintheDCSframework.Aswillbe comeclearinthe nextchapter,DSSisrequiredbytheDCS-ACmodelsinceithan dlesallvoting relatedissues.

PAGE 27

CHAPTER3 BACKGROUND 3.1 Introduction Thischaptersurveyssomeoftheworkinaccesscontrolandtr ustinvoters thatisrelevanttotheDistributedConferencingService-A ccessControl(DCS-AC) model. 3.2 AccessControl Protectionofobjectsiscomplexbecausethenumberofacces spointsmaybe large,theremaybenocentralauthoritythroughwhichallac cessrequestspass, andthekindofaccessisnotsimplylimitedtoread,write,or execute.Accordingto Preeger[23],thereareseveralcomplementarygoalsinsuch amechanism. Checkeveryaccess .Wemaywanttorevokeauser'sprivilegetoaccessan object.Ifwehavepreviouslyauthorizedtheusertoaccesst heobject,wedo notnecessarilymeantheusershouldretainindeniteacces stotheobject. Allowleastprivilege .Asubjectshouldhaveaccesstothesmallestnumber ofobjectsnecessarytoperformsometask.Notallowingunne cessaryaccess toobjectsguardsagainstsecurityweaknessesifapartofth eprotection mechanismshouldfail. Verifyacceptableusage .Thenaldecisiononanaccessrequestisayes-no decision.Ofmoreinterestischeckingthattheactivitytob eperformedonan objectisappropriate. AccesscontrolpoliciesarebroadlyclassiedasMandatory AccessControl (MAC)andDiscretionaryAccessControl(DAC).MACmeanstha taccesscontrol policydecisionsaremadebeyondthecontroloftheindividu alownerofanobject. Acentralauthoritydetermineswhatinformationistobeacc essiblebywhom,and theusercannotchangeaccessrights[23].Aclassicexample ofMACisinmilitary 17

PAGE 28

18 securitywheretheownerofa\top-secret"objectcannotdec idewhohastop-secret clearancenorcantheownerchangetheclassicationoftheo bjectto\secret". ExamplesofmodelsthatenforceMACincludeBell-LaPadulaC ondentiality model[24]andBibaIntegrityModel[25].DAContheotherhan d,allowsthe ownerofanobjectoranyoneelsewhoisauthorizedtocontrol accesstotheobject tospecifywhohaswhataccesstotheobject.Theaccessright sinaDACscheme canchangedynamically[23].Oneofthemaindierencesbetw eenDACandMAC isthefactthatMACisalsoconcernedwiththerowofinformat ion[26]. Inthiswork,wearemainlyconcernedwithDACsincewewantth eusersto beabletodecidetheirownaccesscontrolpolicieswithouta nycentralauthority. Inthefollowingsectionswelookatvariousprotectionmech anisms.Firstwewill considertheAccessMatrixmodel.Wealsodescribecertainm odicationslike AccessControlListsandCapabilitylistsalongwiththeGra ham-Denningand Harrison-Ruzzo-Ullmanmodels,whichareallDACmodels.Ne xtwewillreview rolebasedaccesscontrol,andtheDistributedCompartment Modelforresource managementandaccesscontrolproposedbyStevenGreenwald .Finally,wewill lookatrecentworkonaccesscontrolforcollaborativeenvi ronments. 3.3 AccessMatrixModels Accesscontrolmatrices arethemostpopularmeansofmodelinganaccess controlsystem.Anaccesscontrolsystemhasagroupofusers ,objectsandaccess rightsforthoseusersonthoseobjects.TheHRU[27]andGrah am-Denning[2] modelsareearlyexamplesofsuchmodels.Suchsystemshavea setofcommands thattestthepresenceofvariousrightsinthematrixandthe nexecuteasequence ofoperations.Mostmodernsystemsuseavariationoftheacc esscontrolmatrix likeaccesscontrollistsorcapabilitylists.Accessright sleakageisaninteresting propertyofaccesscontrolsystems.Oneofthemanymeansofa nalyzingamodelis totrytoclassifytheleakageproblemforthatmodel.

PAGE 29

19 Table3{1:PrimitiveOperationsinHRUmodel enter r into( X s ;X o ) delete r from( X s ;X o ) createsubject X s createobject X o destroysubject X s destroyobject X o 3.3.1 HRUModel Harrison,RuzzoandUllmanproposedamodelin1976thatispo pularly referredtoastheHRUmodel[27].AHRU protectionsystem consistsofastatic, nitesetofrights R ,andastatic,nitesetofcommands, C .Therearesix primitiveoperationsdenedwhicharegiveninFigure3{1.A conguration ofa protectionsystemisatriple( S;O;P ),where S isthesetofsubjects, O istheset ofobjects, S O ,and P isarightsmatrix,witharowforeachsubjectanda columnforeachobject. P [ s;o ]( R )givestherightstotheobject o possessedby thesubject s .Theformaldenitionofthemodelisasfollows: Denition: A protectionsystem consistsofthefollowingparts: 1.anitesetof rights;R 2.aniteset C of commands oftheform: command ( X 1 ;X 2 ;:::;X k ) if ( r 1 2 ( X s 1 ;X o 1 )) ^ ::: ^ ( r m 2 ( X sm ;X om )) then op 1 :::op n end Hereeachsubjectorobject X si or X oi isoneoftheparameters X j andeach operation op i isoneofthe primitiveoperations giveninTable3{1. AccessrightLeakWhilewecannotexpectausefulsystemtobesafeinthestrict estsense,the minimumtolerablesituationisthattheusershouldbeablet odecidewhethera

PAGE 30

20 givencongurationcouldleadtosomeotherusergettingasp ecicright,i.e.,if theright leaks tootherusers[27].Needlesstosay,therearesomeuserswho mwe trustandinfactexpecttohavetheright.Weremovetherowsc orrespondingto thoseusersandtrytondoutiftherightleakswhensomesequ enceofcommands isexecuted.Theformaldenitionofthesafetyquestionfor accesscontrolsystems isgivenbelow:Denition Givenaprotectionsystem,wesayasequenceofcommands 1 ; 2 ;:::; n leaksaright fromastartingstateQ ifthecommandswhenrunon Q (insequence),canexecuteaprimitiveoperationthatallowssome usertheright that wasnotallowed Q Inotherwords,asystem leaksaright ifandonlyifitispossibleforan unintendedsubjecttogettheright onanobject o bytheexecutionofasequence ofcommands.Theauthorshaveprovedthatthesafetyquestio n(alsocalledaccess rightleakageproblem)isgenerallyundecidablefortheHRU model.Itisinteresting tonotethatifweenforcethemono-operationrestriction,i .e.,eachcommandcan executeonlyoneoftheprimitivecommands,thenthesafetyq uestionforsucha systemisNP-complete.However,mostusefulHRUsystemscan notsatisfythe mono-operationrequirement. TheTypedAccessMatrix(TAM)model[28],[29]addsstrongty pingtothe HRUmodel.TheaccessrightsproblemforthegenericTAMmode lhasbeen proventobeundecidablebuttherearecertainrestrictedve rsionsofTAMforwhich theproblemhasbeenproventobeNP-Hard. 3.3.2 TypedAccessMatrix RaviSandhuandothershaveworkedonmodifyingtheHRUmodel tomake thesafetyproblemdecidablewhileatthesametimemaximizi ngtheexpressing power[30].TheTypedAccessMatrix(TAM)[28]denedbySand hucombines strongsafetypropertiesforpropagationofaccessrightso fSchematicProtection

PAGE 31

21 Table3{2:PrimitiveOperationsinTAMmodel enter r into [ X s ;X o ] delete r from [ X s ;X o ] createsubject X s oftype t s deletesubject X s createobject X o oftype t o deleteobject X o Model[31]withthenaturalexpressivepoweroftheHRUmodel .TAMisobtained byincorporatingstrongtypingintotheHRUmodel[29].Itis importantto understandthatthetypesandrightsarespeciedaspartoft hesystemdenition. Thesystemadministratorspeciesthefollowingsetsforth ispurpose: anitesetofaccessrightsdenotedby R ,and anitesetofobjecttypesdenotedby T The protectionstate isaTAMsystemisgivenbythefour-tuple( OBJ SUB t AM )interpretedasfollows: OBJ isthesetofobjects. SUB isthesetofsubjects, SUB OBJ t : OBJ T ,isthe typefunction whichgivesthetypeofeveryobject. AM istheaccessmatrix.Wehave AM [ S;O ] R where S isasubjectand O isanobject. TheprotectionstateofthesystemischangedbymeansofTAMc ommands.Each TAMcommandhasthefollowingformat: command ( X 1 : t 1 ;X 2 : t 2 ;:::;X k : t k ) if r 1 2 [ X s 1 ;X o 1 ] ^ r 2 2 [ X s 2 ;X o 2 ] ^^ r m 2 [ X s m ;X o m ] then op 1 ; op 2 ; ::: ; op n end Here isthenameofthecommand; X i areformalparameterswhosetypesare t i ; r i arerights.Each op i isoneoftheprimitiveoperationslistedintable3{2.

PAGE 32

22 Therights,typesandcommandsdenethesystemscheme.Thes chemecan bemodiedonlybythesystemadministrator,whoisnotconsi deredtobeapart ofthesystem.Thetypeofanobjectisxedandcannotbechang edwithinthe system.SandhuhasprovedthatTAMhasconsiderableexpress ivepower. SafetyprobleminTAMTheaccessrightsleakageproblemforthegeneralTAMmodeli sundecidable (refertotheoriginalpaper[29]forproof).Theauthorden esafewrestrictions onTAMthatallowustomaketheproblemdecidable.ATAMsyste mthatdoes nothaveanycommandthatdeletesarightordestroysasubjec torobjectiscalled MonotonicTAM.Insuchasystem, S O and P [ s;o ]areallmonotonicallynondecreasing.Inagivencommand ,wesaythatatype t i isa childtype inthat commandifoneofthefollowingprimitiveoperations createsubject X i oftype t i or createobject X i oftype t i occursinthebodyof .Thetype t j issaid tobea parenttype in ifoneoftheparametersof isoftype t j and t j isnota childtypein .The creationgraph ofanTAMschemeisadirectedgraphwith vertexset T andanedgefrom u to v ifandonlyifthereisacommandinwhich u isaparenttypeand v isachildtype.ATAMschemeis acyclic ifandonlyif itscreationgraphisacyclic.ATernaryTAMisidenticaltoT AMexceptthatall commandsarelimitedtoamaximumofthreeparameters.Given theseproperties, Sandhuhasprovedthefollowingresults: 1.GenericMTAMisundecidable.2.AcyclicMTAMisNP-Hard.3.ThesafetyquestionforacyclicternaryMTAMisdecidable inpolynomial timeinthesizeoftheinitialaccessmatrix.

PAGE 33

23 3.3.3 AccessControlinUNIXOperatingSystem TheUNIXoperatingsystemwasdevelopedatBellLaboratorie sinthelate 1960s.Itevolvedina\friendly"environment,onsystemsth atencouragedusers tosharetheirles[32].However,UNIXisbydesignaveryrob ustsystem.The followingisabriefdiscussionofthebasicprinciplesinUN IXaccesscontrol. FilesarecentraltoUNIXinwaysthatarenottrueforotherop erating systems.Commandsareexecutablelesinspecicdirectori eslike /bin /usr/bin etc.Systemprivilegesandpermissionsarecontrolledinal argepartviaaccessto les[33].Accesstolesisorganizedaroundleownershipa ndprotection. Eachlehasauserownerandagroupowner.UNIXsupportsthre etypesof leaccess:read( r ),write( w ),andexecute( x ).Adierentsetofaccessrightscan besetforuserowner,groupmembersandothers.Forexample, theaccessright rwxr xr meansthattheuserownercanread,writeandexecutethele, membersofthegroupownercanreadandexecutethelebutall otherscanonly readthele.Thecommandthatisusedtoaltertheaccessmode is chmod Thereareafewotherdenedlemodes,namely, t (Stickybit,keepexecutable inmemoryafterexit), s (SetprocessuserIDorgroupIDonexecution),and l (set mandatorylelockingonreads/writes).Filesthatbeginwi thaperiodarehidden lesandarenotlistedby ls commandunlessusedwiththe a option.The l optionof ls commandliststhelesalongwiththemodesandownersofthe les. Thesetofcommandsthatareusedtomodifytheaccessrightso flesare: chmod Specifytheprotectionmodesforles. umask Specifythedefaultmodefornewlycreatedles. chown Changetheuserownerofale. chgrp Changethegroupownerofale.

PAGE 34

24 SomevariantsofUNIX,likeAIXandHP-UXprovideaccesscont rollistswhich oerafurtherrenementtothestandardUNIXlepermission scapabilities.These ACLsconsistofthreeparts: 1. Attributes SpeciesanyspecialattributeslikeSETUIDandSETGID. 2. Basepermissions ThesecorrespondexactlytotheUNIXlemodesand specifyaccessrightsforowner,groupandothers. 3. Extendedpermissions Theseareaccessinformationspeciedbyuserand groupname. ACLsthatspecifyausernameandgroupareusefulforaccount ingpurposes.They arealsousefulifyouaddauseronatemporarybasis[33]. UNIXwastherstmajornetworkoperatingsystem.Itprovide svarious serviceslikeNIS(NetworkInformationServices)andNFS(N etworkFileSystem) thathelpinadministeringanetwork.UsingNIS,userscanlo gontoanymachine onthenetworkthatbelongstothesameNISDomain.Inanetwor kwithtwenty machines,theadministratorhastoaddthenewuseronjuston emachineandthat usercanlogontoanyoneofthesetwentymachines.Inorderto provideauniform directorystructurewhenauserlogsin,administratorsmou ntlesystemsoverthe network.Usually,theuser'shomedirectoriesaremountedu singNFS.Thiswaythe user'slesareavailabletohim/heronanymachineinthenet work.Theadvantage withthisarrangementisthatcontrollinglepermissionsi sthesameasdescribed earlier. Usersauthenticatethemselvestothesystembyprovidingau sernameand password.Itisveryimportantforuserstoprotecttheirpas swordsbecauseifthe passwordiscompromised,thenallloginsmaybecompromised [32].Passwords andlepermissionsaretwobasicwaysofpreventingsecurit yproblemsinUNIX. Passwordspreventbadguysfromgettingonthesysteminthe rstplaceand properlepermissionspreventnormalusersfromdoingthin gstheyarenot

PAGE 35

25 supposedto[33].Thereareonlythreeaccesstypesandusers cannotdenetheir ownaccesstypes.Moreover,theownerofalehasfullrights todoanythingwith thele.Inmanyorganizations,thelesarenot\owned"byth eusersbutbythe organizationitself. 3.4 Role-BasedAccessControl(RBAC) Role-BasedAccessControl(RBAC)[34,35,36,37,38]isamod elthatis gainingpopularity.TheprincipalmotivationsbehindRBAC aretheabilityto articulateandtoenforceenterprise-specicsecuritypol iciesandtostreamlinethe typicallyburdensomeprocessofsecuritymanagement. Inmanyorganizations,theendusersdonot\own"theinforma tionforwhich theyareallowedaccess.Thecorporationistheactual\owne r"ofsystemobjects aswellastheprogramsthatprocessitandcontrolisoftenba sedonemployee functionsratherthandataownership. InRBAC,usersdonothavediscretionaryaccesstoenterpris eobjects.Instead, accesspermissionsareassociatedwithrolesandusersarea ssociatedwithroles.A rolebasedaccesscontrolpolicybasesaccesscontroldecis ionsontherolesauseris allowedtotakeonwithinanorganization.Thedeterminatio nofrolemembership andtheallocationoftransactionstoaroleisincompliance withorganizationspecicprotectionguidelinesderivedfromexistinglaws, ethics,regulations,or generallyacceptedpractices.WithRBAC,usersarenotgran tedpermissionto performoperationsonanindividualbasis,butoperationsa reassociatedwith roles.Thishastheadvantageofsimplifyingtheunderstand ingandmanagementof privileges. Systemadministratorscontrolaccessatalevelofabstract ionthatisnaturalto thewayenterprisestypicallyconductbusiness.RBACaddre ssessecurityprimarily forapplication-levelsystems,asopposedtogeneralpurpo seoperatingsystems.

PAGE 36

26 RBACenforcesthefollowingrulesonroleauthorization,ro leallocation,and operationexecution.RBACconstraintsareusedtoexpresss eparationofduty. 1.Rolehierarchy Ifasubjectisauthorizedtoaccessaroleandthatrole containsanotherrole,thenthesubjectisalsoallowedtoac cessthecontained role. 2.Staticseparationofduty Auserisauthorizedasamemberofaroleonlyif thatroleisnotmutuallyexclusivewithanyoftheotherrole sforwhichthe useralreadypossessesmembership. 3.Cardinality Thecapacityofarolecannotbeexceededbytheadditionof anotherrolemember. 4.Roleauthorization Asubjectcanneverhaveanactiverolethatisnot authorizedforthatsubject. 5.Roleexecution Asubjectcanexecuteanoperationonlyifthesubjectis actingwithinanactiverole. 6.Dynamicseparationofduty Asubjectcanbecomeactiveinanewroleonlyif theproposedroleisnotmutuallyexclusivewithanyofthero lesinwhichthe subjectiscurrentlyactive. 7.Operationauthorization Asubjectcanexecuteanoperationonlyifthe operationisauthorizedfortheroleinwhichthesubjectisc urrentlyactive. 8.Objectaccessauthorization Asubjectcanaccessanobjectonlyiftheroleis partofthesubject'scurrentactiveroleset,theroleisall owedtoperformthe operationandtheoperationtoaccesstheobjectisauthoriz ed. 3.5 DistributedCompartmentModel TheDistributedCompartmentModel[39,3]wasproposedbySt evenGreenwaldasasolutiontomanagementofsystemresourcesandacce sscontrolina distributedcomputingenvironment.Themodelconsistsoft woparts,(i) DistributedHandles ,ameansforuseridenticationandaccesscontroland(ii) DistributedCompartments ,amethodforallowinguserstomanageresourceswithin adistributedsystemacrosscomputersystemboundarieswit hameasureofindependencefromanysystemadministrations[39].Thedistrib utedhandleseliminate

PAGE 37

27 groupwareapplicationuserIDsasameansofidenticationa ndaccesscontrol. Auserjoiningagroupwaresessionisqueriedforahandletha tisuniquetothat applicationandisthenveriedbyagroupwaresecuritymana ger. Underthismethod,anindividualuserwouldrstgainaccess toaparticular computersysteminthedistributedsystembyhavingavalidu serIDandpassword. Theuserwouldthenneedavaliddistributedhandleandwould thenneedtobe validatedbythegroupware'saccesscontrolsecurityinord ertobeallowedaccessto theapplication. Themajoradvantageofthisapproachisthatsecuritydepend enciesarereduced.Moreover,thehandlescanbemoredescriptivethanus erIDs,forexample \Thirdprogrammer"insteadof\av0".Multiplehandlescanb epermittedforthe sameuserandmanyuserscansharethesamehandle.Distribut edcompartment (alsocalleddiscom)isthedesignatedplatformforaccessc ontrolandadministrationofdistributedhandles. Adiscomisalogicalgroupofobjectsthatisconceptuallysi milartoastandardhierarchicaldirectorystructurebutdoesnotnecessa rilyresideinasingle computer.Theusersofdiscomsgainaccessviadistributedh andles.Arootdiscom iscalledan empirediscom .Eachdiscommusthaveatleastonesubjectcalled governor .Governorshavethemaximumprivilegesforthediscomtheyg overn. Thereare24basicoperationscalled initialprivileges .Theyincludeoperations thatcreate,destroy,ormodifyobjects,create,delete,me rge,split,ormodifychild discomsandempire,createorrescindprivilege,createorr emovegovernorships, subjectsorresources,etc.Thiscombinationofsubjects,o bjectsandprivileges, makesitpossibletocreateasystemsimilartoanaccesscont rolmatrix. TheDistributedCompartmentModelhasasetofaxiomsandpro pertiessome ofwhichare:

PAGE 38

28 DivineRightAxiom Asubjectcancreateanempirediscomonlyifgiventhat privilegebytheadministrators. CreatorProperty Thecreatorofadiscomautomaticallybecomesagovernor ofthatdiscom. GovernmentProperty Thegovernorofadiscommaygrantandrevoke privilegestonon-governorsubjectsofthatdiscom. Novaproperty Anon-governorsubjectmayaccessadescendantdiscomonly ifmadeamemberofthatdiscombyagovernorofanancestordis com. CordonProperty Discomsmayneverintersectwithotherdiscoms. DemesneProperty Thegovernorofadiscomalwayshasunrestrictedaccessto descendantdiscoms. CeilingProperty Asubjectmaynotaccessanancestordiscomwithoutbeing asubjectofthatdiscom. Adistributedcompartmentisactuallyagroupwareapplicat ion,withaccesstothe discomsdeterminedbydistributedhandles.Managementofd iscomsisnotdoneby thelocalsystemadministratorsbutbytheindividualusers whoaregovernorsof empirediscoms. 3.6 AccessControlforCollaborativeEnvironments BasedontheworkbyGreif[40]andEllis[41],BullockandBen ford[42]have identiedfourbasicrequirementsforcollaborativeacces smodels: Themechanismmustbesimple. Themechanismshouldbeunobtrusivetousers. Itshouldbeeasytoinspectandchangeaccessrights. Theeectsofaccesscontrolsshouldbeunderstood,andthec onsequencesof anychangesshouldbeclear. Haakeetal.[43]\...foundthatend-usersinordertoconduc tcooperativework insharedworkspacesystemhavetobeableto(1)creategroup sdynamically

PAGE 39

29 withoutpriorplanningofasystemadministrator,(2)emplo ydierentformsof groupformation,and(3)controlaccessrightstotheirwork spaces."Manycurrent systemslacksucientsupportfortheserequirements. ShenandDewan[44]haveextendedthetraditionalaccessmat rixmodelfor groupwarewithmorethan50basicaccessrightstohandlethe variousoperations requiredforcollaborationandinheritancebasedonrightg roupings.Theyalso supportthenotionof negativerights toallowexplicitdenialofrights. ParkandHwangin[45]tailorthegenericarchitectureforco ntrolledPeerto-Peer(P2P)computingenvironmentstosupportRBAC.Forc ollaborative enterpriseinsuchanenvironment,theyidentifythreedie rentpolicies:enterprise, communityandpeer.Acommunitypolicydenesthecommunity 'sUser-Role Assignment(URA),Permission-RoleAssignment(PRA),cons traintsandrolehierarchy.Anenterprisepolicydenestheenterprise'sUR A,PRA,constraints, role-hierarchyandroleontology(anequivalencerelation betweenrolesindierent communities[46]).Eachpeerdenesitsownpeerpolicyincl udingthepeer'sPRA andconstraints.Theenterprisepolicyisenforcedbyacent ralizedmechanismthat appliestoallcommunitiesinthatenterprise,whileacommu nitypolicyisenforced byacentralizedmechanismwithinthecommunity.Thesetwom echanismsare basedonthebrokeredP2Pmodel.Ifaconrictoccursbetweenp olicies,enterprise policiesaresuperiortocommunitypolicies,whicharesupe riortopeerpolicies unlessspecicpolicypriorityisdened. JaegerandPrakash[47]deneadiscretionaryaccesscontro l(DAC)model forspecifyingtheaccessrightsavailabletoamobileagent whichenablesthe readerandwriterinamobileagentcomputationtorexiblyco ntrolaccessto systemobjects.TheyalsospecifytherequirementsofRBACm odelsnecessaryto implementtheDACmodel.InthistypeofRBACmodel,systemad ministrators denerolesforusers(asinregularRBAC)butcanalsodenea modelthatwill

PAGE 40

30 enableuserstolimittheaccessrightsoftheirownprocesse s.First,systemadmins specifytheobjecttypesthatcanbeusedtospecifyoperatio naccessrights.Also, systemadminsspecifytheuserswhoareauthorizedtolimitt heirownrights dynamically. 3.7 TrustandVoting WhilesignicantworkhasbeendoneintheeldsofPolitical Science,Psychology,and,Ethics[48,49],\mostoftheworkconcerningtrust incomputerscience havebeenconcentratedintheareaofsecurity...mainlyint heformofformal logicstoanalyzecryptographicprotocolsfordesignrawsa ndcorrectness."[50]. OneofthemostpopulardenitionsoftrustisgivenbyDeutsc h[51]. (a)anindividualisconfrontedwithanambiguouspath,apat hthat canleadtoaneventperceivedtobebenecialortoaneventpe rceived tobeharmful;(b)heperceivesthattheoccurrenceofthesee vents iscontingentonthebehaviorofanotherperson;and(c)hepe rceives thestrengthofaharmfuleventtobegreaterthanthestrengt hofa benecialevent.Ifhechoosestotakeanambiguouspathwith such properties,hemakesatrustingchoice;elsehemakesadistr ustful choice. Gambetta[52]hasdenedtrustas\aparticularlevelofthes ubjectiveprobability withwhichanagentassessesthatanotheragentorgroupofag entswillperform aparticularaction,bothbeforehecanmonitorsuchaction( orindependently ofhiscapacityevertobeabletomonitorit)andinacontexti nwhichitaects hisownaction."Thisdenitionhasbeenwidelyacceptedbyc omputerscientists Gambettaintroducedtheconceptofusingvaluesfortrustan dalsodefendedthe existenceofcompetitionamongcooperatingagents.Trusti scloselyrelatedto reputation[53].Abdul-RahmanandHalies[50]denereputa tionasanexpectation aboutanindividual'sbehaviorbasedoninformationabouto robservationsof itspastbehavior.Inonlinecommunities,whereanindividu almayhavevery lessinformationtodeterminethetrustworthinessofother s,theirreputation

PAGE 41

31 informationistypicallyusedtodeterminetheextenttowhi chtheycanbetrusted. Anindividualwhoismorereputedisgenerallyconsideredto bemoretrustworthy. Reputationcanbedeterminedinseveralways.Forexample,a personmayeither relyonhisdirectexperiences,orrelyontheexperiencesof otherpeople,ora combinationofbothtodeterminethereputationofanotherp erson. Asmentionedearlier,workconcerningtrustincomputersci encehasbeen primarilyfocusedoncryptographylikein[54]andworkinvo tinghasbedominated byelectronicvoting[55]wheretheemphasisisonauthentic ationandguaranteeing thatthevotecountedasvoted.Marsh'smodel[56],asfarasw eknow,isoneofthe fewattemptstoformalizetrustbasedontherealworldsocia lpropertiesoftrust. 3.8 Summary TheHRUmodelisaverypowerfulmodelintermsofexpressivep ower. However,itisveryprimitiveinitsconstructionandhasnor oles,objecttypesor otherabstractions.Thereforethematrixcanbeverylarge( andsparse).Itisnot easytoimplementthismodelinadistributedsystem. TheTAMmodeltakesahugestepforwardwiththeadditionofty ping. However,thesetoftypesisstaticandtherearenooperation sdenedinthesystem tochangethetypeofanobjectorsubject.Aswewillshowinth elatersections, makingitpossiblefortheuserstodenetheirowntypesandc hangethetypes allowsustoimplementmanyimportantandinterestingsyste mpolicies. RBACprovidesameansofnaminganddescribingrelationship sbetween individualsandrights.SomeformofRBACisusedincommerci alsystemstoday andsomeattemptshavebeenmadetoformalizethemodel(refe r[36]).Oneofthe majorareasinwhichtheDCSmodelscoresoverRBACisgroupde cisions.Another restrictionistheabsenceofsomemechanismthatallowsde ningone-to-one relationshipsbetweensubjectsandobjects.Forinstance, considertheownership relation.PureRBACcanhandlethecasewhereeachobjecthas onlyoneowner,

PAGE 42

32 however,ifsomeobjectsinthesystemhaveasmallsubsetofu sersasitsowner(s), itisimpracticaltodenenewrolessuchas ownerofobject1 (wewillneedas manysuch\ownerroles"asthereareobjects). OnemajordisadvantagewiththeDiscommodelisthatuserswi llhavetohave aseparatehandleforeachapplicationtheyuse.Thismeanst hattheywillhave toremembernotjusttheiruserIDandpasswordbutthehandle andpasswordfor eachapplication.Itwouldhavebeenpreferabletoavoidsuc hmultiple\logins". Sincemanyuserscansharehandles,thisreducesaccountabi lity.TheDiscommodel practicesatypeofmonarchyinwhichthegovernorshaveabso lutepowerwhereas ademocraticformofgovernmentwillbemorepracticalinthe longrun.The Discommodelisreallyconcernedwithresourcemanagementi nhierarchicalgroups distributedovermultipledomains.TheDCSmodelisconcern edwithauthorization issuesandthesetwomodelscanbeusedtogether,providinga secure,rexible system. Alltheabovemodelsrequireasystemadministratortohandl ethechangesin thesystem.Incorporatinggroupvotingmechanismsallowth euserstodecideand implementthegrouppolicies.Thisisoneofthemainfeature softheDCSmodel. TheJaegerandPrakashmodelallowssystemadministratorst ospecifysome DACfeaturesandwhocanusethem.Theuserswiththeprivileg ecancontrol accesstotheirprocessesbutthisisstillverylimitedDACa nddoesnotallow thegroupstodecidetheirownpolicies(theycandosoonlyfo rthoseobjects thesystemadminsallow).TheRBACschemeforP2Penvironmen tsdescribed abovereliesextensivelyonservercontrolleddecisionsan ddoesnotsupportgroup decisions.Itdoeshoweversupportcommunity-levelautono mywhichallowspolicy decisiontobemadeo-lineandchangesareenforcedbysomeo newithadmin-level privileges.

PAGE 43

CHAPTER4 THEDCS-ACMODEL 4.1 Introduction Inthischapter,wewillintroduceandformallyspecifytheD istributedConferencingServices-AccessControl(DCS-AC).Wewillalsod iscusstheconstraints andrulesthatareimposedonanysystemthatimplementsthis model.Finally,we willdiscusssomeofthekeyfeaturesofthemodelandshowthe DCS-ACsolution tothesoftwareproblemmentionedinsection1.2. 4.2 TheDCS-ACModel Theaccesscontrolmatrixisoftenverybigandsparse.RolebasedAccess Control(RBAC)groupssubjectsinto roles andobjectsinto objecttypes ,thereby shrinkingthematrix.Inthesesystems,eachcellinthematr ixcorrespondtothe setofrightsthecorrespondingrole(identiedbytherow)h adwithrespecttothe objecttype(identiedbythecolumn).IntheDCS-ACmodel,w eareconcerned withtwoadditionalaspects,decisiontemplateandtarget. Thedecisiontemplateisapointertosomevotingtemplate(s eeSection6.2.2) whichshouldbeinvokedinordertomakeadecisionontheacce ssrequest.We expectmostentriesinthematrixtopointtothe Always-yes templatewhichsimply returnsa yes withoutcallingforavote.Typically,requeststhatresult ingranting arighttosomerolemightrequireavotebutoncegranted,exe rcisingthatright maynotrequireone.Itisuptotheuserstodecidewhichreque stsrequireavote andwhichdonotrequireone.Needlesstosay,anyrequesttha trequiresavote willtakesometimetobeprocessedandso,thegrouppolicies shouldbedesigned carefully. 33

PAGE 44

34 Thetargeteldisaverypowerfulideawhichhelpsusachieve ne-grained accesscontrol(seeSection4.6.5).Insteadofsaying\role President canallow subjectstobindtotherole ExecutiveMember ",byusingatargeteld,wecan specifytherightinnerdetailbysaying\role President canallowsubjectsof role TrustedMember tobindtotherole ExecutiveMember ".Here,thetargetisthe role TrustedMember sincewearenarrowingdownthescopeofthisrighttojust thisrole.Dependingonthetypeofcommandbeingexecuted,t hetargetcanbea role,objecttypeoraright.Inthecaseofrightsforwhichth etargeteldisnot applicable,itis null andthekeyword any speciesthattherightcanbeexercised onanytarget. Thedistributionofrightsinthesystemarecanbeviewedasa naccessmatrix (implementedasave-eldRDBMStable), A .Thecell A [ X;Y ]containsaset of( ;Z;dp )tupleswhere isarightwhichrole X hasforobjectsoftype Y with respecttoatarget, Z and dp isapointertoadecisiontemplatethatmustbe activatedeachtime X makesarequesttoperform on( Y;Z ). Weachieveagreatdealofrexibilitybyallowingthegroupto dynamically changeamajorpartofthesystemcomponents.UnliketheTAMm odel,weallow types(i.e.,rolesandobjecttypes)andtypebindings(subj ect-roleandobject-type bindings)tobeaddedanddeleteddynamicallybythegroupac cordingtothegroup policyasrepresentedbythematrix.Similarly,thesetofri ghtsandtheavailable decisiontemplatescanalsobechangedwhilethesystemisin operation.Theonly staticcomponentofthemodelisthesetofcommandswhichare thesameforall instancesofthemodel. Eachsubjectcanbindtooneormore roles butatanypointoftime,the subjectcanbeactiveinonlyonerole.Theusercantemporari lychangehis/her activeroletoanotherroletomakearequestthatisnotallow edforhis/hercurrent role.Oneofthemainreasonsforthisrestrictionisthatthe userhastobeaware

PAGE 45

35 oftheincreasedresponsibilitywhilerequestingaccessth atrequiresmembershipto aprivilegedrole.Eachobjectisboundtoone objecttype .Thesebindingscanbe changedbyanyonewhohastherighttodoso.Thisisamajordi erencefromthe TAMmodelinwhichthebindingsareapartofthesystemdenit ionandcanonly bealteredbyanexternaladministrator.IntheDCS-ACmodel ,theadministrator isconsideredtobeapartofthesystemandissubjecttotheac cessrestrictions imposedbythematrix.An instance ofDCS-AChasthefollowingnitedynamic sets: asetofaccessrightsdenotedby R asetofdecisiontemplatesdenotedby D asetofobjecttypesdenotedby T asetofrolesdenotedby T R ( T ), asetofobjectsdenotedby OBJ ,and asetofsubjectsdenotedby SUB Theaccesscontrolmatrixisdenotedby A .Wehavethreemappingfunctions, f r whichmapseachsubjecttoasubsetof T R (correspondingtotherolestowhich thesubjectcanbind), f o whichmapseachobjecttoanelementof T (itsobject type) 1 ,and f a whichmapseach active subjecttohis/her active role. f r : SUB 2 T R f o : OBJ T 1 Ifanobjectisallowedtobeofmorethanonetype,accesscont roldecisionsare dicult.Shouldauserhaverightstoaccessallobjecttypes ofanobjectinorder toaccesstheobject?Analternativeistodeneanobjecttyp ehierarchy,which increasesthecomplexityofthemodel.

PAGE 46

36 Table4{1:ExampleofDCS-ACMatrixFragment Role ObjectType Target Right Template 1 Programmer Code null Read d yes 2 Programmer Code null Write d yes 3 Programmer Code Read GrantRight d 1 f a : SUB T R ThestateofaDCSsystemisthetuple( A;R;D;T;T R ;OBJ;SUB;f r ;f o )andas notedearlier,thesetofcommands C (denedinsection4.4)istheonlystatic componentofthemodel.Afewsimpleexamplesofthematrixen triesaregivenin table4.2.Here,ProgrammerisaroleandCodeisanobjecttyp e.Read,andWrite areaccesstypesand d yes isapointertothe Always-yes template.Therstthree entriesallowsubjectwhoareactivelyintheroleProgramme rtoreadandwrite objectsoftypeCode.ThethirdentryallowsProgrammerstog rantReadaccess toanyoneifthedecisiontemplate d 1 returnsyes.Thedecisiontemplate d 1 might requiretheapprovaloftheProjectLeaderandDevTeamManag er. GrantRight is aspecialaccessrightthatcorrespondstoaprimitiveopera tionthataddsanentry tothematrix. 4.3 Operations Letsusnowlookattheprimitiveoperationsthatcanbeexecu tedonaDCSACsystem.Theseareoperationsthatmodifyoneormorecompo nentsofthe systemandareguaranteedtobeatomic.Wewillformallyden etheoperations byspecifyingtheireectonthesystem.Let( A;R;D;T;T R ;OBJ;SUB;f r f o )denotethesystembeforetheoperationand( A 0 ;R 0 ;D 0 ;T 0 ;T 0 R ;OBJ 0 ;SUB 0 ; f 0 r f 0 o )denotethesystemaftertheoperation.Table4.3denesthe primitive operationsinDCS-AC.Notethatsetsnotmentionedinthede nitionofan operationareunchangedbythatoperation.Thereisonecomm andforevery operationbutwemightwanttohavecommandswithtwoorthree operations especiallyifwewantrolesandobjecttypestohavepedigree (seesection7.1).

PAGE 47

37Table4{2:SpecicationofDCS-ACOperations Operation Precondition Postcondition grantright( r;ot;;t;dp ) r 2 T R ;t 2 T [ R; 8 ( r 1 ;ot 1 ) 2 T R T t 2 T; 2 R;dp 2 DT; (( r 1 ;ot 1 ) 6 =( r;ot )) A 0 [ r 1 ;ot 1 ]= A [ r 1 ;ot 1 ] 8 dp 1 2 DT; A 0 [ r;ot ]= A [ r;ot ] [f ( ;t;dp ) g ( ;t;dp 1 ) = 2 A [ r;ot ] revokeright( r;ot;;t ) r 2 T R ;t 2 T [ R 8 ( r 1 ;ot 1 ) 2 T R T ot 2 T (( r 1 ;ot 1 ) 6 =( r;ot )) A 0 [ r 1 ;ot 1 ]= A [ r 1 ;ot 1 ] 2 R A 0 [ r;ot ]= f ( 1 ;t 1 ;dp 1 ): ( 1 ;t 1 ;dp 1 ) 2 A [ r;ot ] ^ ( 1 6 = ) ^ ( t 1 6 = t ) g createrole( r ) r= 2 T R T 0 R = T R [f r g 8 ( r 1 ;ot 1 ) 2 T R T;A 0 [ r 1 ;ot 1 ]= A [ r 1 ;ot 1 ] 8 ot 1 2 T;A 0 [ r;ot 1 ]= ; deleterole( r ) :9 s;f r ( s )= f r g T 0 R = T R f r g 8 ( r 1 ;ot 1 ) 2 T 0 R T A 0 [ r 1 ;ot 1 ]= A [ r 1 ;ot 1 ] 8 s 1 2 SUB;f 0 r ( s )= f r ( s ) f r g createot( ot ) ot= 2 T T 0 = T [f ot g 8 ( r 1 ;ot 1 ) 2 T R T 0 ;A 0 [ r 1 ;ot 1 ]= A [ r 1 ;ot 1 ] 8 r 1 2 T R ;A 0 [ r 1 ;ot ]= ; deleteot( ot ) :9 o;f o ( o )= ot T 0 = T 0 f ot g 8 ( r;ot ) 2 T R T 0 ;A 0 [ r;ot ]= A [ r;ot ] addobject( o;ot ) o= 2 OBJ OBJ 0 = OBJ [f o g ot 2 T 8 o 1 2 OBJ;f 0 o ( o 1 )= f o ( o 1 ) f 0 o ( o )= ot delobject( o ) OBJ 0 = OBJ f o g 8 o 1 2 OBJ 0 ;f 0 o ( o 1 )= f o ( o 1 ) addsubject( s;r ) r 2 T R SUB 0 = SUB [f s g 8 s 1 2 SUB;f 0 r ( s 1 )= f r ( s 1 ) f 0 r ( s )= f r g

PAGE 48

38Table4.2:Continued Operation Precondition Postcondition delsubject( s ) SUB 0 = SUB f s g 8 s 1 2 SUB 0 ;f 0 r ( s 1 )= f r ( s 1 ) addaccess( ) R 0 = R [f g delaccess( ) R 0 = R f g 8 ( r;ot ) 2 T R T A 0 [ r;ot ]= f ( 1 ;t;dp ):( 1 ;t;dp ) 2 A [ r;ot ] ^ ( 1 6 = ) g addrolebinding( s;r ) s 2 SUB 8 s 1 2 SUB f s g ;f 0 r ( s 1 )= f r ( s 1 ) r 2 T R f 0 r ( s )= f r ( s ) [f r g delrolebinding( s;r ) s 2 SUB 8 s 1 2 SUB f s g ;f 0 r ( s 1 )= f r ( s 1 ) r 2 T R f 0 r ( s )= f r ( s ) f r g f r ( s ) 6 = f r g changedp( r;t;ot;;dp ) r 2 T R ;t 2 T [ R 8 ( r 1 ;ot 1 ) 2 T R T ot 2 T (( r 1 ;ot 1 ) 6 =( r;ot )) A 0 [ r 1 ;ot 1 ]= A [ r 1 ;ot 1 ] 2 R A 0 [ r;ot ]= f ( 1 ;t 1 ;dp 1 ):( 1 ;t 1 ;dp 1 ) 2 A [ r;ot ] ^ 1 6 = ^ t 1 6 = t g dp 2 DT [f ;t;dp g changeot( o;ot ) o 2 OBJ 8 o 1 2 OBJ;o 1 6 = o f 0 o ( o 1 )= f o ( o 1 ) ot 2 T f 0 o ( o )= ot

PAGE 49

39 4.4 CommandsinDCS-ACModel Theaccesscontrolmatrixcanonlybemodiedthroughtheset ofcommands whichistheonlystaticcomponentintheDCS-ACmodel.Unlik etheHRUand othermodels,thesetofcommandsdoesnotvaryfromsystemto system.There isonecommandforeachprimitiveoperation;itchecksifthe subject'srolehas therighttoperformtheoperationandifso,thenitperforms theoperation.A command consistsoftwoparts:aconditionalpartthatchecksifther oleisallowed tomaketherequestandanexecutionpartthatexecutesoneop eration.Allobjects belongingtotheaccesscontrolmodel(like A;f o ;DT;T;T R etc.)areoftheobject type.GivenbelowisthelistofcommandsinDCS-AC.Inallth esecommands, r istheroleofthesubjectexecutingthecommand. commandCreateRole( r 2 T R ;r new = 2 T R ) if(( CREATEROLE,null,dp ) 2 A [ r; ] )forsome dp 2 DT and dp returns true then createrole ( r new ) commandDeleteRole( r 2 T R ;r 1 2 T R ) if :9 s;f r ( s )= f r 1 g and(( DELETEROLE, null ,dp ) 2 A [ r;r 1 ] )forsome dp 2 DT and dp returns true then deleterole ( r 1 ) commandGrantRight( r 2 T R ;r 1 2 T R ;t 2 T [ R;ot 2 T; 2 R;dp 1 2 DT ) if :9 dp 2 ; ( ;t;dp 2 ) 2 A [ r 1 ;ot ] and(( GRANTRIGHT, ,dp ) 2 A [ r;ot ] )for some dp 2 DT and dp returns true then grantright ( r 1 ;ot;;t;dp 1 ) commandRevokeRight( r 2 T R ;r 1 2 T R ;t 2 T [ R;ot 2 T; 2 R ) if(( REVOKERIGHT, ,dp ) 2 A [ r;ot ] )forsome dp 2 DT and dp returns true then revokeright ( r 1 ;t;ot; ) commandCreateOT( r 2 T R ;ot= 2 T ) if(( CREATEOT, null ,dp ) 2 A [ r; ] )forsome dp 2 DT and dp returns true then createot ( ot )

PAGE 50

40 commandDeleteOT( r 2 T R ;ot 2 T ) if :9 o;f o ( o )= ot and(( DELETEOT, null ,dp ) 2 A [ r;ot ] )forsome dp 2 DT and dp returns true then deleteot ( ot ) commandAddSubject( r 2 T R ;s new = 2 SUB;r initial 2 T R ) if(( ADDSUBJECT, r initial ,dp ) 2 A [ r; ] )forsome dp 2 DT and dp returns true then addsubject ( s;r initial ) commandDelSubject( r 2 T R ;s 2 SUB ) if(( DELSUBJECT, null ,dp ) 2 A [ r; ] )forsome dp 2 DT and dp returns true then delsubject ( s 1 ) commandAddObject( r 2 T R ;o= 2 OBJ;ot 2 T ) if(( ADDOBJECT, null ,dp ) 2 A [ r;ot ] )forsome dp 2 DT and dp returns true then addobject ( o;ot ) commandDelObject( r 2 T R ;o 2 OBJ ) if(( DELOBJECT, null ,dp ) 2 A [ r;ot ] )forsome dp 2 DT and dp returns true then delobject ( o ) commandAddRoleBinding( r 2 T R ;s 2 S;r 1 2 T R ) if(( ADDROLEBINDING, r s ,dp ) 2 A [ r;r 1 ] )forsome dp 2 DT and r s 2 f r ( s ) and dp returns true then addrolebinding ( s;r 1 ) commandDelRoleBinding( r 2 T R ;s 2 S;r 1 2 T R ) if f r ( s ) 6 = f r 1 g and(( DELROLEBINDING, null ,dp ) 2 A [ r;r 1 ] )forsome dp 2 DT and dp returns true then delrolebinding ( s;r 1 ) commandChangeOT( r 2 T R ;o 2 OBJ;ot new 2 T ) if(( CHANGEOT, f o ( o ) ,dp ) 2 A [ r;ot new ] )forsome dp 2 DT and dp returns true then changeot ( o;ot new ) commandAddAccess( r 2 T R ;= 2 R ) if(( ADDACCESS, null ,dp ) 2 A [ r; ] )forsome dp 2 DT and dp returns true then addaccess ( )

PAGE 51

41 commandDelACCESS( r 2 T R ; 2 R ) if(( DELACCESS, ,dp ) 2 A [ r; ] )forsome dp 2 DT and dp returns true then delaccess ( ) commandChangeDP( r 2 T R ;r 1 2 T R ;t 2 T [ R;ot 2 T; 2 R;dp new 2 DT ) if 9 dp 1 ; ( ;t;dp 1 ) 2 A [ r 1 ;ot ] and(( CHANGEDP, ,dp ) 2 A [ r;ot ] )forsome dp 2 DT and dp returns true then changedp ( r 1 ;t;ot;;dp new ) Itisobviousthatallthecommandscanbeexecutedinconstan ttime(assuminganthatlookinguptheaccessmatrixandotherDCS-ACc omponentscan bedoneinconstanttime).Moreover,therolesandobjecttyp escreatedbythe CreateRole and CreateOT commandshavenopedigree,i.e.,thecreatoroftherole orobjecttypehasnospecialrightsoverthatroleorobjectt ype.Wealsoallowthe objecttype,accessrightandthetargettobereplacedbythe keyword ANY .For example,if( ANY;ANY;dp ) 2 A [ Secretary;ANY ]where dp isadecisiontemplate thatcallsforasimplemajorityofallsubjectswhocanbindt otherole Senator thenaSecretarycanmakeanychangetothesystemifapproved byamajority ofthesenators.Sincetherolesandobjecttypeshavenopedi gree,therehasto beagrouppolicyforgrantingrightstotheserolesandobjec ttypes(typically, ( GRANTRIGHT;ANY;someDP ) 2 A [ SomeRole;Any ]). 4.4.1 Constraints Thereareafewconstraintsthathavetobeenforcedonthesys tem,someof whichhavebeenmentionedearlier. ActiveRole Atnopointoftimecanasubjectbeactiveinmorethanone role. RoleAuthorization Asubjectcanonlybeactiveinroleshe/sheisauthorized tobein. OperationAuthorization Asubjectcanperformonlythoseoperationsthat his/heractiveroleisauthorizedtodo.

PAGE 52

42 ObjectAccessAuthorization Asubjectcanonlyaccessthoseobjectshis/her activeroleisauthorizedtodo. AmendmentRule Thereshouldalwaysbearulethatallowsthegroupto modifyanycomponentofthesystem. DeleteRestriction Aroleorobjecttypecannotbedeletedifitresultsina violationoftherulesandconstraints. GracefulDeletion Ifanactivesubjectisdeletedfromthesystem,thedeleted subjectshouldloseallrightimmediately. DecisionTemplateOverwriteRule A GrantRight commandshouldnotbe allowedtochangethedecisiontemplateofanalreadygrante dright. The ActiveRole constraintisenforcedtosimplifytheaccesscheckingproc ess.The RoleAuthorization OperationAuthorization ,and ObjectAccessAuthorization areRBACenforcedconstraints. AmendmentRule islikeanemergencyoverride toallowthegrouptorecoverfromunusablestates.Typicall y,thisisenforcedby amatrixentrythatallowsaparticularroletochangeanythi ngifsometemplate returnsayes.Forexample,the Chairman canchangeanyruleifallthe Faculty andthe CollegeDean agree. The DeleteRestriction isimposedondeletionofrolesandobjecttypes.If thereisasubjectthatcanbindtoonlyonerole,thendeletin gthatrolemeansthat thesubjectcannotbindtoanyrole.Thisisaninconsistents tateandshouldbe avoided.Thissubjectshouldbedeletedorallowedtobindto anotherrolebefore deletingthisrole.Furthermore,ifthereisasubjectcurre ntlyactiveinaparticular role,thenthatrolecannotbedeleted.Similarly,iftherei satleastoneobjectthat belongtoaparticulartype,thattypecannotbedeleted. The GracefulDeletion ruleisfordeletingsubjectswhoarecurrentlyactive. Theyshouldbeimmediatelyloggedoutofthesystemwithsuit ablenotication messages.The DecisionTemplateOverwriteRule preventssomesubjectfrom changingthedecisiontemplateforanentryinthematrixbyu singthe GrantRight

PAGE 53

43 command.Thisisenforcedbyensuringthatno GrantRight commandgrantsan alreadyexistingcommand.Thedecisiontemplatepointersf oranentrycanonlybe changedbythe ChangeDP command. 4.4.2 ExpressivePower ItiswellknownthattheHRUmodelhasverygoodexpressivepo werbutis veryweakintermsofprovablesafety.ItcanbeseenthattheD CS-ACmodelalso hasverygoodexpressivepower.AnyHRUprotectionstatecan beconvertedtothe DCS-ACmodel. MappingfromHRUtoDCS-ACConsideraprotectionsystem( R;C )andastate( S;O;P ).Letusdeneanew roleforeachuserandallowonlythatusertobindtothatrole andcallthesetof theseroles T R .Similarly,deneanewobjecttypeforeachobjectandcallt hisset T .Wedene DT = f dp g where dp isapointertoadecisiontemplatethatalways return yes .LetthenewDCS-ACinstancebe( R DT T T R O S f o f r A ). 8 o i 2 O addanewobjecttype ot i to T andlet f o ( o i )= ot i 8 s i 2 S addanewrole r i to T R andlet f r ( s i )= f r i g A [ r i ;ot i ]= f ( ;null;dp ): 2 P [ s i ;o i ] g NowwehaveaninstanceofDCS-ACmodeldenedby( R DT T T R O S f o f r A ).Althoughthesystemstateinthetwomodelsareequivalent ,thesystems themselvesarenotequivalentbecausewehavenotmappedthe commandsofthe HRUmodeltosomethingequivalentintheDCS-ACmodel. MappingfromDCS-ACtoHRUSimilarly,wecandoamappingfromDCS-ACtoHRU.Hereagain, thetwo systemswillnotbeequivalentbecauseofdynamictypingand decisionpointers. ConsideraninstanceoftheDCS-ACmodel( R;DT;T;T R ;OBJ;SUB;f r ;f o ;A ).

PAGE 54

44 WecanconvertthisintoaHRUsystem( R 0 ;C )withtheconguration( S;O;P )as follows: 1. R 0 = R R m where R m isthesetofallmatrixmanipulationoperations notsupportedbyHRU. 2. S = SUB and O = OBJ 3. 8 ( s;o ) 2 SUB OBJ (a) 8 r 2 f r ( s ) ;P [ s;o ]= f :( ;null;dp ) 2 A [ r;f o ( o )] ^ = 2 R m g 4.Addcommandstoperformeachofthesixoperationsifthesu bjecthasthe rightsimilartotheonespeciedinsection4.4. NotethattheresultingHRUinstanceisamono-operationalo neandhencethe safetyofthisisdecidableinNPtime.Here,wedropalltypin ginformation, decisionpointersandoperationsnotallowedbyHRU. 4.5 Comparisonwithexistingmodels OnemajordierencebetweentheDCS-ACmodelandtheothermo delsisthe factthattheACMitselfisanobjectandthereisarightcorre spondingtoeachof theabovementionedoperations.Ifauserwantstoperformam atrixmodifying operation,thenhis/herroleshouldhavetherighttodoso.I tmustbenotedthat inTAM, R;T;T R and t areallpartofthesystemdenitionandcannotbealtered byanyonewithinthesystem,whereastheseareapartoftheDC S-ACmodel instanceandcanbemodiedbyanyonewhohastherighttodoso .TAMdoesnot havethenotionofdecisionpointerseither.TAMallowsanyn umberofparameters initscommandsbuttheDCS-ACallowsatmostve. HRUTAM +Strong Typing + Dynamic Typing+ Decision Pointers DCS Arbitrary Commands Figure4{1:ComparisonofHRU,TAMandDCS-ACmodels TheTAMmodeladdedthenotionofstrongtypingtotheHRUmode l. TheDCS-ACmodelhasdynamictyping,staticsetofcommands( asopposedto

PAGE 55

45 arbitrarycommands)andmostimportantofall,decisiontem platepointersthat allowsthemembersofthegrouptodecideonaccessrightissu es.Anothermajor dierenceisthedynamicsetofaccessrights.Asmentionede arlier,theterm role asusedintheDCS-ACmodelisdierentfromwhatitmeansinRB AC.Hereare somedierencesbetweenthetwo: RoleHierarchy Thereisnorolehierarchyinthecurrentimplementationof theDCS-ACmodel.Subsection7.3talksabouthowtheDCS-ACm odelcan beextendedtoimplementrolehierarchy. StaticSeparationofDuty TheDCS-ACmodeldoesnotsupportstaticseparationofduty.However,itispossibletoimplementdynami cseparationof dutyusingfunctioncalls.Allseparationofdutypoliciesc anbeimplemented asdynamicwhichprovidesgreaterrexibilitytotheusers. DecisionPointers Theuseofdecisionpointersisthenewparadigmintroduced inthismodel.Asmentionedearlier,thisadditionisveryus efulinspecifying varioussystempolicies. 4.6 FeaturesofDCS-ACModel Theaccesscontrolmatrixandthefunctionsmappingvarious setsarestored astablesinabackenddatabasewhichisreplicatedacrossal lsites.Allupdates anddeletionsarepropagatedtoothersitesbyaseparateDat abaseServicesmodule (DBS)whichguaranteesprocessorconsistencyforupdates, i.e.,updatesoriginating fromthesameprocessorwillbecommittedatallsitesinthes ameorder.This isachievedbyassigninganownersiteforeachtupleintheta ble.Whenanew tupleistobeadded,thesitetherequestoriginatedistheow ner.Modications toaparticulartupleareforwardedtoitsownerwhichthenmu lticaststoother sites.ThedecisiontemplatesaremaintainedbytheDecisio nSupportServices module(DSS)whichstoresthevoteparticipants,percentag eofvotesrequiredfor successandotherinformationaboutthetemplate.Whenthea ccesscontrolmodule initiatesadecision,theparticipantsarenotiedandthev otesarecollected.Once adecisionisreached,theDSSpassesittotheaccesscontrol modulewhichtakes

PAGE 56

46 furtheractionasrequired.Notethatinmanycases,thedeci sionpointermaypoint toatemplatethatalwaysreturnsa yes 4.6.1 DecisionTemplates Decisiontemplatesareoneofthemostinterestingfeatures oftheDCS-AC model.Theuseofgroupvotingmechanismsallowtheuserstos elf-administertheir groups.Itisquiteclearthatthesafetyofthesystemwillde pendveryheavily onthedecisionpointer.Itwillbeveryinterestingtostudy thevarioustypesof collusionattackspossiblebasedonagivensetofdecisionp ointers.Adecision templatecontainsthefollowinginformation:(i)Alistofv otersalongwiththe weightofeachentity's(role/subject)vote,(ii)numberof votersforquorum,(iii) startandendtimes,(iv)percentageofvoterwhohavetoagre eforthevotetopass, (v)defaultpoliciesifquorumisnotreached,and(iv)other bookkeepingdetailslike whoshouldbenotiedoftheresultetc.Thetemplatealsospe cieswhatkindof votetostart(ranking,simplemajority,multiplerounds,e tc.).Itisexpectedthat mostaccessrequestswillinvokeasimpledecisiontemplate thatalwaysreturns yes andonlyafewaccessrequests(likegrantingarighttoarole oranythingdeemed importantbythegroup)willrequireavote. Ifweallowthedecisionpointerstobepointerstoavotingpr ocessora functioncallthatreturnsadecisionbasedonthestateofth esystem,wecan implementinterestingpoliciesliketheseparationofduty .Iftheglobalpolicy statesthatanyuserwhohasaccesstoobjectsoftype O 1 shouldnothaveaccess toobjectsoftype O 2 ,thenthedecisionpointerwillexecuteafunctionthatallo ws theaccessonlyifthecellcorrespondingto[ R;O 1 ]isnullforevery R inthesetof allrolesthesubjectcanbindto.However,theuseoffunctio npointersmightmake theaccessrightleakageproblemundecidableandiscurrent lynotapartofthe DCS-ACmodel.

PAGE 57

47 4.6.2 DynamicTypeBinding Thebindingbetweenobjects/subjectsandtheirtypesissta ticinTAM(HRU doesnothavetypes).Therearemanyscenariosinwhichthisb indinghastobe changed.Byallowingthebindingstochange,wecanalsomode lprocesswork rows.Forexample,ifthegrouppolicystatesthatthereview teamshouldnot beabletoaccessthecodeuntilitpassesthetestingphase.W ecandenethree dierentobjecttypes, workingcode,ready-for-test and ready-for-review .Whenthe codeisreadyfortesting,theprojectleaderorthedevelope rcanchangetheobject typeofthelesto ready-for-test .Nowthetesterscandotheirjob.Anadditional advantageindoingthingsthiswayisthattheprogrammersca nnotmodifytheles thatarebeingtested(iftheydonothavethataccessforobje ctsoftype ready-fortest .Ifthecodefailstesting,thePLcanchangeitstypebackto workingcode else, he/shecanchangeitto ready-for-review 4.6.3 DynamicsetofAccessRights Asmentionedearlier,oneofthedierencesbetweentheDCSACmodeland theothermodelsisthefactthattheaccessrightsarenotapa rtofthesystem denition.Whenanewapplicationisaddedtoasystemwithas taticsetofaccess rights,ne-grainedaccesscontrolhastobemanagedbythea pplicationitself.In theDCS-ACmodel,whenanewapplicationisadded,wecanden enewaccess typestothesystemandmakeaccesscontroldecisionsatthes ystemlevel.For example,ifanewaudio-videoapplicationisadded,wecande nenewaccesstypes like playaudiole recompressthele cutandcroples ,etc.Now,basedonthe roles(likeproducer,soundengineer,etc.)itisstraightf orwardtodeneaccess controlpolicieslikeaproducercanplayanaudiolebutcan notmodifyit,a soundengineercanplay,recompress,cutandcropanaudiol e.Wecanalsodene specialrelationssothatonlytheproducersandsoundengin eersworkingwitha

PAGE 58

48 particularartistcanaccesstheaudiolesrecordedbythat artist.Aswecansee, therealmofpossibilitiesisverylarge. 4.6.4 DynamicsetofObjectTypes Inmostrealworldscenarios,itisimpossibletokeeptheset ofobjecttypesa constant.Wecannotforeseeallpossibleobjecttypesdurin gsysteminitiationand althoughtheneedmaynotbeveryfrequent,itisverylikelyt hatanysystemwill neednewobjecttypesatsomepointoftime.Whenatheaudio-v ideoapplication mentionedintheprevioussectionisinstalled,wehavetocr eateanewobject type(called audiole ).Itisquitepossibletojustusethetype genericle and individuallyspecifytheaccessrightsforeachaudiole.T hisishowitwillhaveto bedoneinTAM.However,themainadvantageofusingtypesist hereductionin thesizeoftheACMandhence,specifyingtherightsforeacha ndeveryaudioleis counter-productiveintermsofACMsize.Thusitismorelogi caltoallowthesetof objecttypestochangewiththeneedsoftheusers. 4.6.5 FineGrainAccessControl AscanbeseenfromthecommandsinDCS-AC(Section4.4),theu seof the target eldallowsustodeneverynegrainedaccesscontrolpolic ies.For example,wecanspecifythatrole r hastherighttogrant read accesstoobjectsof type ot (( GRANTRIGHT;read;dp ) 2 A [ r;ot ])andwecansimilarlyspecifyrevoke rightsforspecicaccesses.Anotherinstanceofnegraine daccesscontrolisthe ChangeOT command.Ifamanagercandeclassifya TopSecret documentto Secret buttooonlywiththeapprovaloftheCEO,then( CHANGEOT;Secret;dp 1 ) 2 A [ Manager;TopSecret ]where dp 1 isadecisiontemplatethathasonlyonevoter, theCEO.Thislevelofgranularityisnotavailableinmostac cesscontrolmodelsin usetoday.

PAGE 59

49 4.7 DCS-ACModelSolutionforSoftwareProjectExample Hereisasolutiontothesoftwareprojectexamplementioned insectionrefmotivationusingtheDCS-ACmodel.Letthesetofrolesbe T R = f PL,Architect, Prog,Tester g .Whentheproject(letscallitX)isstartedthefollowingob ject typesarecreated: XDesignDoc,XCode,XWorkingCode,XTestedCode and XShipCode .Thefollowingrolesarealsocreated: XPL,XArchitect,XProg and XTester Wenowaddtheentriesspeciedintable4{3totheaccesscont rolmatrix, A Here, dp 1 isadecisionpointerthatalwaysreturns yes dp 2 requiresavoteof allsubjectswhocanbindto XProg and dp 3 requiresavoteofallsubjectswhocan bindto PL .Entries1,2and3allowtheXPLtodecidewhoworksonaprojec t butensuresthatpolicy6(PLcannotchangetheroleofanempl oyee)isenforced. Thisisasimplisticviewofthingsanditisveryeasytoenvis ionasystemwhere compile and execute arevalidaccesseswhichareusedbyaDCS-awaredevelopment environment. ThusclasslibrariesexampleissolvedbyusingtheDCS-ACmo del.Similar solutionsaresuitableforcollaborativecontractediting andmanyotherdistributed collaborativeapplications.Thisexamplealsoillustrate showtheDCS-ACmodel canbeusedtomodelprocessworkrow.

PAGE 60

50Table4{3:DCS-ACSolutionforSoftwareProjectExample No. Entry Explanation 1 ( ADDROLEBINDING;Architect;dp 1 ) 2 A [ XPL;XArchitect ] ThePLcanassignarchitects totheproject 2 ( ADDROLEBINDING;Prog;dp 1 ) 2 A [ XPL;XProg ] PLcanaddprogrammersto theproject 3 ( ADDROLEBINDING;Tester;dp 1 ) 2 A [ XPL;XTester ] PLcanaddtestersto theproject 4 ( ADDOBJECT;null;dp 1 ) 2 A [ XArchitect;XDesignDoc ] Architectscancreatedesign documentation 5 ( read;null;dp 1 ) 2 A [ XArchitect;XDesignDoc ] Architectscanreadthedocs 6 ( read;null;dp 1 ) 2 A [ XPL;XDesignDoc ] ThePLcanreadthedocs 7 ( write;null;dp 1 ) 2 A [ XArchitect;XDesignDoc ] Architectscanwritetodocs 8 ( read;null;dp 1 ) 2 A [ XProg;XDesignDoc ] Programmerscanreadthedocs 9 ( ADDOBJECT;null;dp 1 ) 2 A [ XProg;XCode ] Progscancreatecodeles 10 ( read;null;dp 1 ) 2 A [ XProg;XCode ] Progscanreadthecodeles 11 ( read;null;dp 1 ) 2 A [ XPL;XCode ] PLcanreadthecodeles 12 ( write;null;dp 1 ) 2 A [ XProg;XCode ] Progscanwritetothecodeles 13 ( CHANGEOT;XCode;dp 2 ) 2 A [ XProg;XWorkingCode ] Progstakeavotetosubmit codefortesting 14 ( read;null;dp 1 ) 2 A [ XTester;XWorkingCode ] Testerscanreadworkingcode 15 ( CHANGEOT;XWorkingCode;dp 1 ) 2 A [ XTester;XCode ] Testerscanreturncode toprogrammers 16 ( CHANGEOT;XWorkingCode;dp 1 ) 2 A [ XTester;XTestedCode ] Testerscanmarkcodeready forreview 17 ( read;null;dp 1 ) 2 A [ PL;XTestedCode ] AllPLsinthecompanycan lookattestedcode. 18 ( CHANGEOT;XTestedCode;dp 3 ) 2 A [ XPL;XShipCode ] PLcanshipcodeif reviewteamagrees

PAGE 61

51 4.8 Summary Inthischapter,wedenedanddiscussedtheDCS-ACmodel.On eofthemain featuresofthismodelistheabilityofthesubjectstovoteo nimportant(asdened bythegroup)decisions.Allsubjectsbelongtooneormorero lesandallobjects belongtoanobject-type.Theaccessmatrixentryforaparti cularroleandobject typecontainsasetoforderedpairscorrespondingtotherig htstherolehasover theobjecttypeandthedecisiontemplatethatisexecutedwh enasubjectofthat roletriestousethatparticularrightovertheobjecttype. Thedecisiontemplate mightpointtothe Always-yes template(whichalwaysreturns yes )oranyother templatedenedbythegroup.Therearesixteenprimitiveop erationsandsixteen commands(eachofwhichcorrespondtooneoftheoperations) .Thesearethe onlystaticcomponentsofthemodel.Thegroupcandeneandm odifyallother componentslikeroles,objecttypes,etc.dynamically.The reareafewconstraints thathavetobeenforcedwhenimplementingthismodel.Theco mmandsinDCSACaredesignedinsuchawaysoastoallowne-grainedaccess control,i.e.,we canspecifyruleslike RoleXcanallowasubjectofroleYtobindtotheroleZ insteadofjustamoregeneralrulelike RoleXcanallowasubjecttobindtoroleZ Itshouldberememberedthatwhileallthesefeaturesarerea llypowerful,care mustbetakentoavoidgettingintoastatethatmakesthesyst emdiculttouse. The AmendmentRule constraintenablesthegrouptorecoverfromanysuchbad states.Inthenextchapter,wewillprovethatthemodelispr ovablysafe.

PAGE 62

CHAPTER5 SAFETYANALYSIS 5.1 Introduction Thepresenceofdecisionpointersmakesthesafetyanalysis oftheDCS-AC modelverytricky.ConsiderarestrictedversionofDCS-ACw herethereisonly onedecisionpointerinthesystem, dp ,andthatpointeralwaysreturns true .This isavalidrestrictionbecause,iftrusteddeciderscontrol adecision,theywillvote no ,sowecanremovetheseentriesfromthematrixandanydecisi oncontrolledby untrusteddeciderswill,intheworstcase,alwaysresultin yes .Wewillrstanalyze thesafetyofsucharestrictedmodelandinthenextchapter, wewilldiscussthe safetyofthefullmodel. 5.2 Denitions Letusnowlookatsomedenitionsthatwillhelpusunderstan dthesafety propertiesoftheDCS-ACmodel.Denition Thestate, S ,ofaDCS-ACsystemisasnapshotofthesystemata giventime.Itconsistsoftheaccesscontrolmatrix A ,therolebindingfunction f r theobjecttypebindingfunction f o ,andthefollowingsets: setofrights R setofsubjects SUB setofobjects OBJ setofobjecttypes T setofroles T R ( T R T ),and setofdecisiontemplates DT 52

PAGE 63

53 Denition Foragivenstate S ,objecttype ot ,andright S;;ot = f s : s 2 SUB ^9 r 2 f r ( s ) ;t 2 ( T [ R [; )suchthat( ;t;dp ) 2 A [ r;ot ] g Inotherwords, S;;ot isthesetofallsubjectswhohavetheright forobjectsof type ot in S .Wecangettheset S;;ot in O ( j SUB jj T R jj R j )timeasfollows: functiongetPhi( S;;ot ) 1. result = ; 2.forall s 2 SUB (a)forall r 2 f r ( s ) i.forall ( 0 ;t 0 ;dp ) 2 A [ r;ot ] A.if 0 = then result = result [f s g Processnext s 3.return result Denition Giventwostates, S and S 0 ,andacommand, ,wesay S* S 0 ifthe command canbeexecutedon S and S 0 istheresultofperformingtheoperation in on S (i.e.,applying on S resultsin S 0 ). Denition Giventwostates S and S 0 ,andasequenceofcommands (containing k commands, 1 ; 2 ;:::; k ),wesay S S 0 if 8><>: k =0 ) S = S 0 k =1 ) S* 1 S 0 k> 1 ) S* 1 S 1 ^ S 1 0 S 0 ; where 0 = 2 ; 3 ;:::; k Denition ForagivenDCS-ACstate S ,object o ,andright ,wesaythata sequenceofcommands resultsinaleakingstateifandonlyif S S 0 ) S 0 ;;f 0 o ( o ) S;;f o ( o ) 6 = ; Letusnowdenetheaccessrightleakprobleminthecontexto ftheDCS-AC model.

PAGE 64

54 Denition ForagivenDCS-ACstate S ,object o ,andright ,theaccessright leakproblemisadecisionproblemisthequestion,doesther eexistasequenceof commandson S thatresultsinaleakingstate. 5.3 AttributesofaState Inordertohelpuskeeptrackofthecommandsthathavebeenex ectutedand thosethatcanbeexecuted,weidentifycertainattributesw hicharedependenton thecurrentstateofthesystem.Eachoftheseattributescan beactive(i.e.,the commandhasbeenexecuted),enabled(thecommandhasnotbee nexecutedbut thereissomeroleinthecurrentstatethatcanexecutetheco mmand),orinactive (thecommandhasnotbeenexecutednorcananyroleexecuteth ecommandinthe currentstate). Foranystate S t (reachedbyexecuting0ormorecommandsonthestarting state S 0 ),thefollowingattributesarevalid: 1. HasRight r 0 ;ot 0 ; 0 ;t Thisattributetracksthe GrantRight commandsand issaidtobeactivefor S t if( 0 ;t;dp ) 2 A ( r 0 ;ot 0 )forsome dp 2 DT Iftheattributeisnotactive,wesaythatthisattributeise nabledif 9 r;dp 0 suchthat( GRANTRIGHT;dp 0 ) 2 A ( r;ot 0 ) 2. CanBind s 0 ;r 0 Thisattributetrackssubject-rolebindingsandissaidtob e activefor S t if r 0 2 f r ( s 0 ).Iftheattributeisnotactive,wesaythatthis attributeisenabledif 9 r;dp 0 suchthat( ADDROLEBINDING;dp 0 ) 2 A ( r;r 0 ) Foragivenstartingstate S 0 andadescendantstate S t (reachedbyexecuting1or morecommandsonthestartingstate S 0 ,i.e., 9 suchthat j j 1 ^ S 0 S t ), weidentifythefollowingattributesthatarevalidfor S t andallstatesthatresultin executingasequenceofcommandson S t : 1. NewRole Thisattributeissaidtobeactivefor S t ifoneofthecommands wehaveexecutedon S 0 isa CreateRole command.Itcannotbeactivefor S 0 .Iftheattributeisnotactive,wesaythatthisattributeis enabledif 9 r;d 0 suchthat( CREATEROLE;d 0 ) 2 A ( r; )

PAGE 65

55 2. NewOT Thisattributeissaidtobeactivefor S t ifoneofthecommandswe haveexecutedon S 0 isa CreateOT command.Itcannotbeactiveforthe initialstate S 0 .Iftheattributeisnotactive,wesaythatthisattributeis enabledif 9 r;d 0 suchthat( CREATEOT;d 0 ) 2 A ( r; ) 3. NewSubject r 0 Thisattributeissaidtobeactiveforastate S t ifoneofthe commandsexecutedisa AddSubject commandwiththeinitialrole r 0 .These attributescannotbeactivefor S 0 .Iftheattributeisnotactive,wesaythat thisattributeisenabledif 9 r;dp 0 suchthat( ADDSUBJECT;dp 0 ) 2 A ( r;r 0 ) Theseattributesareactivatedbyexecutingthecorrespond ingcommands. Active ( S i )isthesetofattributesthatareactiveinastate S i and Enabled ( S i ) isthesetofattributesthatareenabledin S i 5.4 Proofs Letusnowlookatafewlemmasandtheoremsthatwillleadtoap olynomial timesolutiontotheARLproblemforatDCS-ACsystemwithout voting. Denition Wesaythattwostates S i and S j (withthesamestartingstate S 0 )are equivalent intermsofaccessrightleakageif: S i isaleakingstate S j isaleakingstate .Axiom1 InaDCS-ACsystemwithaninitialstate S ,twosequencesofcommands, 1 and 2 ,resultinequivalentstatesiftheactiveattributesofthe two resultingstatearethesame. ( S 1 S 1 ) ^ ( S 2 S 2 ) ^ ( Active ( S 1 )= Active ( S 2 )) ) S 1 S 2 Lemma2 Foragivenstate S ,object o ,andright ,ifthereexistsasequenceof commands thatresultinaleakingstate,thenthereexistsasequenceo fcommands 0 suchthat: 0 resultsinaleakingstateand

PAGE 66

56 0 doesnotcontainanycommandthatrevokesarightordeletesa subject, object,role,objecttypeoraccess. Proof Let = 1 ; 2 ;:::; k andlet i betherstrevocationordeletioncommand. Let j (1 j k )bethesmallestnumbersuchthatthesequence 1 = 1 ;:::; j resultsinaleakingstate S 0 .Clearly, j 6 = i since i isarevocationor deletioncommand. Case1: ji Considerthesequence 2 = 1 ;:::; i 1 ; i +1 ;:::; j .Weknowthatthe commands i +1 ;:::; j canbeexecutedevenifwehadexecuted i (whichremoves somethingfrom S ).Moreover,allcommandscheckforthepresenceofsomerigh t andnotfortheabsence.Therefore,thecommandsin 2 canstillbeexecutedand hence,thissequencewillalsoresultinaleakingstate. Repeatingtheabovestepforallrevocationanddeletioncom mandsin ,we get 0 ,asequencewhichdoesnotcontainanyrevocationordeletio ncommandand resultsinaleakingstateif resultsinaleakingstate. Lemma3 Foragivenstate S ,object o ,andright ,ifthereexistsasequenceof commands thatresultinaleakingstate,thenthereexistsasequenceo fcommands 0 suchthat: 0 alsoresultsinaleakingstateand 0 doesnotcontainany AddObject AddAccess ,or ChangeDP commands. Proof Let = 1 ; 2 ;:::; m andlet i bethecommandthataddsanewobject o 1 .Weconstruct 1 byremoving i andallothercommandsin thatchange

PAGE 67

57 theobjecttypeof o 1 .Since ChangeOT istheonlycommandthatdependsonthe existenceof o 1 ,alltheothercommandscanstillbeexecuted. Sincethepresenceorabsenceof o 1 doesnotaecttherightleakfor o (asper thedenitionofrightleakproblemabove),if resultsinaleakingstate,then 1 alsoresultsinaleakingstate. Repeatingtheabovestepsforall AddObject commands,wegetasequence 2 whichdoesnotcontainany AddObject commandsandresultsinaleakingstateif resultsinaleakingstate. Usingsimilararguments,wecanremoveall AddAccess commandsfrom 2 .Moreover,sincethereisonlyonedecisionpointerinthesy stem, ChangeDP commandscanignored. Sowenowhaveasequence 0 whichdoesnotcontainany AddObject,AddAccess or ChangeDP commandsandresultsinaleakingstateif resultsinaleaking state. Corollary4 Foragivenstate S ,object o ,andright ,ifthereexistsasequenceof commands thatresultinaleakingstate,thenthereexistsasequenceo fcommands 0 suchthat: 0 alsoresultsinaleakingstateand 0 doescontainsonly CreateRole,CreateOT,AddSubject,GrantRight, AddRoleBinding, and ChangeOT commands. Lemma5 Foragivenstate S ,object o ,andright ,ifthereexistsasequenceof commands thatresultinaleakingstate,thenthereexistsasequenceo fcommands 0 suchthat: 0 alsoresultsinaleakingstateand 0 doesnotcontainmorethanone CreateRole andone CreateOT command.

PAGE 68

58 Proof Let = 1 ; 2 ;:::; m .Wewillconstructanewsequence, 1 ,asfollows: 1.Let create i newroles, r 1 ;r 2 ;:::;r i 2.Removeall CreateRole commandsin commandsexcepttherstone(only r 1 isadded). 3.Replacealloccurrencesof r j (1
PAGE 69

59 Let contain n commandsthataddanewsubjectwiththeinitialrole r 1 AddRoleBinding istheonlycommandotherthan AddSubject thatdirectly addressesasubject. Let } ( k;r 1 )bethestatementthatif adds k newsubjectswithinitialrole r 1 thenthereexistsasequenceofcommandsthatresultsinalea kingstateandadds onlyonenewsubjectwithinitialrole r 1 BaseCase: k =2 Whentherstsubject s 1 iscreated, f r ( s 1 )= f r 1 g .Whenthesecondsubject s 2 iscreated, f r ( s 2 ) f r ( s 1 ),therefore,anynewrolebindingaddedfor s 2 canalsobeaddedfor s 1 .Letusconstructanewsequence 1 byremovingthe AddSubject( r 0 ;r 1 ;s 2 ) command,replacingeveryoccurrenceof s 2 with s 1 inall AddRoleBinding commandsandretainingallothercommands. Let S S 0 and S 1 S 1 .Byconstruction, s 1 hasalltherightsin S 1 that s 2 hasin S 0 andneither s 1 nor s 2 wereapartof S .Wealsoknowthat S 0 isa leakingstate(since resultsinaleakingstate).Now,wewillprovethat S 1 isalso aleakingstate. Case1:Thenewlycreatedsubject s 2 causedtheleak. If s 2 getstheright over o in S 0 ,then s 1 gets over o in S 1 .Therefore,if s 2 wasthecauseoftheleakin S 0 ,then s 1 willcausealeakin S 1 Case2:Therightleakwasduetosomeothercommandin Sinceallthecommandsotherthanthosethathave s 2 asaparameterhave beenretainedin 1 ,ifcommandsotherthantheonesaecting s 2 causedtheleak in S 0 ,thenthosesamecommandswillcausealeakin S 1 .Therefore, S 1 alsoresults inaleakingstate. Hence,if addstwonewsubjectwithinitialrole r 1 ,thenwecangetanew sequencethatalsoresultsinaleakingstatebutcreatesonl yonesubjectwith initialrole r 1 .Therefore } (2 ;r 1 )istrue.

PAGE 70

60 InductionStep: Assume } ( k 1 ;r 1 )istrue( k> 2). Letthe k subjectsaddedby withinitialrolebe s 1 ;s 2 ;:::;s k .Wecanconstructasequenceofcommands, k whichdoesnotaddthesubject s 2 butstill resultsinaleakingstateusingtheconstructionmentioned above.Now,wehavea sequenceofcommandsthatadds k 1newsubjectswithinitialrole r 1 thatresults inaleakingstate. Since } ( k 1 ;r 1 )istrue,wecanreplace k withanewsequence 0 thatadds onlyonenewsubjectwithinitialrole r 1 andstillresultsinaleakingstate. } ( k 1 ;r 1 ) ) } ( k;r 1 ) Therefore,bytheprincipleofmathematicalinduction, } ( k;r 1 )istrueforall positiveintegervaluesof k .If k =0,thenwealreadyhaveasequenceofcommands thatresultinaleakingstateandaddsnomorethanonesubjec twithinitialrole r 1 Applyingtheaboveresultforeveryrole,wecanconstructas equenceof commandsthataddonlyonesubjectforeveryroleinthestate .Bylemma5,we canretainjustone CreateRole commandin ,thereforethenumberofrolesafter theexecutionofallcommandsisatmostonemorethanthenumb erofrolesin S .Thereforethenewsequencewillhaveatmost j T R j +1numberof AddSubject commands.Eachofthese j T R +1 j AddSubject commandsactivatesa NewSubject r attribute. Iftheinitialroleofthenewsubjectis r 0 ,thenthecorresponding AddSubject commandactivatestheattribute NewSubject r 0 Lemma7 Foragivenstate S ,object o ,andright ,ifthereexistsasequenceof commands thatresultinaleakingstate,thenthereexistsasequenceo fcommands 0 suchthat:

PAGE 71

61 0 alsoresultsinaleakingstateand 0 doesnotcontainmorethan N G ( S )GrantRight commands,where N G ( S )= 7( j T R j +1)( j T j +2)( j T j + j R j +2) Proof Weareinterestedonlyinthose GrantRight commandsthatgrant ADDSUBJECT,CREATEROLE,CREATEOT,GRANTRIGHT,ADDROLEBINDING ,and CHANGEOT rightsbecause: 1.BythedenitionofaccessrightleakproblemfortheDCS-A Cmodel, grantingsomerolearight 0 thatisnotoneofthesixteenDCS-ACsystem rightsor (therightweareinterestedin)doesnotaecttheaccessrig htleak problem. 2.Bylemma2,weareignoringallrevocationanddeletioncom mandsandby lemma3,wecanignoreall AddObject,AddAccess, and ChangeDP commands. Sincewearenotexecutingthesecommands,weneednotexecut e GrantRight commandsthatallowrolestoexecutethesecommands. Applyinglemmas2,3,5,and6,wecanconstructasequenceofc ommands 1 from thatresultsinaleakingstateandcontains: norevocationordeletioncommands no AddObject,AddAccess, or ChangeDP commands nomorethanone CreateRole andone CreateOT command nomorethan j T R j +1 AddSubject commands. Leteach GrantRight( r;r 1 ;t;ot; 1 ) commandactivatethe HasRight r 1 ;ot; 1 ;t attribute.Weknowthat 1 hastobeoneofthesevenrightsidentiedabove. Furthermore,ifa GrantRight command, j ,activatesaattributethatwasactive intheinitalstate S orwasactivatedbyanearliercommand i ,wecanignorethis commandsincetherearenorevocationordeletioncommands. Weconstructanew sequenceofcommands 0 from 1 thatdoesnotcontainany GrantRight command thatactivatesanalreadyactiveattribute.Sincewearethr owingawayonlythose

PAGE 72

62 commandsthataremeaninglessinthecontextofaccessright leak, 0 willstill resultinaleakingstate. Therefore,thenumberof GrantRight commandsin 0 isnomorethanthe numberof HasRight r 0 ;ot 0 ; 0 ;t 0 attributes(activeorinactive).Weknowthat: numberofpossiblevaluesfor r 0 is j T R j +1 numberofpossiblevaluesfor ot 0 is j T j +2 1 numberofpossiblevaluesfor 0 is7. numberofpossiblevaluesfor t 0 is j T j +2+ j R j (since t 0 2 T [ R ). Let S 0 S 0 .Thismeansthatthenumberof HasRight attributesin S 0 isnomore than7( j T R j +1)( j T j +2)( j T j +2+ j R j ). Therefore,thenumberof GrantRight commandsin 0 isnomorethan7( j T R j + 1)( j T j +2)( j T j + j R j +2). Lemma8 Foragivenstate S ,object o ,andright ,ifthereexistsasequenceof commands thatresultinaleakingstate,thenthereexistsasequenceo fcommands 0 suchthat: 0 alsoresultsinaleakingstateand 0 doesnotcontainmorethan N R ( S )AddRoleBinding commands,where N R ( S )=( j T R j +1)( j SUB j + j T R j +1) Proof Applyinglemmas2,3,5,6,and7,wegetanewsequenceofcomma nds 1 from whichalsoresultsinaleakingstate. Now,each AddRoleBinding( r;s;r 1 ) commandactivatesthe CanBind s;r attribute. Weconstructanewsequenceofcommands, 0 byremovingall AddRoleBinding 1 Wecancreateonenewroleandonenewobjecttype.Since T R T ,intheresultingstate, j T 0 j canbeupto2morethan j T j

PAGE 73

63 commandsthatactivateaattributethatwasalreadyactivei n S orwasactivated byanearliercommandin 0 Therefore,thenumberof AddRoleBinding commandsin 0 isnomorethanthe numberof CanBind attributesinthatinstanceofDCS-AC.Moreover, 0 doesadds nomorethanonenewroleandnomorethan j T R j +1newsubjects(bylemmas5 and6respectively). Therefore,thenumberof AddRoleBinding commandsin 0 isnotmorethan ( j T R j +1)( j SUB j + j T R j +1). Sinceweareremovingonlythose AddRoleBinding commandsfrom 1 thatdo notchangethestateofthesystem, 0 willalsoresultinaleakingstate. Denition An enablercommand isacommandthatactivatesacurrentlyinactive attribute.Therefore,forastate S Enabled ( S )isthesetofinactiveattributesfor whichanenablercommandexists.Denition Foragivenstate S ,wesaythatasequenceofcommandsismonotonic ifandonlyifthesequencecontainsonlyenablerand ChangeOT commands Corollary9 Foragivenstate S ,right ,andobject o ,ifthereexistsasequence ofcommands thatresultsinaleakingstate,thenthereexistsasequence of commands 0 thatismonotonicandresultsinaleakingstate. Lemma10 Foragivenstate S ,thesetofcommandsthatactivatetheattributesin Enabled ( S ) canbeexecutedinanyorderandtheresultingstatewillbeth esame. Proof Let ( n )bethepropositionthatforasequenceof n commands (= 1 ; 2 ;:::; n )thatactivate n enabledattributes,foranypermutation ofthe commands 1 ; 2 ;:::; n ,( S S ) ) ( S S )where isthepermuted sequenceofthecommandsin BASECASE: n =2(Thereareonlytwopermutations,1 ; 2and2 ; 1) = 1 ; 2 .Let 0 = 2 ; 1

PAGE 74

64 Let 1 activatetheattribute 1 and 2 activate 2 .Let S S and S 1 S 0 S isthestateobtainedastheresultofaddingtheattributes 1 and 2 to S and S 0 istheresultofaddingthesametwoattributesto S ) S = S 0 .Hence (2)istrue. InductionStep:Assumethat ( k )istrueforall k (2 k
PAGE 75

65 Case2: 0 n 6 = n Let ( n )= 0 j (1 j
PAGE 76

66 8 r 2 T R add NewSubject r to InactiveAttributes 8 r 2 T R ; 8 ot 2 T; 8 0 2 R; 8 t 2 ( T [ R ) if HasRight r;ot; 0 ;t = 2 Active ( S )thenadditto InactiveAttributes 8 s 2 SUB; 8 r= 2 f r ( s ) ; add CanBind s;r to InactiveAttributes Theabovestepcanbecompletedin O ( N ( S 0 ))time.Oncewehaveidentiedthe inactiveattributes,wecanproceedtothenextstep. SaturationStepWewillnowsaturatetheinstance,i.e.,activateeveryattr ibutethatcanbe addedtillnothingmorecanbeadded.Startingfrom S 0 ,weexecutealltheenabled commandsinthecurrentstate( S i )toreachanewstate( S i +1 )andrepeatthisstep tillnomoreattributescanbeactivated. Bylemma10,wecanexecutethecommandsthatenabletheattri butes in Enabled ( S i )inanyorder.Weexecutethemalltakingcareofthefollowin g book-keepingsteps: Ifthe NewRole attributeisactivated,then: 1.Forallsubjectscurrentlyinthesystem,addacorrespond ingattribute ( CanBind s;r new where s isthesubjectand r new isthenewrolecreated). 2.Forallobjecttypes,rights,andtargets,add HasRight r new ;ot; 0 ;t to InactiveAttrinutes Ifthe NewOT attributeisactivated,thenaddcorresponding HasRight attributes. Ifa NewSubject r 0 attributeisactivated,thenforallroles r 1 currentlyinthe systemotherthan r 0 ,add CanBind s new ;r 1 to InactiveAttributes ,where s new isthenewsubjectadded. Removeallattributesthatareactivatedfrom InactiveAttributes oncethe enablingcommandisexecuted. Repeattheabovesteptillwereachastate S s forwhich Enabled ( S s )= ; Atthispointthesystemissaturatedandwecannotactivatea nynewattribute.

PAGE 77

67 Sincethereareatmost N ( S 0 )attributes,thissteptakes O ( N ( S 0 ) 2 )time.Wenow proceedtothenextstep. TypeCheckingStepLet S s =( A 0 ;R 0 ;T 0 ;T 0 R ;SUB 0 ;OBJ 0 ;f 0 o ;f 0 r ).Now,wecantacklethe ChangeOT commandasfollows:Werstidentifythesetof leakingtypes LT andthencheckif o canbechangedtoanyofthesetypes. LT = f ot j ot 2 T 0 ^ S s ;;ot S 0 ;;f o ( o ) 6 = ;g Wecanidentifytheelementsoftheset LT in O ( j T jj SUB jj T R jj R j )time. Oncewehaveidentiedtheelementsof LT ,wecancheckifthetypeof o can bechangedtoanyofthesetypesbycreatinga Typechange graph, G =( V;E ) where G isadirectedgraphsuchthat V = T 0 T 0 R and E = f ( ot 1 ;ot 2 ) j ot 1 ;ot 2 2 T 0 ^9 r 2 T 0 R suchthat( CHANGEOT;ot 1 ;dp ) 2 A 0 [ r;ot 2 ] g Thatis,thenodesin G correspondtoobjecttypesin S s andthereisanedgefrom ot 1 to ot 2 ifsomerolecanchangetheobjecttypeofanobjectfrom ot 1 to ot 2 Now,theproblemofdecidingiftheobjecttypeof o canbechangedtooneof the leakingtypes isreducedtoagraphreachabilityproblemwhichcanbesolve d byperformingadepthrstsearchstartingfrom f o ( o )(theobjecttypeof o inthe initialstate)andcheckingifthecurrentnodeisin LT .Ifoneofthetypesin LT canbereachedfrom f o ( o ),thenthereisasequenceofcommandsthatcanleadto aleakingstateelsetheredoesnotexistasequenceofcomman dsthatresultina leakingstate. Thegraphcanbeconstructedin O ( j T j 2 )timeandthegraphtraversalalso takesthesameamountoftime.Thetypecheckingsteptakes O ( j T jj SUB jj T R j j R j )time.

PAGE 78

68 Ofthethreestepsmentionedabove,thesaturationsteptake sthemostamount oftimeandhencetheARLproblemcanbedecidedin O ( N ( S ) 2 )time. 5.5 Summary Inthischapter,werestrictedtheDCS-ACmodelandsawhowto decidein polynomialtimewhetheragivenstatecouldresultinaleaki ngstatebyexecuting anarbitrarysequenceofcommandsifvotingisdisallowed.W eassumedmonotonicityandprovedthatthereisapolynomialupperboundon thenumberof meaningfulcommands(i.e.,commandsthatwhenexecutedres ultinachangeof state).Usingthis,weconstructedadirectedstategraphwh ereeachnodeofa graphcorrespondstoastateandtwonodesareconnectedifth ereisacommand whichwhenexecutedonthestartingstateresultsintheendi ngstate. Wethenidentiedthosestateswhichresultinaleakandifth ereisapath fromthenodecorrespondingtothestartingstatetoanodeco rrespondingtoone oftheleakingstates,thenthesystemcanleaktheright.The commandsthatwill resultinaleakingstateisthesequenceofcommandsthatcor respondtotheedges alongsuchapath.Hencetheaccessrightleakproblemforthi srestrictedversionof theDCS-ACisdecidableinpolynomialtime.Inthenextchapt er,wewillseehow tosolvethisproblemifvotingisallowed.

PAGE 79

CHAPTER6 TRUSTANDVOTING 6.1 Introduction InthischapterwewillanalyzethesafetyoftheDCS-ACmodel wheresubjects areallowedtovote.Sincewecannotdeterministicallypred icthowthesubjectswill votewewillapproachtheproblemfromadierentangle.Weas signanumerical value, trust-level ,toeachsubjectwhichrepresentstheamountofresourcesa maliciousentityneedstoexpendinordertomakethesubject voteagainstthe bestinterestsofthegroup.Wewillidentifythreesimpleap proachesonhow subjectscanbe\turned"andanalyzetheaccessrightleakpr oblembasedonthese approaches. 6.2 TrustandTrust-Worthiness Oneofthekeyquestionsinanyvoteis\Howmuchcanwetrustth evotersto maketherightdecision?".Therearemanyaspectsinvolvedi n trust ,someofwhich areidentiedbelow: understandingofandbeliefinthemissionofthegroup sounddecision-makingprocess rationalbehavior susceptibilitytoblackmailorbribery protectionofidentity Dierentgroupsgivedierentweight-agestotheseandothe raspectsoftrust. Basedonthese,weassigna trustlevel toeachsubject s denotedby ( s ),whichis theamountofresourcesrequiredtoturnthesubject s .Ourmainconcernhereis 69

PAGE 80

70 thesusceptibilityofthesubjectstomakeawrongdecision. Bywrong,wemeana decisionthatisnotinthebestinterestsofthegroup.Thesu bjectmightdecideto dothewrongthingbyintention(needlesstosay,ourtrustle velinsuchaperson wouldbelow).Weassumethatweknowthetrustlevelofallsub jectsinthegroup andthatthistrustlevelisconstant.Forthesakeofsimplic ity,wewillassumethat eachsubjectinthesystemhasauniquetrustlevel. ( s 1 )= ( s 2 ) s 1 = s 2 Notethatwedonottalkabouthowthetrustlevelsareassigne dasthismayvary fromgrouptogroupdependingonthegroupproirities.Wesho uldconsiderallthe factorsmentionedaboveandotheraspectsthatthegroupmig htfeelimportant. Wecoulduseareputation-basedtrustmanagementschemelik ethemodeldened byShmatikovandTalcott[57]orafeedback-basedschemesim ilartotheoneused ineBay[58].Inoursafetyanalysis,wewillassumethateach subjecthasaunique trust-levelthatisassignedoutsideoftheDCS-ACandiscor rect. 6.2.1 ApproachingTrust Therearemanywaysoflookingattrustandsusceptibility.T hekeyideain hereistolookattrustlevelastheamountofresourcesneede dtomakeaparticular subjectorgroupofsubjectsvoteinamannerthatisagainstt hebestinterestsof thegroup.Withthisinmind,wewillnowlookatthreedieren tapproachesto analyzingsusceptibilitythroughtrustlevelsasdenedhe re. Ad-ApproachIntherstcase,ifsomeonecanmakeasubject s 1 makeadecisioninacertain way,thenthatpersoncanmakeanyothersubject s 2 makethesamedecisionin thesamewaywithnoadditionaleortif ( s 1 ) ( s 2 ).Wewillcallthisthe Advertisementapproach (ad-approach)sincewecanlookatthisaspayingforan advertisementwhichallthevoterswillsee.Iftheadisgood enoughtoconvince s 1

PAGE 81

71 then s 2 willalsobeconvinced.Wewilluse A ( s )todenotethetrustinasubject s underthead-approach.Itmustbenotedthatinthisapproach ,one\ad"willcover alldecisionsrequired. Pay-As-You-GoApproachItispossibletobribeorcheatthevoterstoturnonedecisio natatime.This meansthatmoreresourcesarerequiredtoconvincethesamev oterifhe/shegets toparticipateinanotherdecisiondowntheline.Wewillcal lthisthePay-as-you-go approach(P-approach)anduse P ( s )todenotethetrustinasubject s underthis approach. HonestPoliticianApproachInthewordsofformerU.S.senatorSimonCameron,\anhonest politician isonewhowhenbought,staysbought".Thekeyideabehindthi sapproachis theassumptionthatallthesubjectsare\honestpolitician s".Inthiscase, ( s )is theamountofresourcesthatsomeonehastoexpendtomake s 1 makeacertain decision(thatpersonhastoexpend ( s 2 )additionalresourcesto\turn" s 2 ).In addition,oncebought,thesubjectstaysboughtandnoaddit ionalresourcesare requiredifthesubjectgetstovoteonanotherdecisionlate r.Wewillcallthisthe HonestPoliticianapproach (H-approach).Wewilluse H ( s )todenotethetrustin asubject s undertheH-approach. HybridApproachTheapproachesmentionedaboveareverysimplisticandinre ality,amixture oftheseapproachesismorelikelytobeused.Thesethreeapp roachesprovidea startingpointfordiscussionandaremoreusefulinintrodu cingtheideasdiscussed here.Wehopetoextendthistomodelreal-lifeapproachesin thenearfuture.We willconcentrateonlyontherstthreeapproacheshere.

PAGE 82

72 6.2.2 DecisionTemplates Inordertoclarifyhowdecisiontemplateswork,letuslooka tasimpledecision template.Here,allvotesareweightedequallyandparamete rslikequorum,voting period,percentageofvotesrequiredfora yes voteareallpartofthetemplate. Eachsuchvotingtemplateisrepresentedbythetuple( V R ;k;q;t d ;y d )where, V R isasetofrolesthatcanparticipateinthevote, k isanumberbetween0and1whichrepresentstheratiobetween the minimumnumberof yes votesrequiredtopassandthetotalnumberof participatingvoters, q isanothernumberbetween0and1whichrepresentsthequorum (i.e.,ratio ofminimumnumberofvotersrequiredtoparticipateandthet otalnumberof voters), t d isthetimedurationoverwhichthevoteisactive(example:2 days),and, y d isthedefaultdecisionwhichisreturnedifthedeadlinehas passedandthe quorumhasnotyetbeenreached. Inaddition,thesetofdecisionpointers, DT ,alsocontainsan Always-Yes template ( d yes )whichalwaysreturns yes .Thereasonforthisisthatmanydecisionsdonot requireavote.Anexampleofthetemplateis( f Faculty;Staff g ; 0 : 5 ; 0 : 8 ; 2days ;N ). Inthistemplate,allsubjectswhocanbindtotherolesFacul tyandStacanparticipateinthevotewhichrequiresasimplemajoritywithat least80%voter turnout.Ifafter2days,thequorumisnotreached,aresulto f No isreturned.If aftertwodays,atleast80%ofthevotershavecasttheirvote s,thena Yes decisionisreturnedifatleasthalfthevotescastare yes votes,ifnotaresult No is returned.

PAGE 83

73 Inourmodel,eachsubjectgetstocastonevoteevenifhe/she canbindto morethanonerolein V R .Adiscussionoftheactualworkingofthevotingmechanismisbeyondthescopeofthisworkandwewillrestrictour selvestoabriefdescriptionofthelife-cycleofavote.Whenagroupdecisioni scalledfor,weinstantiateavote v basedonthetemplate. V =( E v ;Vote v ;Voted v ;T v ;k v ;q v ;default ) where: E v isthesetofalleligiblevoters Vote v isamappingbetweeneachsubjectandhis/hervoteinthedeci sion. Thepossiblevaluesare D (defer), Y (Yes), N (No),and, A (abstain) Voted v isthesetofalleligiblevoterswhohavecastavalidvote( Y;N; or, A ) T v isthedeadlineforthevotewhichisobtainedbyadding t d tothetimeof voteinitialization. k v isthevalueof k inthetemplate q v isthevalueof q inthetemplate default isthevalue y d ofthetemplate E v = f s 2 SUB j V R \ f r ( s ) 6 = ;g Vote v : E v !f Y;N;A;D g Voted v = f s 2 E v j Vote v ( s ) 2f Y;N;A gg Initially,sincenobodyhasvotedyet, 8 s 2 E v ;Vote v ( s )= D Whenaneligiblevoter, s ,castsavalidvote( Y;N; or, A ),his/hervoteis updatedin Vote v and s isaddedto Voted v .Whenthedeadline T v isreached,all newvotesarerejectedandadecisionisreached.

PAGE 84

74 Weidentifythefollowingsets: Y v = f s 2 E v j Vote v ( s )= Y g N v = f s 2 E v j Vote v ( s )= N g A v = f s 2 E v j Vote v ( s )= A g Werstcheckforthequorum, j Voted v j j E v j q v ifthisisfalse,wereturnthedefaultdecision.Ifeverysub jectwhovotedhas abstained,( j Y v j + j N v j =0),wereturnthedefaultdecision.Next,wecheckif enoughyesvoteshavebeencast. j Y v j j Y v j + j N v j k ifthisistrue,wereturnyesandwereturnnootherwise. 6.3 ARLProblemAndStates Sinceexcecutionofcertaincommandsisdependentonthesub jectswhoare allowedtovote,wehavetofactorourtrustinthesubjectswh iledecidingthe safetyofthesystem.Withthisinmind,weredenetheaccess rightleakproblem foraDCS-ACsystemwithvotingasfollows:Denition Foragivenstate S 0 ,object o ,right ,and,budget,theaccess rightleakproblem(ARL)isadecisionproblem,doesthereex istasequenceof commandsin S 0 withtrustlevellessthanthatresultsinaleakingstate. ARL f j9 suchthat S 0 S t and S t ;;f 0 o ( o ) S 0 ;;f o ( o ) 6 = ; and( ) g where( )isourtrustinthesequenceofcommands byapplyingoneofthe threeapproaches.

PAGE 85

75 Inotherwords,canamaliciousparty,withagivenbudget,co rruptenoughvoters toenableanunauthorizedsubjectaccesstoanobject. Let N v ( S 0 )denotethenumberofcommandsthatcanbeexecutedonthe initialstate S 0 andallitsdescendentstates.Weareonlyconcernedwiththe commands CreateRole CreateOT GrantRight AddSubject AddRoleBinding ,and ChangeOT (thisisduetoCorollary4).Asproveninthelemmas3,5,6,7, and8, thetotalnumberofsuchcommandsisbounded. N v ( S 0 ) 1+1+( j T R j +1)+ N G ( S 0 )+ N R ( S 0 )+( j T T R j +1) 4+ N G ( S 0 )+ N R ( S 0 )+ j T j Denition ForagivenDCS-ACsystemwithinitialstate S 0 ,wedenethesetof allpossiblereachablestates, c S 0 asfollows: c S 0 = f S j ( S = S 0 ) ( 9 suchthat S 0 S ^ S 0 2 c S 0 ) g Thesizeofthissetisdependentonthenumberofcommandstha tcanbeexecuted ontheinitialstateanditsdescendants.Eachstatecanbere presentedbya N v ( S 0 )bitnumberwhereeachbitcorrespondstoaparticularattrib ute.Thebitis1ifthe correspondingattributeisactiveinthatstateand0otherw ise. j c S 0 j 2 N v ( S 0 ) 6.4 TrustAnalysisofDCS-AC LetusnowprovethetractabilityoftheARLproblemforaDCSACsystem. Asmentionedearlier,wewillusethetrust-worthinessofsu bjectstodecideonthe trust-worthinessofthesystem. 6.4.1 StateGraph Wewillnowconstructadirectedgraph G S 0 =( V;E )whichcorrespondstoa DCS-ACsystemwiththeinitialstate S 0 (Wewillcallthisgraphthe StateGraph of S 0 ).Thesetofvertexesis V = c S 0 andthereisanedgefromvertex S i to S j

PAGE 86

76 labeled( ;r )if S j istheresultwhenasubjectboundtotherole r executesthe command in S i Sinceeachstatehasauniquesetofproperties,therecannot bemorestates thanthetotalnumberofpropertiesinanygivenpath. j V j = j c S 0 j 2 N v ( S 0 ) Inanygivenstate,wecannotexecutemorethan N v ( S 0 )commandsandeachof thesecommandscanbeexecutedbyatmost j T R j roles. j E jj V jj T R j N v ( S 0 ) j T R j N v ( S 0 ) 2 N v ( S 0 ) Ifweuseanadjacencylist,wecanconstructthegraphin O ( j E j ).Therefore,the graphcanbeconstructedin O ( j T R j N v ( S 0 ) 2 N v ( S 0 ) )time. Let S L denotethesetofallleakingstates. S L = f S i 2 c S 0 j S i ;ot; S 0 ;f o ( o ) ; 6 = ;g Asmentionedinthepreviouschapter,wecanidentifytheele mentsof S L in O ( j V jj T jj T R jj SUB jj R j )time. BeforelookingatthethreeapproachestotrustfromtheDCSACpointof view,letusdeneafewusefulsets.Foradecision d =( V R ;k;q;y d ;t d ),let W ( d ) bethesetof ( d )weakest(intermsofsusceptibility)voters.Thesevoters arethe mostlikelytovoteagainstthebestinterestsofthegroup. W ( d )= f s j s 2 V ( d ) ^ @ s 1 ;s 2 ;:::;s ( d ) 2 V ( d )suchthat i 6 = j s i 6 = s j ^8 i 2 [1 ; ( d )] ( s i ) < ( s ) g

PAGE 87

77 Foracommand ,let W c ( )denotethesetofvotersthataremostlikelytovote againstthebestinterestsofthegroup. W c ( )= W ( d ) where d isthedecisionthatguardsthecommand.Moreover,somesubj ecthas toissuethecommandinordertoexecuteit.Therefore,ourtr ustinacommand hastoincludeourtrustintherolethatcanissuethecommand .Let r ( r )denote ourtrustinarole r .Ourtrustinaroleisthesameasourtrustintheleast trustworthysubjectthatcanbindtothatrole. r ( r )= min f ( s ) j s 2 SUB and r 2 f r ( s ) g Needlesstosay,ourtrustinthedecisionpointer d yes is0. 6.4.2 Ad-Approach Let A ( d )denoteourtrustlevelinadecision.Inad-approach, A ( d ),isthe maximumtrustlevelofallthevotersin W ( d ). A ( d )= max f A ( s ) j s 2 W ( d ) g Let d bethedecisiontemplatethatguardsacommand .Iftherightthatguards isenabled,thenwecantrust onlyasfaraswecantrust d .Let A ( )denote ourtrustlevelinacommand .Here,wearelookingatthecommandbyitself withnoprior\history".Theremaybemorethanonerolethatc anissuethe command.Let r l betheleasttrustworthyofalltherolesthatcanexecutethe command. A ( )= max ( A ( d ) ;r ( r l ))

PAGE 88

78 Now,foragivensequenceofcommands (= 1 ; 2 ;:::; n ),let A ( )denotethe trustlevelin usingthead-approach. A ( )= A ( i )suchthat 8 j 2 [1 ;n ] ; A ( j ) A ( i ) Inordertodeterminetheminimumcostrequiredtoensureale akingstate,we havetondapathfrom S 0 to S L thathastheleast A value.Weachievethisby doingamodieddepthrsttraversalonthegraph. FunctionDFT( v ) //Thearray visited []isglobalandinitiallysettofalse //Thevalue MinCost A ( S 0 )isinitially 1 //Thestackisinitiallyempty. 1. visited [ v ]= true 2.if v = S L then (a)let bethesequenceofcommandsinthestack (b) c = A ( sigma ) (c)if( c 2 ARL MinCost A ( S 0 ) Theabovedepth-rsttraversalcanbecompletedin O ( j E j )time.HencetheARL problemusingtheAd-approachcanbesolvedin O ( j T R j 2 N v ( S 0 ) )time.

PAGE 89

79 6.4.3 Pay-As-You-GoApproach Let P ( d )denoteourtrustlevelinadecision.Inthisapproach, P ( d ),isthe maximumtrustlevelofallthevotersin W ( d ). P ( d )= X s 2 W ( d ) P ( s ) Let d bethedecisiontemplatethatguardsacommand .Iftherightthatguards isenabled,thenwecantrust onlyasfaraswecantrust d .Let P ( )denote ourtrustlevelinacommand .Here,wearelookingatthecommandbyitself withnoprior\history".If r l istheleasttrustworthyrolethatcanissuethe command P ( )= P ( d )+ r ( r l ) Now,foragivensequenceofcommands (= 1 ; 2 ;:::; n ),let P ( )denotethe trustlevelin usingthethisapproach. P ( )= X i 2 P ( i ) Inordertodeterminetheminimumcostrequiredtoensureale akingstate, wehavetondapathfrom S 0 to S L thathastheleast P value.Weachievethis byusingthesingle-sourceshortestpathalgorithmstartin gfrom S 0 .Foreachedge ( S i ;S j ),theedgeweightis P ( )where isthelabeloftheedge. Lettheminimumcosttoreach S L be MinCost P ( S 0 ). 2 ARL MinCost P ( S 0 ) Hereagain,thesinglesourceshortestpathtakes O ( j E j )time(sinceweareusing adjacencylists)andhencetheARLproblemcanbesolvedusin gtheP-Approachin O ( j T R j 2 N v ( S 0 ) )time.

PAGE 90

80 6.4.4 HonestPoliticialApproach IntheHonestPoliticalapproach,asubjectonce\bought"st aysbought.There aretwoproblemswithapplyinganalgorithmsimilartotheon esusedfortheother approaches.Considerthetwodecisions d 1 and d 1 andtwosubject s 1 and s 2 such that:(i) s 1 and s 2 arebothvalidvotersfor d 1 and s 2 isavalidvoterfor d 2 ,and(ii) s 1 isamongthepotentiallyweakvotersin d 1 while s 2 isnot. s 1 ;s 2 2 Voters ( d 1 )and s 2 2 Voters ( d 2 ) s 1 2 W ( d 1 )and s 2 = 2 W ( d 1 ) 1.If s 2 2 W ( d 2 ),i.e., s 2 isamongthepotentiallyweakvotersin d 2 ,theninstead ofspendingresourcesonboth s 1 and s 2 ,amaliciousentitycan\buy"only s 2 andstillgetboththedecisionsthussavingontheresources requiredtobuy s 1 2.If s 2 = 2 W ( d 2 )butthereexistsasubject s 3 2 W ( d 2 )suchthat H ( s 1 )+ H ( s 3 ) > H ( s 2 ),thenitwouldbecheapertobuy s 2 insteadofboth s 1 and s 3 Theabovetwoscenarioscanbeextendedtoanynumberofsubje ctsandany numberofdecisionssuchthatreplacingasinglesubjectcan leadtoacascading eectonotherdecisionsifthesubjectbeingreplacedisamo ngtheweakvotersin theotherdecisions. Aswecansee,themainproblemiswithvoterswhocanparticip ateinmore thanonedecisioninasequenceofdecisions.Oursolutionto thisproblemisvery simple.Ifasubject s 1 withatrustlevelof H ( s 1 )participatesin n ( < j j )decisions inasequenceofcommands ,thenlet H ( s 1 )denotethecostperdecisioninthe sequence. H ( s 1 )= H ( s 1 ) n

PAGE 91

81 Lettheset V ( )denotethesetofallvotersinallthedecisionsin V ( )= [ i 2 Voters ( d i )where d i isthedecisionthatguards i Let W s ( )denotetheminimalsetofvotersrequiredtogetallthedeci sionsin Letusnowlookatanalgorithmtondthisset. Function W s ( ) //Returnstheminimalsetofvoters//Initially W s isanemptyset 1.sortallsubjectsin V ( )accordingtotheir H 2.Foreach i in (a)Let d i denotethedecisionguarding i (b)Let count bethenumberofvotersin i alreadybought. count = j Voters ( d i ) \ W s j //Wenowhavetond ( d i ) count eligiblevoters (c)while count< ( d i ) i.Find s 2 Voters ( d i ) W s withsmallest H ii.Add s to W s iii. count = count +1 3.Return W s Now,let H ( )denotethetrustlevelin usingthisapproach. H ( )= X s 2 W s ( ) H ( s ) Inordertodeterminetheminimumcostrequiredtoensureale akingstate,we havetondapathfrom S 0 to S L thathastheleast H value.Weachievethisby usingtheDFTalgorithmgivenabove(wecalculate H and MinCost H insteadof A and MinCost A 2 ARL MinCost H ( S 0 )

PAGE 92

82 Weknowthatthelengthofthelongestpossiblesequenceis N v ( S 0 ).Wealso knowthatthemaximumnumberofvotersthatcanparticipatei nadecisionis j SUB j .Hence,wecanndthe H foranysequenceofcommandsin O ( j SUB j N v ( S 0 ))time.Therefore,wecandecidetheARLproblemusingtheHapproachin O ( j SUB j N v ( S 0 ) j T R j 2 N v ( S 0 ) )time. 6.5 Summary InthischapterwelookedatthesafetyanalysisoftheDCS-AC modelwith voting.Weassumedthateachsubjecthasanumerical trust-level andintroduced threeapproachestotrustandsuseptibilitynamely,Ad,Hon estPoliticianand Pay-As-You-Go.Wethensawhowtodeterminethetrustinavot e,acommand andasequenceofcommandsbasedoneachofthesethreeapproa ches.Withthis asbuildingblocks,weanalyzedthesafetyoftheDCS-ACmode lwithamodied accessrightsleakproblem. ThekeyideaintheAd-approachisthatifamaliciousentityc anconvincea subject, s ,tovoteinamannerthatisnotinthebestinterestsofthegro up,then thatentitydoesnotneedanyadditionalresourcestoconvin ceanothersubject whosetrustlevelislessthanthatof s .InthePay-As-You-Goapproach,each subjecthasaspecicamountofresourcesrequiredtomakehi m/hervoteina mannerthatisnotinthebestinterestsofthegroupandthema liciousentity hastoexpendadditionalresourcesforeveryothersubjects andalsoforthesame subjectifhe/sheisrequiredtovoteagaininanotherdecisi on. ThemostcomplexofthethreeapproachesistheHonestPoliti cianapproach, inwhich,asubjectis\bought"fortheentiresetofdecision s.Thiscomplicates thesafetyanalysissinceamaliciousentityisbetterospe ndingresourcesona moreexpensivesubjectwhocanparticipateinmanydecision sasopposedtoalarge numberoflesstrustworthysubjecteachofwhomcanparticip ateinonedecision.

PAGE 93

83 Inordertosolvethisproblem,welookedatcostperdecision whiledecidingthe leastexpensivesetofvoters. Ineachofthesethreeapproaches,weconstructadirectedgr aphwhichwe callstategraphandusegraphtraversalalgorithmstosolve theaccessrightleak problem.Thereisacombinatorialexplosionofthenumberof statesandweproved thedecidabilityoftheARLproblemineachofthesethreeapp roachesbyproviding exponentialtimealgorithms.

PAGE 94

CHAPTER7 NEXTSTEPS Themodelaspresentedispowerful,rexibleandscalable.Ho wever,more workneedstobedoneinordertomakethismodelmodelreal-li fepolicies.Some oftheseareenhancingthecommandsinthemodel,extendingt hemodelitselfto allowsubject-to-objectprivilegedenitions,incorpora tingarolehierarchyand time-limitedaccessrights.Asmentionedearlier,amajorf eatureoftheDCSmodel istheuseofdecisiontemplateswhichcanprotectagainstsi nglemalicioususer attacks.Furtherworkneedstobedoneinanalyzingmulti-us ercollusionattacks. 7.1 EnhancingDCSCommands Therearesomeadditionsthatcanbedonetoimprovethemodel .Thecommandsasdescribedhereareallmono-operational(i.e.,per formonlyoneprimitive operation).Inmanycases,thesubjectcreatinganewobject hassomespecial rightswithrespecttothatobject,i.e.,thecreatorhasthe righttoread/writethe objectorgrantrightstoothers.Whilesomeonehasthe GrantRight privilegefor objectsofthattype,thisissueismorecriticalforcreatio nofnewrolesandobject types.Ifsomeonecreatesanewroleorobjecttype,theusabi lityofthisnewroleor objecttypeisseverelyrestrictedifnoonehastherighttoa llowsubjects/objects tobindtothatrole/objecttype.Thereforeanadditionalop erationneedstobe performedthatallowsthecreator'srolesomebasicrights. Thesafetyanalysisneedstoberevisitedsincetherolesand objecttypeshave pedigreeandwewillhavetofactorthisintotheanalysis.Ho wever,theresulting systemwouldbemoreusable. 84

PAGE 95

85 7.2 SpecialRelations Wewouldliketobeabletospecifysubject-to-objectlevela ccessrights,for example,eventhoughallprogrammershavetherighttoreada nycode,onlythe programmerwhowroteaparticularclasshastherighttomodi fyit.Wecanimplementthisbycreatinganewobjecttypeoranewroleforeachcl ass/programmer. Thisisinecientandasimplerwayistouse SpecialRelationships .Thesearea mappingfrom(subject,object)pairstoroles.( f s : SUB OBJ T R ).Wecan denearole ClassWriter andspecify f s ( programmer;class )= f ClassWriter g foreachclass.Now,eachtimeanaccessrequestismade,wesh ouldcheckforany specialrelationsbetweenthesubjectandtheobjectbefore checkingfortherole andobjecttype(thereasonbeing,specialrelationsareusu allymore\powerful" thanregularrolesforthatparticularobject).Thisclearl ychangesthedenitionof allthecommandsandthesafetyanalysisbutprovidesaveryu sefulwaytospecify ner-grainedaccesscontrol. 7.3 RoleHierarchy OneofthemajordierencesbetweentherolesasusedintheDC Smodel andRBACis rolehierarchy .Wecanimplementrolehierarchybymaintaininga partialorderingoftherolesintheformofadirectedgraph, G R =( V;E )where V T R and( r 1 ;r 2 ) 2 E ifandonlyif r 1 inheritsalltherightsfrom r 2 .Whenan accessrequestismade,werstcheckforspecialrelations, failingwhichtherights oftheuser'sroleischecked.Ifthisfails,abreadthrstse archisperformedon G R withthemodecorrespondingtotheuser'sroleasthestartin gpoint.Ateachnode visited,thecorrespondingroleischeckedfortherighttop erformtherequested access.Weusebreadthrstsearchinsteadofdepthrstsear chsinceroleshigher uponthehierarchyaremore\powerful"thanthosefurtherdo wnthegraph.It mightbeusefultoconstraintheroleorderingtobeacyclicf orsecuritypurposes. Thiscanbeensurediftherolehierarchycanbespeciedonly whentheroleis

PAGE 96

86 denedandcannotbechanged.Thisistoorigidandcanhurtth eutilityofthe model.Therefore,wecanallowthehierarchytobechangedan ytimebutthegraph couldbecheckedforcyclesbeforecommittingthechange.Si ncetherolegraphis notlikelytochangefrequently,thisisanacceptableoverh eadonperformance.The additionofrolehierarchyincreasestheoverheadwhilesea rchingforalltheusersin arole 1 7.4 Use-CasesandScenarios Oneofthemostimportantstepsinprovingtheusabilityofth emodelisto identifyvariousscenariosandshowhowthismodelcanbeuse dthere.Forexample, wecanmodeltheCISEdepartmentintermsofsubjects,roles, objects,etc.and showhowwecanusetheDCSmodel(OnlyPh.D.candidatescanre gisterfor doctoralresearchcreditsandaPh.D.studentcanbindtothe Ph.D.candidaterole ifhis/hersupervisorycommitteechairnominateshim/hera ndallthemembers ofthecommitteeagree).Oneotherscenariowecanconsideri stheoperationsof alargeorganizationlikeIEEE.TheideaistoshowhowtheDCS modelcanbe usedinthesescenarios,startingfrombootstrappingthesy stemtogettingitfully functional. 7.5 Multi-UserCollusionAttacks TheuseofdecisiontemplatesmakestheDCSmodelverypowerf ulandhelps minimizetheroleofthelocaldomainsystemadministrators .Thisalsoopensupan interestingareaofresearch,multi-usercollusionattack s.Foragivenstateofthe system,ifagroupofsubjectswanttotipavote(withagivend ecisiontemplate, dp 1 )intheirfavor,andtheytrytodosobyallowingsomeoftheir buddies to bindtosomeroleswhichparticipateinthatvote,howmany AddRoleBinding 1 Wemayhavetondthelistofalluserswhocanbindtoarolefor votingand noticationpurposes.

PAGE 97

87 commandsdotheyneed?Ifthe AddRoleBinding commandsrequireanothervote (say, dp 2 ),theywillhavetobeabletocarrythosevotesinordertoget afavorable resultfor dp 1 .Thequestionis,foranygiven dp 1 and dp 2 ,theminimumnumberof \conspirators"requiredtowinthevote dp 1 istheminimumnumberrequiredtowin dp 2 .Amorecomplexcaseiswhenyouneedtocontroltwovotes, dp 2 and dp 3 to win dp 1 7.6 Time-LimitedAccess Anotherusefuladditionis Time LimitedAccess ( TLA ) 2 .Insteadof returningasimpleyes/noanswer,thedecisionpointercoul dreturnthetimefor whichtheaccessisvalid.Iftheaccessisdenied,thenitret urnsazeroelseit returnsthetimeforwhichtheaccessisvalid.Duringthatti me,theuserisgranted accesstotheobjectwithoutstartingthedecision-makingm echanism.Thisisvery usefulfor\proxies"orsubstitutes.Forexample,iftheuse r Alice whocanbindto therole Instructor isleavingtownforaweek,shecanallow Bob (boundtorole TA )totemporarilybindtotherole Instructor .Wecanalsocreateanewrole sub Instructor withasubsetoftherightsof Instructor .Forexample, Bob can notassigngradestothestudents.InordertoimplementTLA, weneedaseparate datastructurethatstoresthetimeperiodofvalidity.TheT LAstructureshould eitherperiodicallyremoveexpiredentriesorcheckforval idityeachtimeanaccess isrequested.Thisagainmightincreasetheturn-aroundtim eforanaccessrequest butontheotherhand,itcanbeveryusefulsinceitcanhelpav oidfrequentcallsto timeconsumingdecisionpointers. 2 TLAcouldalsostandforThree-LetterAcronym

PAGE 98

CHAPTER8 CONCLUSION TheaccesscontrolmodeldescribedhereisdesignedfortheD istributed ConferencingSystemversion2(DCSv.2).However,thismode lcanbeusedin anydistributedsystemthatrequireshighlyavailableacce sscontrolservicesand userdrivendecisionmakingcapabilities.Wehaveformally speciedthemodel andanalyzeditsvariousadvantageswithrespecttoexistin gmodels.Wehavealso providedalgorithmstomapastateinaDCSsystemtoanequiva lentHRUstate and viceversa andprovedthattheaccessrightleakageproblemisdecidabl einNP time.Thesoftwareprojectexampleillustratestheusefuln essofthismode.Asseen inchapterfour,thismodelsatisesmanyinterestingprope rtiesofaccesscontrol systemsandsupportsuser-denedvotingtemplates.Thepre senceofdecision templatesallowsthemembersofthegrouptodecideontheiro wngrouppolicies andvoteonimportantdecisions.Thisdemocraticapproache nsuresautonomyfor thegroupsandprovidesgreaterrexibilityintermsofacces scontrol. Wehaveshownthatthemodelisprovablysafeintermsoftheac cessrights leakproblem.Sincesomeoftheaccesscontroldecisionsare madethroughvoting, thesecurityofthesystemdependsonourtrustinthevoters. Thisleadsustothe threeapproachestotrustthatarementionedhere.TheAd-Ap proachissimplistic andtheanalysisisverystraightforward.ThePay-As-You-G oapproachisslightly morecomplicatedandtheHonest-Politicianapproachisthe mostdicultofthe threetoanalyze.Inallthreeapproaches,wereducedthepro blemtosomeformof graphreachabilityandhaveprovidedalgorithmicsolution stothesame. Thistypeofanalysiscanhelpusprepareagainstmulti-user collusionattacks andisheavilydependentonaccuratelyassigningtrust-lev elstoallthesubjects. 88

PAGE 99

89 Inreality,ahybridofthesethreeapproachesislikelytobe usedandthiswork providesastartingpointforfurtherworkinthisarea.Inco nclusion,themodel presentedhereisscalable,useful,provablysecure,andve ryrexible.

PAGE 100

REFERENCES [1]B.W.Lampson,\Protection,"in Proceedingsof5thPrincetonSymposiumon InformationSciencesandSystems .Princeton,1971,pp.437{443. [2]G.ScottGrahamandPeterJ.Denning,\Protection{princ iplesandpractice," in ProceedingsofSpringJointComputerConference .AFIPS,1972,pp. 417{429. [3]StevenJ.Greenwald,\Anewsecuritypolicyfordistribu tedresourcemanagementandaccesscontrol,"in Proceedingsofthe1996WorkshoponNew SecurityParadigms .1996,pp.74{86,ACMPress. [4]MarkusLorchandSethProctorandRebekahLeproandDenni sKafuraand SumitShah,\FirstexperiencesusingXACMLforaccesscontr olindistributed systems,"in Proceedingsof2003ACMWorkshoponXMLsecurity .2003,pp. 25{37,ACMPress. [5]IanFosterandCarlKesselmanandGeneTsudikandStevenT uecke,\A securityarchitectureforcomputationalgrids,"in Proceedingsofthe5thACM ConferenceonComputerandcommunicationssecurity .1998,pp.83{92,ACM Press. [6]M.WebbandD.L.WilsonR.E.Newman-WolfeandC.L.Ramire zandH. PelimuhandiramandM.Montes,\Abriefoverviewofthedcsdi stributed conferencingsystem,"in ProceedingsofSummerUsenixConference ,Nashville, TN,1991,USENIX,pp.437{452. [7]AndrasBelokosztolszkiandKenMoody,\Meta-policies fordistributed role-basedaccesscontrolsystems,"in Policy2002:IEEE3rdInternational WorkshoponPoliciesforDistributedSystemsandNetworks ,2002,pp.106{ 115. [8]AnekVorapanya, Large-ScaleDistributedServices ,Ph.D.dissertation, UniversityofFlorida,2000. [9]JamesGoslingandBillJoyandGuyL.SteeleJr.andGiladB racha, The JavaLanguageSpecication ,Addison-WesleyProfessional,Boston,MA,third edition,2005. [10]HerbertSchildt, Java:TheCompleteReference,J2SE5Edition ,McGraw-Hill OsborneMedia,2004. 90

PAGE 101

91 [11]AshishBhalani,\Implementationofconferencecontro lserviceindistributed conferencingsystem,"M.S.thesis,UniversityofFlorida, 2002. [12]SwatiShukla,\Noticationservicesinadistributedc onferencingsystem," M.S.thesis,UniversityofFlorida,2000. [13]AmitV.Date,\Implementationofdistributeddatabase andreliablemulticast fordistributedconferencingsystemversion2,"M.S.thesi s,Universityof Florida,2001. [14]RamezElmasriandShamkantB.Navathe, FundamentalsofDatabaseSystems Addison-Wesley,Boston,MA,1994. [15]MaydeneFisherandJonEllisandJonathanBruce, JDBCAPITutorialand Reference ,Addison-WesleyProfessional,Boston,MA,thirdedition, 2003. [16]LukeWellingandLauraThomson, MySQLTutorial1/e ,MySQLPress, Uppsala,Sweden,2004. [17]KorryDouglasandSusanDouglas, PostgreSQL ,Sams,Indianapolis,IN,2003. [18]AparnaKakarparti,\Decisionsupportservicefordist ributedconferencing system,"M.S.thesis,UniversityofFlorida,2002. [19]VijayManian,\Accesscontrolfordistributedconfere ncingsystem,"M.S. thesis,UniversityofFlorida,2002. [20]RavichandranAringunram,\Securecommunicationserv icesgambettatrustfor distributedconferencingsystem,"M.S.thesis,Universit yofFlorida,2002. [21]PhilipS.Yeager,\Adistributedlesystemfordistrib utedconferencing system,"M.S.thesis,UniversityofFlorida,2003. [22]VijayaRangadhamKomaragiri,\Motherofallconcurren teditorsversion2.0," M.S.thesis,UniversityofFlorida,2004. [23]CharlesP.Preeger, SecurityinComputing ,Prentice-Hall,Inc.,UpperSaddle River,NewJersey,1996. [24]D.BellandL.LaPadula,\Computersecuritymodel:Uni edexpositionand multicsinterpretation,"Tech.Rep.MTR-2997,MITRECorpo ration,1976. [25]K.J.Biba,\Integrityconsiderationforsecurecomput ersystems,"Tech.Rep. MTR-3153,MITRECorporation,1977. [26]E.EllmerandG.PernulandG.QuirchmayrandA.Tjoa,\Ac cesscontrolfor cooperativeenvironments,"in WorkshoponDistributedSystems,Multimedia, andInfrastructure,ACMConferenceonComputer-Supported Cooperative Work(CSCW'94). ,1994.

PAGE 102

92 [27]MichaelA.HarrisonandWalterL.RuzzoandJereyD.Ull man,\Protection inoperatingsystems," CommunicationsoftheACM ,vol.19,no.8,pp. 461{471,August1976. [28]R.S.Sandhu,\Thetypedaccessmatrixmodel,"in ProceedingsoftheIEEE SymposiumonSecurityandPrivacy ,Washington,DC,1992,pp.122{136, IEEEComputerSociety. [29]RaviS.SandhuandGurpreetS.Suri,\Implementationco nsiderationsforthe typedaccessmatrixinadistributedenvironment,"in Proceedingsofthe15th NIST-NCSCNationalComputerSecurityConference ,Baltimore,MD,1992, pp.221{235. [30]P.E.AmmannandRaviS.Sandhu,\Safetyanalysisforthe extended schematicprotectionmodel,"in ProceedingsofIEEESymposiumonResearchinSecurityandPrivacy ,Washington,DC,1991,pp.87{97,IEEE. [31]RaviS.Sandhu,\Theschematicprotectionmodel:Itsde nitionandanalysis foracyclicattenuatingschemes," JournalofACM ,vol.36,no.2,pp.404{432, 1988. [32]PatrickH.WoodandStephenG.Kochan, UNIXSystemSecurity ,Hayden Books,Indianapolis,1985. [33]leenFrisch, EssentialSystemAdministration ,O'Reilly&Associates,New York,1996. [34]DavidFerraioloandRichardKuhn,\Role-basedaccessc ontrol,"in Proceedings of15thNationalComputerSecurityConference ,Baltimore,MD,1992,pp. 437{443. [35]DavidF.FerraioloandJanetA.CuginiandD.RichardKuh n,\Role-based accesscontrol(rbac):Featuresandmotivations,"in Proceedingsof11th AnnualComputerSecurityApplicationConference ,NewOrleans,LA,1992, pp.241{48. [36]DavidF.FerraioloandRaviSandhuandSerbanGavrilaan dD.Richard KuhnandRamaswamyChandramouli,\ProposedNISTstandardf orrolebasedaccesscontrol," ACMTransactionsonInformationandSystemSecurity (TISSEC) ,vol.4,no.3,pp.224{274,2001. [37]RoshanK.Thomas,\Team-basedaccesscontrol(TMAC):a primitive forapplyingrole-basedaccesscontrolsincollaborativee nvironments,"in ProceedingsofthesecondACMWorkshoponRole-basedaccess control ,New York,NY,1997,pp.13{19,ACMPress.

PAGE 103

93 [38]Gail-JoonAhnandRaviS.Sandhu,\Role-basedauthoriz ationconstraints specication," InformationandSystemSecurity ,vol.3,no.4,pp.207{226, 2000. [39]StevenJonGreenwald, TheDistributedCompartmentmodelforResource ManagementandAccessControl ,Ph.D.dissertation,UniversityofFlorida, 1994. [40]IreneGreifandSunilSarin,\Datasharingingroupwork ,"in CSCW'86: Proceedingsofthe1986ACMConferenceonComputer-Support edCooperative Work ,NewYork,NY,1986,pp.175{183,ACMPress. [41]ClarenceA.EllisandSimonJ.GibbsandGailRein,\Grou pware:someissues andexperiences," Commun.ACM ,vol.34,no.1,pp.39{58,1991. [42]AdrianBullockandSteveBenford,\Anaccesscontrolfr ameworkformultiusercollaborativeenvironments,"in GROUP'99:ProceedingsoftheInternationalACMSIGGROUPConferenceonSupportingGroupWork ,NewYork, NY,USA,1999,pp.140{149,ACMPress. [43]JoergM.HaakeandAnjaHaakeandTillSchummerandMoham ed BourimiandBrittaLandgraf,\End-usercontrolledgroupfo rmationand accessrightsmanagementinasharedworkspacesystem,"in CSCW'04: Proceedingsofthe2004ACMConferenceonComputersupporte dcooperative work ,NewYork,NY,2004,pp.554{563,ACMPress. [44]HongHaiShenandPrasunDewan,\Accesscontrolforcoll aborativeenvironments,"in CSCW'92:Proceedingsofthe1992ACMConferenceon Computer-SupportedCooperativeWork ,NewYork,NY,1992,pp.51{58,ACM Press. [45]JoonS.ParkandJunseokHwang,\Role-basedaccesscont rolforcollaborative enterpriseinpeer-to-peercomputingenvironments,"in SACMAT'03: ProceedingsoftheEighthACMSymposiumonaccesscontrolmo delsand technologies ,NewYour,NY,2003,pp.93{99,ACMPress. [46]DieterFensel, Ontologies:AsilverBulletforKnowledgeManagementand ElectronicCommerce ,SpringerVerlag,2003. [47]TrentJaegerandAtulPrakash,\Requirementsofrole-b asedaccesscontrolfor collaborativesystems,"in RBAC'95:ProceedingsoftherstACMWorkshop onRole-basedaccesscontrol .1996,p.16,ACMPress. [48]MargaretLeviandLauraStoker,\Politicaltrustandtr ustworthiness," Annual ReviewofPoliticalSciences ,vol.3,pp.475{507,2000.

PAGE 104

94 [49]RoderickM.Kramer,\Trustanddistrustinorganizatio ns:Emerging perspectives,enduringquestions," AnnualReviewofPsychology ,vol.50, pp.569{598,1999. [50]AlfarezAbdul-RahmanandStephenHailes,\Supporting trustinvirtual communities,"in HICSS-33:HawaiiInternationalConferenceonSystem Sciences ,Washington,DC,2000,IEEE. [51]MortonDeutsch,\Cooperationandtrust:Sometheoriti calnotes,"in Nebraska SymposiumonMotivation ,M.R.Jones,Ed.1962,NebraskaUniversityPress. [52]DiegoGambetta,Ed., Trust ,Oxford:BasilBlackwell,1990. [53]GirishSuryanarayanaandRichardN.Taylor,\Asurveyo ftrustmanagement andresourcediscoverytechnologiesinpeer-to-peerappli cations,"Tech.Rep. UCI-ISR-04-6,InstituteforSoftwareResearch,Universit yofCalifornia,Irvine, 2004. [54]PeterA.Dinda,\Addressingthetrustasymmetryproble mingridcomputing withencryptedcomputation,"in LCR'04:Proceedingsofthe7thWorkshop onWorkshoponlanguages,compilers,andrun-timesupportf orscalable systems ,NewYork,NY,USA,2004,pp.1{7,ACMPress. [55]D.Gritzalis,Ed., SecureElectronicVoting ,KluwerAcademicPublishers,2003. [56]S.Marsh, FormalisingTrustasaComputationalConcept ,Ph.D.dissertation, UniversityofStirling,1994. [57]V.ShmatikovandC.Talcott,\Reputation-basedtrustm anagement,"in ProceedingsofWorkshoponIssuesintheTheoryofSecurity( WITS) ,2003. [58]\Ebayfeedbackscheme,"http://pages.ebay.com/help /feedback/evaluatingfeedback.html(July10,2005).

PAGE 105

BIOGRAPHICALSKETCH VijayManianwasborninChennai,India,in1977,thesonofPa dmaand S.V.S.Manian.Hehastwoeldersisters,ChithraandVidya.A ftercompleting hisprimaryschoolinginChennai,heattendedIdaScudderSc hool,Vellore,India, wherehecompletedhisX.HecompletedhighschoolfromPadma SeshadriBala BhavanJuniorCollege,Chennai,in1995.HereceivedaBache lorofEngineering degreeincomputerscienceandengineeringfromtheUnivers ityofMadrasin 1999.Hethendecidedtopursuehismaster'sdegreeincomput ersciencefrom theUniversityofFlorida'sComputerandInformationScien cesandEngineering Departmentin1999.AfterobtainingaMasterofSciencedegr eein2002,he continuedontothePh.D.program.Helooksforwardtoahopef ullysuccessful careerinthesoftwareindustry. 95


Permanent Link: http://ufdc.ufl.edu/UFE0011941/00001

Material Information

Title: Voting-enabled role-based access-control model for distributed collaboration
Physical Description: x, 95 p.
Language: English
Creator: Manian, Vijay ( Dissertant )
Newman, Richard E. ( Thesis advisor )
Publisher: University of Florida
Place of Publication: Gainesville, Fla.
Publication Date: 2005
Copyright Date: 2005

Subjects

Subjects / Keywords: Computer and Information Science and Engineering thesis, Ph.D   ( local )
Electronic voting   ( lcsh )
Computer networks -- Access control   ( lcsh )
Dissertations, Academic -- UF -- Computer and Information Science and Engineering   ( local )
Teams in the workplace -- Data processing   ( lcsh )

Notes

Abstract: This dissertation presents a voting enabled role-based access control (RBAC) model designed for distributed collaboration that allows the group to decide and implement group policies. This model can also be used in many middle-level systems that require support for group voting. The primary goals of this model are security, scalability, flexibility and simplicity. One of the major drawbacks with many models in use today is the need for an external administrator or a user with "god-level" powers to implement the group policies. We overcome this by allowing subsets of users to vote on access control decisions that are deemed important. This takes the burden of group management from the system administrators and allows the group to be truly democratic and autonomous. In this dissertation, we give the motivation for the model, formally define it and give an example of how it can be used. We also define the access right leakage problem which we use to analyze the safety of the model. We first prove that for a simple version without any voting, the access right leakage problem can be decided in polynomial time. We then introduce the notion of trust-level and discuss how the trust-level of the users affect the safety of the system. This dissertation identifies three simple approaches by which a malicious entity can cause group members to vote in a manner that is not in the best interest of the group. We then analyze the safety of the model under each of these three approaches.
Subject: access, collaboration, trust, voting
General Note: Title from title page of source document.
General Note: Document formatted into pages; contains 105 pages.
General Note: Includes vita.
Thesis: Thesis (Ph. D.)--University of Florida, 2005.
Bibliography: Includes bibliographical references.
General Note: Text (Electronic thesis) in PDF format.

Record Information

Source Institution: University of Florida
Holding Location: University of Florida
Rights Management: All rights reserved by the source institution and holding location.
System ID: UFE0011941:00001

Permanent Link: http://ufdc.ufl.edu/UFE0011941/00001

Material Information

Title: Voting-enabled role-based access-control model for distributed collaboration
Physical Description: x, 95 p.
Language: English
Creator: Manian, Vijay ( Dissertant )
Newman, Richard E. ( Thesis advisor )
Publisher: University of Florida
Place of Publication: Gainesville, Fla.
Publication Date: 2005
Copyright Date: 2005

Subjects

Subjects / Keywords: Computer and Information Science and Engineering thesis, Ph.D   ( local )
Electronic voting   ( lcsh )
Computer networks -- Access control   ( lcsh )
Dissertations, Academic -- UF -- Computer and Information Science and Engineering   ( local )
Teams in the workplace -- Data processing   ( lcsh )

Notes

Abstract: This dissertation presents a voting enabled role-based access control (RBAC) model designed for distributed collaboration that allows the group to decide and implement group policies. This model can also be used in many middle-level systems that require support for group voting. The primary goals of this model are security, scalability, flexibility and simplicity. One of the major drawbacks with many models in use today is the need for an external administrator or a user with "god-level" powers to implement the group policies. We overcome this by allowing subsets of users to vote on access control decisions that are deemed important. This takes the burden of group management from the system administrators and allows the group to be truly democratic and autonomous. In this dissertation, we give the motivation for the model, formally define it and give an example of how it can be used. We also define the access right leakage problem which we use to analyze the safety of the model. We first prove that for a simple version without any voting, the access right leakage problem can be decided in polynomial time. We then introduce the notion of trust-level and discuss how the trust-level of the users affect the safety of the system. This dissertation identifies three simple approaches by which a malicious entity can cause group members to vote in a manner that is not in the best interest of the group. We then analyze the safety of the model under each of these three approaches.
Subject: access, collaboration, trust, voting
General Note: Title from title page of source document.
General Note: Document formatted into pages; contains 105 pages.
General Note: Includes vita.
Thesis: Thesis (Ph. D.)--University of Florida, 2005.
Bibliography: Includes bibliographical references.
General Note: Text (Electronic thesis) in PDF format.

Record Information

Source Institution: University of Florida
Holding Location: University of Florida
Rights Management: All rights reserved by the source institution and holding location.
System ID: UFE0011941:00001


This item has the following downloads:


Full Text











VOTING ENABLED ROLE-BASED ACCESS CONTROL MODEL FOR
DISTRIBUTED COLLABORATION















By

VIJAY MANIAN


A DISSERTATION PRESENTED TO THE GRADUATE SCHOOL
OF THE UNIVERSITY OF FLORIDA IN PARTIAL FULFILLMENT
OF THE REQUIREMENTS FOR THE DEGREE OF
DOCTOR OF PHILOSOPHY

UNIVERSITY OF FLORIDA


2005
















I dedicate this work to my parents, S.V.S. and Padma Manian.















ACKNOWLEDGMENTS

I would like to thank Dr. Richard N. vin i, for getting me started on this

project. I would like to express my gratitude to Dr.Steve Thebaut for his willing-

ness to help me whenever I had a problem. I would also like to thank all the DCS

group members, past and present, for their invaluable contributions without which

I would not have been able to complete this dissertation.

Special thanks are due to Salil Gokhale for helping me stay on track during the

last stages of my Ph.D. Finally, I would like to thank my parents for their support

and encouragement.















TABLE OF CONTENTS
page

ACKNOWLEDGMENTS ................... ...... iii

LIST OF TABLES ...................... ......... vii

LIST OF FIGURES ................... ......... viii

ABSTRACT .............................. ..... ix

CHAPTER

1 INTRODUCTION .................... ....... 1

1.1 M otivation . . . . . . . 2
1.2 Sample Scenario ............................ 4
1.3 Organization of this Dissertation ......... ......... 6

2 DCS OVERVIEW .............................. 7

2.1 Introduction . . . . . . . 7
2.2 D efinitions . . . . . . .. . 8
2.3 A Typical Day at Work ................... ... 9
2.4 Services .................. ............. .. 10
2.4.1 CoG Manager (C\!) .................. .... 10
2.4.2 Notification Services (NTF) ................. .. 10
2.4.3 Database Services (DBS) .................. .. 12
2.4.4 Decision Support Service (DSS) .............. .. 12
2.4.5 Access Control Services (ACS) ............... .. 12
2.4.6 Secure Communications Services (SCS) . . 13
2.4.7 Distributed File Services (DFS) .............. 13
2.4.8 Application Manager (AM) ................. .. 14
2.4.9 Tools .................. ........... .. 14
2.5 Interaction With Other Services .................. .. 14
2.5.1 Interaction With DBS ................ .. .. 15
2.5.2 Interaction W ith C'\I ................ .. .. 15
2.5.3 Interaction With DSS ................ .. .. 15
2.6 Summary .................. ............ .. 15

3 BACKGROUND ............... ........... ..17

3.1 Introduction ............... ........... ..17
3.2 Access Control. .................... ......... .. 17









3.3 Access Matrix Models ................ ... ... .. 18
3.3.1 HRU Model ............... ....... .. 19
3.3.2 Typed Access Matrix ...... .......... ... 20
3.3.3 Access Control in UNIX Operating System . ... 23
3.4 Role-Based Access Control (RBAC) .... . . 25
3.5 Distributed Compartment Model ... . . 26
3.6 Access Control for Collaborative Environments . .... 28
3.7 Trust and Voting ............... ........ .. 30
3.8 Summary ............... ......... .. 31

4 THE DCS-AC MODEL .............. . .. .. 33

4.1 Introduction ............... ........... .. 33
4.2 The DCS-AC Model ................ ... ... .. 33
4.3 Operations ................. ........... 36
4.4 Commands in DCS-AC Model ............. .. .. .. 39
4.4.1 Constraints. ....... ............ ..... 41
4.4.2 Expressive Power ............... .... 43
4.5 Comparison with existing models ............. .. .. 44
4.6 Features of DCS-AC Model ................ ...... 45
4.6.1 Decision Templates ................ . 46
4.6.2 Dynamic Type Binding ............. . .. 47
4.6.3 Dynamic set of Access Rights .... . . 47
4.6.4 Dynamic set of Object Types .... . . 48
4.6.5 Fine Grain Access Control .... . . 48
4.7 DCS-AC Model Solution for Software Project Example . 49
4.8 Summary ............... ......... .. 51

5 SAFETY ANALYSIS .................. .......... .. 52

5.1 Introduction ............... ........... .. 52
5.2 Definitions ............... ........... .. 52
5.3 Attributes of a State ................ ... .... .. 54
5.4 Proofs ............... ............. .. 55
5.5 Summary ............... ......... .. 68

6 TRUST AND VOTING ............... ........ .. 69

6.1 Introduction ............... ........... .. 69
6.2 Trust and Trust-Worthiness ............... .... 69
6.2.1 Approaching Trust ...... ......... .... 70
6.2.2 Decision Templates ................ . 72
6.3 ARL Problem And States ................ . 74
6.4 Trust Analysis of DCS-AC ................ ...... 75
6.4.1 State Graph .... ........... .... 75
6.4.2 Ad-Approach. .............. ... ... .. 77
6.4.3 Pay-As-You-Go Approach .... . 79









6.4.4 Honest Politicial Approach ................. .. 80
6.5 Summary ............... ......... ..82

7 NEXT STEPS ................ ........ ....... 84

7.1 Enhancing DCS Commands ............... .... 84
7.2 Special Relations ............... ........ ..85
7.3 Role Hierarchy ............... .......... ..85
7.4 Use-Cases and Scenarios ..... .......... .... 86
7.5 Multi-User Collusion Attacks ...... .......... .... 86
7.6 Time-Limited Access ................ ... .... .. 87

8 CONCLUSION .................. ............ .. 88

REFERENCES ............. .. ............ ... 90

BIOGRAPHICAL SKETCH .............. . .. 95















LIST OF TABLES
Table page

3-1 Primitive Operations in HRU model .................. 19

3-2 Primitive Operations in TAM model .................. 21

4-1 Example of DCS-AC Matrix Fragment ................. ..36

4-2 Specification of DCS-AC Operations .................. 37

4-3 DCS-AC Solution for Software Project Example ........... ..50















LIST OF FIGURES
Figure page

1-1 Class Library Scenario .................. .. 5

2-1 Architecture of DCS .................. ..... 11

4-1 Comparison of HRU, TAM and DCS-AC models . ..... 44















Abstract of Dissertation Presented to the Graduate School
of the University of Florida in Partial Fulfillment of the
Requirements for the Degree of Doctor of Philosophy

VOTING ENABLED ROLE-BASED ACCESS CONTROL MODEL FOR
DISTRIBUTED COLLABORATION

By

Vijay Manian

December 2005

C(! ,i': Richard E. N, v in ,
M ii Department: Computer and Informational Sciences and Engineering

This dissertation presents a voting enabled role-based access control (RBAC)

model designed for distributed collaboration that allows the group to decide and

implement group policies. This model can also be used in many middle-level

systems that require support for group voting. The primary goals of this model

are security, scalability, flexibility and simplicity. One of the 1 i, i" drawbacks with

many models in use tod -v is the need for an external administrator or a user with

;od-level" powers to implement the group policies. We overcome this by allowing

subsets of users to vote on access control decisions that are deemed important.

This takes the burden of group management from the system administrators and

allows the group to be truly democratic and autonomous. In this dissertation, we

give the motivation for the model, formally define it and give an example of how

it can be used. We also define the access right leakage problem which we use to

analyze the safety of the model. We first prove that for a simple version without

any voting, the access right leakage problem can be decided in polynomial time.

We then introduce the notion of trust-level and discuss how the trust-level of

the users affect the safety of the system. This dissertation identifies three simple









approaches by which a malicious entity can cause group members to vote in a

manner that is not in the best interest of the group. We then analyze the safety of

the model under each of these three approaches.















CHAPTER 1
INTRODUCTION

Distributed collaboration is more than just a buzzword in .1-'di's world.

Most users log in from large networks, and often times, the collaborators are from

different administrative domains. In such a scenario, access control can become

an additional burden on the already overworked administrators and usually is

difficult without enforcing many restrictions. On a stand-alone machine, access

control is more or less straightforward with the operating system providing simple

discretionary access control (DAC) mechanisms like access control lists (ACL) or

capability lists (CL). Most of these mechanisms are based on the access control

matrix (AC'\l) model [1, 2]. Various models have been proposed for multi-user

systems and these models are defined with well-known abstractions like subjects,

objects and access rights.

There are some i1n i, i"r disadvantages to the current models when applied

to distributed environments in general and distributed collaborative systems in

particular. Most systems tod -v are run over the network and have a centralized

node to handle access control, which results in a single point of failure and more

importantly, a single administrative authority, which is not ahv--, desirable. Many

practical models restrict the types of accesses (for example, Unix has only three

types: read, write and execute), which does not reflect real life. In addition, each

object in the system can have only one owner, which might not be the case in a

collaborative environment. Some of the 1 i jri problems with classical models are

discussed in section 1.1.

The Distributed Conferencing System-Access Control Model (DCS-AC)

discussed in this dissertation has been designed to provide a simple, powerful,









implementable, scalable and flexible access control mechanism. One of the most

important features of this model is the use of group decision-making mechanisms

(voting) as a part of the access control decision process. Here, important access

control decisions can be referred to a vote among a specified subset of the users,

thereby allowing them to self-administer the groups. 1 ii': current models rely

on a -,'I' i i~" ," who can do almost anything in the system. The DCS approach

models society more closely and also protects the system against malicious single-

user attacks.

We analyze the safety of the model in terms of the Access Rights Leakage

(ARL) problem. ARL is the problem of deciding whether a malicious entity can

execute a set of commands which result in an unauthorized user gaining access to

an object in a given DCS-AC instance. We approach this problem by first solving

it for a system with no voting. When the subjects are allowed to vote on one or

more access control decisions, it is difficult to decide on a yes or no answer. We

assign a trust-level value to each subject and decide on the answer in terms of

the trust-levels of all the subjects who can participate in the vote(s). Let us now

consider why we need the DCS-AC model.

1.1 Motivation

Most access control systems in use tod w are based on the traditional ac-

cess control matrix model.1 This proposal considers access control policies in a

distributed collaborative environment where the traditional models suffer from

the following problems (a few more problems with current systems are given in

Greenwald [3]).





1 ACL and CL can be considered to be a part of the traditional access control
matrix model









1. System administrators are usually overworked and underpaid. A centralized
server that coordinates the entire distributed system will not work well.

2. If three subjects are collaborating on a document, under the current
paradigm, any one of these three can unilaterally delete the object. This
is not desirable and a more useful policy could be to require at least two of
the author's approval in order to delete the object.

3. It is difficult to obtain access to objects located in a different administrative
domain without getting the local system administrator's permission.

4. Even in systems that are specifically designed for distributed computing [4],
like grid computing, the standard policy is for each domain to be responsible
for the objects in its site [5]. Now, if Alice accesses an object from another
administrative domain, a < ,v of the object is usually cached. The local
system has no idea about the access control policies of this object and when
Bob requests access to the same object, the request is forwarded to the other
domain. If the local system were aware of the access control policies for the
object, it could have made the decision on its own and saved Bob a lot of
time.

5. The individual groups of collaborators cannot set their own group policies.

The DCS-AC model addresses these issues and provides a very flexible access

control mechanism. This model was developed for Distributed Conferencing System

(DCS) [6], a distributed collaborative architecture that allows users from different

sites to work together. The first objective of the DCS-AC model is to provide

flexible, implementable and fault tolerant access control. The second objective is

to allow the users of the system to self-administer the access privileges, i.e., allow a

subset of users (who are often the stakeholders) to make access control decisions for

important objects on a case-by-case basis. This is done by using a set of decision

templates each of which defines the subset of users that can participate in a vote.

Each entry in the AC'\ has a decision template pointer which has to be exe-

cuted in order to arrive at a decision. Although the model enforces no constraints

on which decisions require a vote, we expect that most entries will point to the

A1l, .;;,--;. template which ahv--, returns a .;/ since many rights, once granted,









need not be referred to the voting group for every access. However, for important

access control decisions the system can refer the decision to a subset of the users

who vote on it. This allows the users to express access control policies for some

accesses (like joining the group, accessing important objects, granting access rights,

etc.) in the system.

The use of decision pointers also improves fault tolerance. It protects against

single malicious user threats, since many users may have to agree for the vote

to pass. In addition, if some of the users are unavailable, the system can still

take decisions based on the users available (unless the system policy specifically

states that a particular user must agree for the vote to pass). There are many

real-life scenarios in which such multi-user authorizations are required and are often

handled off-line before one of the participants "informs" the system if the request is

approved.

1.2 Sample Scenario

Consider the following example of a project to be implemented by a team

consisting of a project leader (PL) and many subordinates (architects, 1i.' i ,ii,,in,, rs

and testers). The architects work on the design and once the design is approved

by the PL, one or more 1' .,.'ii I,,' rs code the project, which is then tested by

the testers. The testers can either send it back to the programmers along with a

bug-list or notify the PL that the code is acceptable. The PL then reviews the code

with the review team, and if approved, the project is released to the client (refer to

Figure 1-1).

Given below are a few

1. The individuals concerned may be located in different branches; confidential-
ity and availability are important for the shared objects.

2. The architect does not need access to the code and the tester can look at the
code only after the programmers are ready.













Problem Statement


Figure 1-1: Class Library Scenario


3. The review team consists of all PLs in the i. "-! ln-: and the members do not
have access to the code until it passes the testing phase.

4. The PL can access any document related to this particular project at any
point of time.

5. The PL also decides who works on this project.

6. The PL cannot change the role of an employee; for example, the PL cannot
assign a programmer to do the task of an architect.

7. There are many architects, programmers, etc. in the company, and only those
involved in development should have access to the objects.

8. The programmers do an internal review and send the code to the testers after
every programmer has approved it.

9. The review team members vote on whether the code can be added to the
library.

The first eight requirements can be handled by RBAC in a straightforward manner

using constraints. However, specifying constraints introduces runtime overhead

[7]. Requirements eight and nine involve group decisions. Although the above

example deals with a simplistic scenario, we believe that there are many examples










that involve similar issues. The DCS model is designed to handle scenarios of this

nature.

1.3 Organization of this Dissertation

C'! lpter 2 gives a brief overview of the Distributed Conferencing System and

chapter 3 provides the technical background for the DCS access control model.

C!i lpter 4 deals with the formal definition of the DCS Model and discusses the

features of the DCS model. Ci Ilpter 5 discusses the decidability of the ARL

problem for the DCS-AC model without voting and chapter 6 discusses trust in

voters and the trust worthiness of a DCS-AC system where voting is allowed.

chapter 7 mentions some future directions of research and chapter 8 concludes this

work.















CHAPTER 2
DCS OVERVIEW

2.1 Introduction

In tod w's highly-networked working environment, support for collaboration

and group-work has become critical. The availability of low-cost Wide Area

Networks (WANs) means that members of a group can be geographically scattered

around the country (or even the world). There is a growing need for efficient

architectures and applications that facilitate collaboration between such members.

A system that allows users to log on from different locations, to share objects, and

to work on the same object with other members of the group has become essential

in such cases.

The Distributed Conferencing System (DCS) seeks to fulfill these requirements

and many more. The system is based on a robust architecture and provides

distributed file services, access control, secure communication, notification and

group decision-making mechanisms. The DCS will provide basic distributed

collaborative applications like text editors, graphics editors, etc., and can also

support third-party applications. The scalable architecture can support multiple

sites and objects can be replicated to ensure faster access and availability. One

of the 1i ii' r design criteria is fault tolerance. The system is designed to handle

network failures and system crashes by restoring from backups and contacting

other sites for the most up-to-date information. We achieve this by replicating

the objects across multiple sites and also by means of backup servers for each site

which can take over if the primary server fails.









2.2 Definitions

Before getting into the details of DCS and the various services provided, we

first define some terms that are required to understand the architecture:


DCS instance This is a collective term for one or more DCS sites that share
resources, communicate DCS specific information with and store information
about each other. Any user id or CoG registered at one site is accessible
from all sites in that DCS instance. An instance of DCS may cover multiple
administrative domains.

Site This term refers to the DCS servers) located in a single administrative
domain that provide services to the users. Sites that are a part of the same
DCS instance can communicate with each other.

Collaborative group (CoG) This term refers to a persistent or transient
group consisting of members, objects, applications, and a DCS-AC system
(consisting of roles, object types, allowable member-role bindings and decision
templates). The members of a CoG work together on the objects and decide
group policies for that CoG.

User This is an entity in the system that initiates action and (in the context
of access control) requests to access objects. This term usually refers to a
human being.

Member This term when used in the context of a CoG refers to a user who
is a part of the CoG and has been granted rights that are not granted to
non-members.

Subject This represents an active user process that is allowed to perform
some action within the system on behalf of the user.

Object This is a passive entity in the system. Users can perform various
accesses on them. Examples of objects are documents, files and DCS system
specific tables.

Application This is a program that the user launches from within the system
to work on the objects.

Collaboration-ware These are applications that are designed to support
collaborative work. Therefore these applications will have a better access
control features than the regular off-the-shelf applications.









DCS-aware applications These are applications that are specifically designed
to work within the DCS. These applications can use the features of DCS like
event notification or new access type registration.

Role This is a named group of subjects. Roles can also be viewed as a
collection of job functions. A particular subject can bind to any number of
roles but at any point of time, the subject can be bound to only one role. It
must be noted that role as used here is slightly different from role as used in
Role-based access control because there is no notion of a role-hierarchy in the
DCS model.

Object type This is a named group of objects. A particular object can belong
to only one object type.

2.3 A Typical Day at Work

A typical instance of DCS consists of many sites and each site consists of a

primary server with one or more backup servers (which are ranked from 1 to n

where n is the number of backups) to ensure high availability. The primary server

sends periodic heartbeats and updates to the backups [8]. If the backups do not

get the heartbeat from the primary for a fixed amount of time, the lowest ranked

backup takes over as the primary and informs the other sites in the instance.

Similarly, the sites exchange heartbeats and if a site does not respond, the other

sites can take over the management of objects controlled by the failed site.

Each site contributes resources (like disk space) to the instance and all objects

are partially replicated to provide fault tolerance. The DCS architecture is divided

in to various modules each of which provides a different service to the users (section

2.4). A user logs into a CoG through a site and is bound to a role (based on the

user-role bindings maintained by the Access Control Services). The Distributed

File Services provides a uniform view of the DCS space, which actually consists of

objects located on different sites. The user can launch applications to access these

objects, participate in decision making processes or interact with other members of

the CoG. It must be noted that site are managed in the same way as CoGs. That

is, On each site, there is a CoG corresponding to the site containing all subjects









who joined the DCS instance from that site; they can form and implement their

own site management rules. The following section provides a brief description of

the various services and tools available in DCS.

2.4 Services

The architecture of DCS v.2 is shown in figure 2-1. It is based on various

services available in most networked domains (like local file systems, TCP/IP,

cryptographic packages, database system, etc.). Since we are using Java [9, 10], the

sites need not all run the same operating system. A brief description of the core

services is given below.

2.4.1 CoG Manager (C\M)

This is the module responsible for managing the collaborative groups (CoGs)

[11]. This module instantiates the other modules and the clients interact with the

other services mainly through the C \!. Tasks like merging two instances of DCS

or sites or CoGs, and splitting an instance, a site, or a CoG is handled by this

module. The C'\ interacts with the secure messaging and the cryptographic 1lV,-i

during user login. The user's access control requests are routed through the C'\ .

The C'\ also allows the user to import and export objects, add new members and

start sub-groups (sub-CoGs).

2.4.2 Notification Services (NTF)

The NTF [12] provides .,-vnchronous event notification to registered users.

Users can define new event types and register to be notified on events. Subjects

are automatically registered for notification if they are among the valid voters

on a decision. The various services and applications running in the instance raise

events as and when they occur and the NTF maintains a global and local database

in which it stores the users to be notified on each event along with the delivery

method.























NTF ACS


Figure 2-1: Architecture of DCS









2.4.3 Database Services (DBS)

The DBS [13] makes use of a backed Database Management System (DBMS)

[14] to maintain the tables of all the DCS services and applications. Most tables

are stored as partially replicated distributed databases. The DBS uses group

multicast and ensures eventual consistency among all member sites by using vector

timestamps. Since DBS uses Java Database Connectivity (JDBC) [15], we can use

any backed DBMS system like MySQL [16] or PostgreSQL [17].

2.4.4 Decision Support Service (DSS)

Decision Support System [18] is a module that facilitates resolving issues by a

group of users who have a joint responsibility to such decisions. Voting is one of the

tools of DSS which is designed to be a flexible and friendly system that allows users

to initiate, participate in and terminate decisions within the context of a CoG. It

provides on-line voting and has automated vote collection mechanisms. It allows

members who are currently off-line to be voters in a decision process. The initiator

of the vote can set time constraints and specify voting parameters, voters, reporting

--1i. and report recipients.

This service takes into account the user's role, weight assigned to the vote and

access rights, etc. It has several features like reminders, request for status, change

of vote, short circuit evaluation, withdrawal and termination of active votes, which

add more flexibility to the decision process. It also allows other modules of DCS to

make these requests.

The module supports different voting methods like 1in i i i ly, plurality, and

ranking. Users can save their requirements as templates that can be reused in the

future by anyone who has the access rights to do so.

2.4.5 Access Control Services (ACS)

The ACS [19], as the name -,-.-- -i- controls access to (CoG-specific or

instance-specific) objects. It makes use of decision templates of the DSS to provide









group decision-based access control. This puts the control of the CoG in the hands

of the members. The ACS stores its tables in a database through the DBS. The

ACS allows applications to register new access types. This allows more fine-grain

access control if the application supports it.

The ACS interacts with all the other five modules and provides various

services to the users. The DCS architecture requires the ACS to allow decisions

to be made on access control requests at the source site itself. This coupled with

the decision templates makes the ACS an interesting study in itself. The model

used here is not specific to DCS and can be used in any distributed system that

supports group decision-making mechanisms.

2.4.6 Secure Communications Services (SCS)

The Secure Communication Services [20] ensures the confidentiality, authentic-

ity and integrity of all messages passed between sites and clients. To enforce these

important security properties, it is necessary to establish the identity of the entities

of the system. The entities of the system are users, hosts, and servers. The identi-

fication of the entities should be done reliably, that is, it should be authenticated.

DCS poses a greater challenge since entities communicate through messages and

hence all the entities must establish their identities and maintain confidentiality. In

DCS, identity is first established using strong authentication and per-connection

symmetric cryptography provides confidentiality and integrity. The SCS is also

responsible for creation and maintenance of keys and certificates for sites and users.

2.4.7 Distributed File Services (DFS)

The Distributed File Services [21] provides a DCS-specific view of the objects

located at various sites. It allows concurrent access of files using a versioning

scheme with immutable shared files and is designed to provide reasonable service

in the case of site crashes. Each CoG is represented by a directory in DCS-space

and sub-CoGs are simply sub-directories under the directory corresponding to the









parent CoG. The DFS creates and maintains multiple copies of all objects, thereby

ensuring high availability.

2.4.8 Application Manager (AM)

The Application Manager is responsible for registering and invoking applica-

tions that are available for each CoG. These applications could be DCS-aware (like

MACE [22]) or DCS-unaware. The AM maintains a list of applications available for

a particular CoG, and depending on the access rights of the user, it makes those

available to the users.

2.4.9 Tools

The DCS framework provides a few basic tools for collaboration. These include

instant messaging (Gossip), concurrent text (\! ACE) and graphics (Ensemble)

editors.


Gossip This is a simple instant messaging application that is a part of the
client GUI. It allows the user to be in touch with his/her collaborators.

MACE MACE [22] stands for Mother of All Concurrent Editors and is
a very powerful concurrent text editor. In addition to regular text editor
features, MACE allows users to lock various parts of the files and share views.
MACE provides a very fine-grained (byte-level) locking mechanism and the
user can set the view rights for others, i.e., the other users can see every key
stroke or receive updates only when the writer commits the changes. This
allows other users to "look over the shoulder" of the writer (useful in pair
programming among other areas).

Ensemble Ensemble is a concurrent graphics editors that provides object-
locking and specific user pointer view. Multiple users can work on the same
figure and each user can lock one or more objects and share cursor, allowing
other users to see exactly what is going on.

2.5 Interaction With Other Services

Since we are primarily concerned with the ACS, which implements the DCS-

AC model, let us look at ACS' interactions with the other services. As mentioned









earlier, ACS interacts with all the core services. Out of these, DBS and DSS

provide vital services required for ACS.

2.5.1 Interaction With DBS

All ACS information about a CoG are stored as relational database tables that

are replicated across all sites interested in the CoG by DBS. When a new CoG is

created, the relevant ACS tables have to be created on the local site. Whenever

a site wants to participate in a CoG, it obtains a dump of the ACS tables from

a site that is already in the CoG and copies it on to the local database. Any

database query can be handled by the DBMS at the local site but updates have to

be forwarded to the site that '.--;" the entry and then multi-cast to other sites.

2.5.2 Interaction With C'\

The C'\I controls the entire conference and instantiates the objects that

provide the services including ACS. Moreover, most user requests are passed on to

the ACS through the C\ i. Most C\ I-originated actions have to be checked through

the ACS for access privileges. For example, if a user wants to import a new file, the

C'\ will have to check with the ACS before proceeding with the import.

2.5.3 Interaction With DSS

The DSS handles the decision-making process and is therefore closely tied to

the ACS. If a request requires a vote, the DSS has to be invoked and the voting

process initiated. The ACS must be able to check the status of a particular vote.

When a vote is completed, the DSS should notify the ACS. Similarly, the ACS

must be able to report a list of active votes to the DSS if the DSS decides to delete

obsolete votes. Actions like defining new templates and modifying existing ones

require a check by the ACS.

2.6 Summary

The core services described here provide a framework for distributed collab-

oration. The three tools mentioned are what we consider minimal applications







16

required by collaborating users. The Application Manager allows users to execute

other applications from within the DCS framework. As will become clear in the

next chapter, DSS is required by the DCS-AC model since it handles all voting

related issues.















CHAPTER 3
BACKGROUND

3.1 Introduction

This chapter surveys some of the work in access control and trust in voters

that is relevant to the Distributed Conferencing Service Access Control (DCS-AC)

model.

3.2 Access Control

Protection of objects is complex because the number of access points may be

large, there may be no central authority through which all access requests pass,

and the kind of access is not simply limited to read, write, or execute. According to

Pfleeger [23], there are several complementary goals in such a mechanism.


C' e. very access. We may want to revoke a user's privilege to access an
object. If we have previously authorized the user to access the object, we do
not necessarily mean the user should retain indefinite access to the object.

Allow least privilege. A subject should have access to the smallest number
of objects necessary to perform some task. Not allowing unnecessary access
to objects guards against security weaknesses if a part of the protection
mechanism should fail.

Verify acceptable usage. The final decision on an access request is a yes-no
decision. Of more interest is checking that the activity to be performed on an
object is appropriate.

Access control policies are broadly classified as Mandatory Access Control

(\!AC) and Discretionary Access Control (DAC). MAC means that access control

policy decisions are made beyond the control of the individual owner of an object.

A central authority determines what information is to be accessible by whom, and

the user cannot change access rights [23]. A classic example of MAC is in military









security where the owner of a "top--- i. I object cannot decide who has top-secret

clearance nor can the owner change the classification of the object to "secret".

Examples of models that enforce MAC include Bell-La Padula Confidentiality

model [24] and Biba Integrity Model [25]. DAC on the other hand, allows the

owner of an object or .iione else who is authorized to control access to the object

to specify who has what access to the object. The access rights in a DAC scheme

can change dynamically [23]. One of the main differences between DAC and MAC

is the fact that MAC is also concerned with the flow of information [26].

In this work, we are mainly concerned with DAC since we want the users to

be able to decide their own access control policies without .,vii, central authority.

In the following sections we look at various protection mechanisms. First we will

consider the Access Matrix model. We also describe certain modifications like

Access Control Lists and Capability lists along with the Graham-Denning and

Harrison-Ruzzo-Ullman models, which are all DAC models. Next we will review

role based access control, and the Distributed Compartment Model for resource

management and access control proposed by Steven Greenwald. Finally, we will

look at recent work on access control for collaborative environments.

3.3 Access Matrix Models

Access control matrices are the most popular means of modeling an access

control system. An access control system has a group of users, objects and access

rights for those users on those objects. The HRU [27] and Graham-Denning [2]

models are early examples of such models. Such systems have a set of commands

that test the presence of various rights in the matrix and then execute a sequence

of operations. Most modern systems use a variation of the access control matrix

like access control lists or capability lists. Access rights leakage is an interesting

property of access control systems. One of the many means of analyzing a model is

to try to classify the leakage problem for that model.









Table 3-1: Primitive Operations in HRU model

enter r into (X, Xo)
delete r from (Xs, Xo)
create subject X,
create object Xo
destroy subject X,
destroy object Xo


3.3.1 HRU Model

Harrison, Ruzzo and Ullman proposed a model in 1976 that is popularly

referred to as the HRU model [27]. A HRU protection system consists of a static,

finite set of rights R, and a static, finite set of commands, C. There are six

primitive operations defined which are given in Figure 3-1. A configuration of a

protection system is a triple (S, O, P), where S is the set of subjects, O is the set

of objects, S C 0, and P is a rights matrix, with a row for each subject and a

column for each object. P[s, o] (C R) gives the rights to the object o possessed by

the subject s. The formal definition of the model is as follows:

D [i../ A protection I.' ,,, consists of the following parts:


1. a finite set of rights, R,

2. a finite set C of commands of the form:
command a(Xi,X2,..., Xk)
if (ri E (X,i,X1o)) A... A (rm E (Xsm, Xo)) then
opi

opn
end

Here each subject or object Xsi or Xoi is one of the parameters Xj and each

operation opi is one of the primitive operations given in Table 3-1.

Access right Leak

While we cannot expect a useful system to be safe in the strictest sense, the

minimum tolerable situation is that the user should be able to decide whether a









given configuration could lead to some other user getting a specific right, i.e., if

the right leaks to other users [27]. Needless to -'v, there are some users whom we

trust and in fact expect to have the right. We remove the rows corresponding to

those users and try to find out if the right leaks when some sequence of commands

is executed. The formal definition of the safety question for access control systems

is given below:

Definition Given a protection system, we ~v- a sequence of commands ca, ca2,.. *

leaks a right p from a starting state Q if the commands when run on Q (in se-

quence), can execute a primitive operation that allows some user the right p that

was not allowed Q.

In other words, a system leaks a right p if and only if it is possible for an

unintended subject to get the right p on an object o by the execution of a sequence

of commands. The authors have proved that the safety question (also called access

right leakage problem) is generally undecidable for the HRU model. It is interesting

to note that if we enforce the mono-operation restriction, i.e., each command can

execute only one of the primitive commands, then the safety question for such a

system is NP-complete. However, most useful HRU systems cannot satisfy the

mono-operation requirement.

The Typed Access Matrix (TAM) model [28],[29] adds strong typing to the

HRU model. The access rights problem for the generic TAM model has been

proven to be undecidable but there are certain restricted versions of TAM for which

the problem has been proven to be NP-Hard.

3.3.2 Typed Access Matrix

Ravi Sandhu and others have worked on modifying the HRU model to make

the safety problem decidable while at the same time maximizing the expressing

power [30]. The Typed Access Matrix (TAM) [28] defined by Sandhu combines

strong safety properties for propagation of access rights of Schematic Protection









Table 3-2: Primitive Operations in TAM model

enter r into [X, Xo] delete r from [X, Xo]
create subject X, of type t, delete subject X,
create object Xo of type to delete object Xo


Model [31] with the natural expressive power of the HRU model. TAM is obtained

by incorporating strong typing into the HRU model [29]. It is important to

understand that the types and rights are specified as part of the system definition.

The system administrator specifies the following sets for this purpose:


a finite set of access rights denoted by R, and

a finite set of object types denoted by T.

The protection state is a TAM system is given by the four-tuple (OBJ, SUB, t,

AM) interpreted as follows:


OBJ is the set of objects.

SUB is the set of subjects, SUB c OBJ.

t : OBJ -- T, is the type function which gives the type of every object.

AM is the access matrix. We have AM[S, O] C R where S is a subject and
O is an object.

The protection state of the system is changed by means of TAM commands. Each

TAM command has the following format:

command a(XI : t, X2 : t2, ... ,Xk : tk)

if ri E [X,,, Xo1 A r2 [X,,, X2] A .-A r E [X,, XX0

then opi; op2;...;,''

end

Here a is the name of the command; Xi are formal parameters whose types are

ti; ri are rights. Each opi is one of the primitive operations listed in table 3-2.









The rights, types and commands define the system scheme. The scheme can

be modified only by the system administrator, who is not considered to be a part

of the system. The type of an object is fixed and cannot be changed within the

system. Sandhu has proved that TAM has considerable expressive power.

Safety problem in TAM

The access rights leakage problem for the general TAM model is undecidable

(refer to the original paper [29] for proof). The author defines a few restrictions

on TAM that allow us to make the problem decidable. A TAM system that does

not have any command that deletes a right or destroys a subject or object is called

Monotonic TAM. In such a system, S, O and P[s, o] are all monotonically non-

decreasing. In a given command a, we i- that a type ti is a child type in that

command if one of the following primitive operations create subject Xi of type

ti or create object X, of type ti occurs in the body of a. The type tj is said

to be a parent type in a if one of the parameters of a is of type tj and tj is not a

child type in a. The creation 'jr'l, of an TAM scheme is a directed graph with

vertex set T and an edge from u to v if and only if there is a command in which

u is a parent type and v is a child type. A TAM scheme is .: if and only if

its creation graph is .,1 i-, 1i A Ternary TAM is identical to TAM except that all

commands are limited to a maximum of three parameters. Given these properties,

Sandhu has proved the following results:


1. Generic MTAM is undecidable.

2. Acyclic MTAM is NP-Hard.

3. The safety question for .,- i-* i- ternary MTAM is decidable in polynomial
time in the size of the initial access matrix.









3.3.3 Access Control in UNIX Operating System

The UNIX operating system was developed at Bell Laboratories in the late

1960s. It evolved in a "friendly" environment, on systems that encouraged users

to share their files [32]. However, UNIX is by design a very robust system. The

following is a brief discussion of the basic principles in UNIX access control.

Files are central to UNIX in v- -, that are not true for other operating

systems. Commands are executable files in specific directories like /bin, /usr/bin,

etc. System privileges and permissions are controlled in a large part via access to

files [33]. Access to files is organized around file ownership and protection.

Each file has a user owner and a group owner. UNIX supports three types of

file access: read (r), write (w), and execute(x). A different set of access rights can

be set for user owner, group members and others. For example, the access right

rwxr xr means that the user owner can read, write and execute the file,

members of the group owner can read and execute the file but all others can only

read the file. The command that is used to alter the access mode is chmod.

There are a few other defined file modes, namely, t (Sticky bit, keep executable

in memory after exit), s (Set process user ID or group ID on execution), and I (set

mandatory file locking on reads/writes). Files that begin with a period are hidden

files and are not listed by Is command unless used with the -a option. The -1

option of Is command lists the files along with the modes and owners of the files.

The set of commands that are used to modify the access rights of files are:


chmod Specify the protection modes for files.

umask Specify the default mode for newly created files.

chown C'!I, Ige the user owner of a file.


* chgrp C'i m ,_, the group owner of a file.









Some variants of UNIX, like AIX and HP-UX provide access control lists which

offer a further refinement to the standard UNIX file permissions capabilities. These

ACLs consist of three parts:


1. Attributes Specifies any special attributes like SETUID and SETGID.

2. Base permissions These correspond exactly to the UNIX file modes and
specify access rights for owner, group and others.

3. Extended permissions These are access information specified by user and
group name.

ACLs that specify a username and group are useful for accounting purposes. They

are also useful if you add a user on a temporary basis [33].

UNIX was the first 1i ii network operating system. It provides various

services like NIS (Network Information Services) and NFS (Network File System)

that help in administering a network. Using NIS, users can log on to any machine

on the network that belongs to the same NIS Domain. In a network with twenty

machines, the administrator has to add the new user on just one machine and that

user can log on to any one of these twenty machines. In order to provide a uniform

directory structure when a user logs in, administrators mount file systems over the

network. Usually, the user's home directories are mounted using NFS. This way the

user's files are available to him/her on any machine in the network. The advantage

with this arrangement is that controlling file permissions is the same as described

earlier.

Users authenticate themselves to the system by providing a user name and

password. It is very important for users to protect their passwords because if the

password is compromised, then all logins may be compromised [32]. Passwords

and file permissions are two basic v--,i- of preventing security problems in UNIX.

Passwords prevent bad guys from getting on the system in the first place and

proper file permissions prevent normal users from doing things they are not









supposed to [33]. There are only three access types and users cannot define their

own access types. Moreover, the owner of a file has full rights to do anything with

the file. In many organizations, the files are not 'I.--i: ,1" by the users but by the

organization itself.

3.4 Role-Based Access Control (RBAC)

Role-Based Access Control (RBAC) [34, 35, 36, 37, 38] is a model that is

gaining popularity. The principal motivations behind RBAC are the ability to

articulate and to enforce enterprise-specific security policies and to streamline the

typically burdensome process of security management.

In many organizations, the end users do not i.--v the information for which

they are allowed access. The corporation is the actual "c.--v i of system objects

as well as the programs that process it and control is often based on employee

functions rather than data ownership.

In RBAC, users do not have discretionary access to enterprise objects. Instead,

access permissions are associated with roles and users are associated with roles. A

role based access control policy bases access control decisions on the roles a user is

allowed to take on within an organization. The determination of role membership

and the allocation of transactions to a role is in compliance with organization-

specific protection guidelines derived from existing laws, ethics, regulations, or

generally accepted practices. With RBAC, users are not granted permission to

perform operations on an individual basis, but operations are associated with

roles. This has the advantage of simplifying the understanding and management of

privileges.

System administrators control access at a level of abstraction that is natural to

the way enterprises typically conduct business. RBAC addresses security primarily

for application-level systems, as opposed to general purpose operating systems.









RBAC enforces the following rules on role authorization, role allocation, and

operation execution. RBAC constraints are used to express separation of duty.


1. Role hierarchy If a subject is authorized to access a role and that role
contains another role, then the subject is also allowed to access the contained
role.

2. Static separation of duty A user is authorized as a member of a role only if
that role is not mutually exclusive with any of the other roles for which the
user already possesses membership.

3. Cardinality The capacity of a role cannot be exceeded by the addition of
another role member.

4. Role authorization A subject can never have an active role that is not
authorized for that subject.

5. Role execution A subject can execute an operation only if the subject is
acting within an active role.

6. Dynamic separation of duty A subject can become active in a new role only if
the proposed role is not mutually exclusive with any of the roles in which the
subject is currently active.

7. Operation authorization A subject can execute an operation only if the
operation is authorized for the role in which the subject is currently active.

8. Object access authorization A subject can access an object only if the role is
part of the subject's current active role set, the role is allowed to perform the
operation and the operation to access the object is authorized.

3.5 Distributed Compartment Model

The Distributed Compartment Model [39, 3] was proposed by Steven Green-

wald as a solution to management of system resources and access control in a

distributed computing environment. The model consists of two parts, (i) Dis-

tributed Handles, a means for user identification and access control and (ii)

Distributed Compartments, a method for allowing users to manage resources within

a distributed system across computer system boundaries with a measure of inde-

pendence from any system administrations [39]. The distributed handles eliminate









groupware application userlDs as a means of identification and access control.

A user joining a groupware session is queried for a handle that is unique to that

application and is then verified by a groupware security manager.

Under this method, an individual user would first gain access to a particular

computer system in the distributed system by having a valid user ID and password.

The user would then need a valid distributed handle and would then need to be

validated by the groupware's access control security in order to be allowed access to

the application.

The major advantage of this approach is that security dependencies are re-

duced. Moreover, the handles can be more descriptive than user IDs, for example

"Third programmer" instead of '. 0". Multiple handles can be permitted for the

same user and many users can share the same handle. Distributed compartment

(also called discom) is the designated platform for access control and administra-

tion of distributed handles.

A discom is a logical group of objects that is conceptually similar to a stan-

dard hierarchical directory structure but does not necessarily reside in a single

computer. The users of discoms gain access via distributed handles. A root discom

is called an empire discom. Each discom must have at least one subject called

governor. Governors have the maximum privileges for the discom they govern.

There are 24 basic operations called initial privileges. They include operations

that create, destroy, or modify objects, create, delete, merge, split, or modify child

discoms and empire, create or rescind privilege, create or remove governorships,

subjects or resources, etc. This combination of subjects, objects and privileges,

makes it possible to create a system similar to an access control matrix.

The Distributed Compartment Model has a set of axioms and properties some

of which are:









Divine Right Axiom A subject can create an empire discom only if given that
privilege by the administrators.

Creator Property The creator of a discom automatically becomes a governor
of that discom.

Government Property The governor of a discom may grant and revoke
privileges to non-governor subjects of that discom.

Nova property A non-governor subject may access a descendant discom only
if made a member of that discom by a governor of an ancestor discom.

Cordon Property Discoms may never intersect with other discoms.

Demesne Property The governor of a discom alr--,i- has unrestricted access to
descendant discoms.

Ceiling Property A subject may not access an ancestor discom without being
a subject of that discom.

A distributed compartment is actually a groupware application, with access to the

discoms determined by distributed handles. Management of discoms is not done by

the local system administrators but by the individual users who are governors of

empire discoms.

3.6 Access Control for Collaborative Environments

Based on the work by Greif [40] and Ellis [41], Bullock and Benford [42] have

identified four basic requirements for collaborative access models:


The mechanism must be simple.

The mechanism should be unobtrusive to users.

It should be easy to inspect and change access rights.

The effects of access controls should be understood, and the consequences of
any changes should be clear.

Haake et al. [43] "... found that end-users in order to conduct cooperative work

in shared workspace system have to be able to (1) create groups dynamically









without prior planning of a system administrator, (2) employ different forms of

group formation, and (3) control access rights to their workspaces." AT ii': current

systems lack sufficient support for these requirements.

Shen and Dewan [44] have extended the traditional access matrix model for

groupware with more than 50 basic access rights to handle the various operations

required for collaboration and inheritance based on right groupings. They also

support the notion of negative rights to allow explicit denial of rights.

Park and Hwang in [45] tailor the generic architecture for controlled Peer-

to-Peer (P2P) computing environments to support RBAC. For collaborative

enterprise in such an environment, they identify three different policies: enterprise,

community and peer. A community policy defines the community's User-Role

Assignment (URA), Permission-Role Assignment (PRA), constraints and role-

hierarchy. An enterprise policy defines the enterprise's URA, PRA, constraints,

role-hierarchy and role ontology (an equivalence relation between roles in different

communities [46]). Each peer defines its own peer policy including the peer's PRA

and constraints. The enterprise policy is enforced by a centralized mechanism that

applies to all communities in that enterprise, while a community policy is enforced

by a centralized mechanism within the community. These two mechanisms are

based on the brokered P2P model. If a conflict occurs between policies, enterprise

policies are superior to community policies, which are superior to peer policies

unless specific policy priority is defined.

Jaeger and Prakash [47] define a discretionary access control (DAC) model

for specifying the access rights available to a mobile agent which enables the

reader and writer in a mobile agent computation to flexibly control access to

system objects. They also specify the requirements of RBAC models necessary to

implement the DAC model. In this type of RBAC model, system administrators

define roles for users (as in regular RBAC) but can also define a model that will









enable users to limit the access rights of their own processes. First, system admins

specify the object types that can be used to specify operation access rights. Also,

system admins specify the users who are authorized to limit their own rights

dynamically.

3.7 Trust and Voting

While significant work has been done in the fields of Political Science, Psychol-

ogy, and, Ethics [48, 49], iii,-I of the work concerning trust in computer science

have been concentrated in the area of security ... mainly in the form of formal

logics to analyze cryptographic protocols for design flaws and correctness." [50].

One of the most popular definitions of trust is given by Deutsch [51].


(a) an individual is confronted with an ambiguous path, a path that
can lead to an event perceived to be beneficial or to an event perceived
to be harmful; (b) he perceives that the occurrence of these events
is contingent on the behavior of another person; and (c) he perceives
the strength of a harmful event to be greater than the strength of a
beneficial event. If he chooses to take an ambiguous path with such
properties, he makes a trusting choice; else he makes a distrustful
choice.

Gambetta [52] has defined trust as a particular level of the subjective probability

with which an agent assesses that another agent or group of agents will perform

a particular action, both before he can monitor such action (or independently

of his capacity ever to be able to monitor it) and in a context in which it affects

his own action." This definition has been widely accepted by computer scientists

Gambetta introduced the concept of using values for trust and also defended the

existence of competition among cooperating agents. Trust is closely related to

reputation [53]. Abdul-Rahman and Halies [50] define reputation as an expectation

about an individual's behavior based on information about or observations of

its past behavior. In online communities, where an individual may have very

less information to determine the trustworthiness of others, their reputation









information is typically used to determine the extent to which they can be trusted.

An individual who is more reputed is generally considered to be more trust worthy.

Reputation can be determined in several v-iv. For example, a person may either

rely on his direct experiences, or rely on the experiences of other people, or a

combination of both to determine the reputation of another person.

As mentioned earlier, work concerning trust in computer science has been

primarily focused on cryptography like in [54] and work in voting has be dominated

by electronic voting [55] where the emphasis is on authentication and guaranteeing

that the vote counted as voted. Marsh's model [56], as far as we know, is one of the

few attempts to formalize trust based on the real world social properties of trust.

3.8 Summary

The HRU model is a very powerful model in terms of expressive power.

However, it is very primitive in its construction and has no roles, object types or

other abstractions. Therefore the matrix can be very large (and sparse). It is not

easy to implement this model in a distributed system.

The TAM model takes a huge step forward with the addition of typing.

However, the set of types is static and there are no operations defined in the system

to change the type of an object or subject. As we will show in the later sections,

making it possible for the users to define their own types and change the types

allows us to implement many important and interesting system policies.

RBAC provides a means of naming and describing relationships between

individuals and rights. Some form of RBAC is used in commercial systems tod iv

and some attempts have been made to formalize the model (refer [36]). One of the

i, P"r areas in which the DCS model scores over RBAC is group decisions. Another

restriction is the absence of some mechanism that allows defining one-to-one

relationships between subjects and objects. For instance, consider the ownership

relation. Pure RBAC can handle the case where each object has only one owner,









however, if some objects in the system have a small subset of users as its ownerss,

it is impractical to define new roles such as owner of object 1 (we will need as

n: i in: such "owner 1,.!, as there are objects).

One n1i ri" disadvantage with the Discom model is that users will have to have

a separate handle for each application they use. This means that they will have

to remember not just their user ID and password but the handle and password for

each application. It would have been preferable to avoid such multiple "lc-i-

Since many users can share handles, this reduces accountability. The Discom model

practices a type of monarchy in which the governors have absolute power whereas

a democratic form of government will be more practical in the long run. The

Discom model is really concerned with resource management in hierarchical groups

distributed over multiple domains. The DCS model is concerned with authorization

issues and these two models can be used together, providing a secure, flexible

system.

All the above models require a system administrator to handle the changes in

the system. Incorporating group voting mechanisms allow the users to decide and

implement the group policies. This is one of the main features of the DCS model.

The Jaeger and Prakash model allows system administrators to specify some

DAC features and who can use them. The users with the privilege can control

access to their processes but this is still very limited DAC and does not allow

the groups to decide their own policies (they can do so only for those objects

the system admins allow). The RBAC scheme for P2P environments described

above relies extensively on server controlled decisions and does not support group

decisions. It does however support co-n-ninitv-1. v.l autonomy which allows policy

decision to be made off-line and changes are enforced by someone with admin-level

privileges.















CHAPTER 4
THE DCS-AC MODEL

4.1 Introduction

In this chapter, we will introduce and formally specify the Distributed Con-

ferencing Services Access Control (DCS-AC). We will also discuss the constraints

and rules that are imposed on any system that implements this model. Finally, we

will discuss some of the key features of the model and show the DCS-AC solution

to the software problem mentioned in section 1.2.

4.2 The DCS-AC Model

The access control matrix is often very big and sparse. Role-based Access

Control (RBAC) groups subjects into roles and objects into object 'i',,. thereby

shrinking the matrix. In these systems, each cell in the matrix correspond to the

set of rights the corresponding role (identified by the row) had with respect to the

object type (identified by the column). In the DCS-AC model, we are concerned

with two additional aspects, decision template and target.

The decision template is a pointer to some voting template (see Section 6.2.2)

which should be invoked in order to make a decision on the access request. We

expect most entries in the matrix to point to the Always-;I. template which simply

returns a ;/. without calling for a vote. Typically, requests that result in granting

a right to some role might require a vote but once granted, exercising that right

may not require one. It is up to the users to decide which requests require a vote

and which do not require one. Needless to -iv, any request that requires a vote

will take some time to be processed and so, the group policies should be designed

carefully.









The target field is a very powerful idea which helps us achieve fine-grained

access control (see Section 4.6.5). Instead of -,i-ing "role President can allow

subjects to bind to the role ExecutiveM. ni,,l by using a target field, we can

specify the right in finer detail by -,i-ing "role President can allow subjects of

role TrustedMember to bind to the role ExecutiveM. m,,, Here, the target is the

role TrustedMember since we are narrowing down the scope of this right to just

this role. Depending on the type of command being executed, the target can be a

role, object type or a right. In the case of rights for which the target field is not

applicable, it is null and the keyword i;i, specifies that the right can be exercised

on any target.

The distribution of rights in the system are can be viewed as an access matrix

(implemented as a five-field RDBMS table), A. The cell A[X, Y] contains a set

of (p, Z, dp) tuples where p is a right which role X has for objects of type Y with

respect to a target, Z and dp is a pointer to a decision template that must be

activated each time X makes a request to perform p on (Y, Z).

We achieve a great deal of flexibility by allowing the group to dynamically

change a 1 ii' r part of the system components. Unlike the TAM model, we allow

types (i.e., roles and object types) and type bindings (subject-role and object-type

bindings) to be added and deleted dynamically by the group according to the group

policy as represented by the matrix. Similarly, the set of rights and the available

decision templates can also be changed while the system is in operation. The only

static component of the model is the set of commands which are the same for all

instances of the model.

Each subject can bind to one or more roles but at any point of time, the

subject can be active in only one role. The user can temporarily change his/her

active role to another role to make a request that is not allowed for his/her current

role. One of the main reasons for this restriction is that the user has to be aware









of the increased responsibility while requesting access that requires membership to

a privileged role. Each object is bound to one object type. These bindings can be

changed by .in:one who has the right to do so. This is a ii, difference from the

TAM model in which the bindings are a part of the system definition and can only

be altered by an external administrator. In the DCS-AC model, the administrator

is considered to be a part of the system and is subject to the access restrictions

imposed by the matrix. An instance of DCS-AC has the following finite dynamic

sets:


a set of access rights denoted by R,

a set of decision templates denoted by D,

a set of object types denoted by T,

a set of roles denoted by TR(C T),

a set of objects denoted by OBJ, and

a set of subjects denoted by SUB.

The access control matrix is denoted by A. We have three mapping functions, fr

which maps each subject to a subset of TR (corresponding to the roles to which

the subject can bind), fo which maps each object to an element of T (its object

type)1 and f, which maps each active subject to his/her active role.


f, : SUB 2T


fo : OBJ T



1 If an object is allowed to be of more than one type, access control decisions are
difficult. Should a user have rights to access all object types of an object in order
to access the object? An alternative is to define an object type hierarchy, which
increases the complexity of the model.









Table 4-1: Example of DCS-AC Matrix Fragment

Role Object Type Target Right Template
1 Programmer Code null Read dyes
2 Programmer Code null Write dyes
3 Programmer Code Read GrantRight di


f, : SUB-TR

The state of a DCS system is the tuple (A, R, D, T, TR, OBJ, SUB, fr, fo) and as

noted earlier, the set of commands C (defined in section 4.4) is the only static

component of the model. A few simple examples of the matrix entries are given in

table 4.2. Here, Programmer is a role and Code is an object type. Read, and Write

are access types and dyes is a pointer to the Ala, .--;. template. The first three

entries allow subject who are actively in the role Programmer to read and write

objects of type Code. The third entry allows Programmers to grant Read access

to anyone if the decision template di returns yes. The decision template dl might

require the approval of the Project Leader and Dev Team Manager. GrantRight is

a special access right that corresponds to a primitive operation that adds an entry

to the matrix.

4.3 Operations

Lets us now look at the primitive operations that can be executed on a DCS-

AC system. These are operations that modify one or more components of the

system and are guaranteed to be atomic. We will formally define the operations

by specifying their effect on the system. Let (A, R, D, T, TR, OBJ, SUB, f,,

fo) denote the system before the operation and (A', R', D', T', TP, OBJ', SUB',

f fo) denote the system after the operation. Table 4.3 defines the primitive

operations in DCS-AC. Note that sets not mentioned in the definition of an

operation are unchanged by that operation. There is one command for every

operation but we might want to have commands with two or three operations

especially if we want roles and object types to have pedigree (see section 7.1).











Table 4-2: Specification of DCS-AC Operations


Operation Precondition Postcondition


grantright(r, ot, p, t, dp)



revokeright(r, ot, p, t)



createrole(r)


deleterole(r)


createot(ot)


deleteot(ot)

addobject(o, ot)


delobject(o)

addsubject(s, r)


r E TR,t TUR,
tE T, pE R, dp E DT,
Vdpl e DT,
(P, t, dp1) V A [r, ot]
r c TR,t TUR
ot T
pER

r TRp


- s, f(s) {r}


ot V T


-3o, fo(o)

o OBJ
ot T



re Tp


A[ri, oti]



A[ri, otl]


r,ot] A (pi / p) A (ti t)}

[ri, oti] A[ri, otl]


'[ri, ot] = A[ri, oti]
(s) {r}


(pi,ti,dpi) c A[
TR = TR U {r}
V (ri,oti) E TR x T,A'
V otl e T, A'[r, otl] 0
TR = TR {r}
V (ri, oti) Ti xT, A
V sl E SUB, f((s) f,
T' TU {ot}


V(r, oti) Tp X T', A'[ri, oti] A[ri, oti]
Vrl E TR, A'[ri, ot] 0=
T' T' {ot
V(r, ot) E TR x T', A'[r, ot] = A[r, ot]
OBJ' OBJ U {o}
Vo1 e OBJ, f(ol) fo(ol)
f'(o) = ot
OBJ' = OBJ {o}
Vo1 E OBJ', f'(ol) = fo(ol)
SUB' = SUB U {s}
V sl E SUB, f/(si) f,(si)
f;(s)= {r}


V (ri, oti) TR XT,
((r, oti) / (r, ot)) -A'[ri, otl]
A'[r, ot] A[r, ot] U {(p, t, dp)}

V (ri, ot) E TR x T,
((ri, oti) (r, ot)) A'[ri, otl]
A'[r,ot]= {(p1,ti, dp1) :
















Table 4.2: Continued


Operation Precondition Postcondition
delsubject(s) SUB' = SUB {s}
Vs1 E SUB', f (si) f,(si)
addaccess(p) R' = RU {p}
delaccess(p) R' R- {p}
V (r, ot) E TR x T,
A'[r, ot] = {(p, t, dp) : (pi, t, dp) E A[r, ot] A (pi / p)}
,,l,;,,.1 1,].,/1,,,(s, r) s c SUB Vs E SUB -{s}, f(si) f,(si)
r e TR f(s) f(s)U {r}
delrolebinding(s, r) s E SUB Vsi E SUB {s}, f,(si) = ,(si)
r TR f'(s) = f,(s) {r}
fr(s) {r}
lilj'. .r,t, ot, p,dp) r TR,tETUR V (ri, otl)E T x T,
ot ET ((ri,oti) / (r,ot)) --A'[ri, otI] A[ri, ot]
p R A'[r, ot] {(p, ti, dpl) : (pl, ti, dpl) E A[r, ot] A pi /pAt / t}
dpC DT U {p,t,dp}
, I1,,'I...(o,ot) o OBJ Vo1 E OBJ,ol / o f(ol) fo(ol)
ot c T f (o) = ot









4.4 Commands in DCS-AC Model

The access control matrix can only be modified through the set of commands

which is the only static component in the DCS-AC model. Unlike the HRU and

other models, the set of commands does not vary from system to system. There

is one command for each primitive operation; it checks if the subject's role has

the right to perform the operation and if so, then it performs the operation. A

command consists of two parts: a conditional part that checks if the role is allowed

to make the request and an execution part that executes one operation. All objects

belonging to the access control model (like A, fo, DT, T, Tp etc.) are of the object

type F. Given below is the list of commands in DCS-AC. In all these commands, r

is the role of the subject executing the command.


command CreateRole(r E TR, new V TR)
if ((CREATEROLE,null,dp) A[r,F]) for some dp E DT and dp
returns true then
createrole(rnew)

command DeleteRole(r G TR, r1 E TR)
if -3s, f(s) = {ri} and ((DELETEROLE,null, dp) e A[r,ri]) for some
dp G DT and dp returns true then
deleterole(ri)

command GrantRight (r E TR, rl c TR, t E TU R, ot E T, p c R, dpl E DT)
if -3dp2,(p,,dp2) G A[ri,ot] and ((GRANTRIGHT,p, dp) c A[r,ot]) for
some dp G DT and dp returns true then
grantright(ri, ot, p, t, dpi)

command RevokeRight(r c TR, rl E TR, t TU R, ot E T, p e R)
if ((REVOKERIGHT,p, dp) E A[r,ot]) for some dp E DT and dp
returns true then
revokeright(ri, t, ot, p)

command CreateOT(r E TR, ot V T)
if ((CREATEOT,null, dp) A[r,F]) for some dp E DT and dp returns
true then
createot(ot)









* command DeleteOT(r E T, ot E T)
if -io,fo(o) = ot and ((DELETEOT,null, dp) E A[r,ot]) for some
dp E DT and dp returns true then
deleteot(ot)

* command AddSubject (r E TR, Snew SUB, initial E TR)
if ((ADDSUBJECT,rinitial, dp) E A[r,F]) for some dp E DT and dp
returns true then
addsubject(s, initial)


* command DelSubject(r E TR, s SUB)
if ((DELSUBJECT,null, dp) E A[r,F])
returns true then
delsubject(si)

* command AddObject(r E TR, o OBJ,ot
if ((ADDOBJECT,null, dp) E A[r,ot])
returns true then
,,7,, i., /(o, ot)

* command Del0bject(r TR, o e OBJ)
if ((DELOBJECT,null, dp) E A[r,ot])
returns true then
delobject(o)


for some dp G DT and dp



E T)
for some dp G DT and dp




for some dp G DT and dp


* command AddRoleBinding(r E TR, s c S, ri c TR)
if ((ADDROLEBINDING,rs, dp) E A[r,rl]) for some dp E DT and
rs E f(s) and dp returns true then
addrolebinding(s, ri)

* command DelRoleBinding(r E TR, s G S, ri G TR)
if fr(s) / {ri} and ((DELROLEBINDING,null, dp) e A[r,ri]) for some
dp G DT and dp returns true then
delrolebinding(s, ri)

* command ChangeOT(r E TR, o E OBJ, otnw E T)
if ((CHANGEOT,fo(o), dp) E A[r,ote,]) for some dp E DT and dp
returns true then
changeot(o, otnew)

* command AddAccess(r G TR, p R)
if ((ADDACCESS,null, dp) E A[r,F]) for some dp E DT and dp
returns true then
addaccess(p)









command DelACCESS (r TR, p R)
if ((DELACCESS,p, dp) E A[r,F]) for some dp E DT and dp returns
true then
delaccess(p)

command ChangeDP (r E TR, rl E T t TU R, ot T, p E R, dpnew E DT)
if 3dpli,(p,t,dpi) E A[ri,ot] and ((CHANGEDP,p, dp) A[r,ot]) for some
dp E DT and dp returns true then
changedp(ri, t, ot, p, dpnew)

It is obvious that all the commands can be executed in constant time (as-

suming an that looking up the access matrix and other DCS-AC components can

be done in constant time). Moreover, the roles and object types created by the

CreateRole and CreateOT commands have no pedigree, i.e., the creator of the role

or object type has no special rights over that role or object type. We also allow the

object type, access right and the target to be replaced by the keyword ANY. For

example, if (ANY, ANY, dp) E A[Secretary, ANY] where dp is a decision template

that calls for a simple i I i i, ily of all subjects who can bind to the role Senator,

then a Secretary can make any change to the system if approved by a iI i ii i ly

of the senators. Since the roles and object types have no pedigree, there has to

be a group policy for granting rights to these roles and object types (typically,

(GRANTRIGHT, ANY, someDP) E A[SomeRole, A111]).

4.4.1 Constraints

There are a few constraints that have to be enforced on the system, some of

which have been mentioned earlier.


Active Role At no point of time can a subject be active in more than one
role.

Role Authorization A subject can only be active in roles he/she is authorized
to be in.

Operation Authorization A subject can perform only those operations that
his/her active role is authorized to do.









Object Access Authorization A subject can only access those objects his/her
active role is authorized to do.

Amendment Rule There should alv--, be a rule that allows the group to
modify any component of the system.

Delete Restriction A role or object type cannot be deleted if it results in a
violation of the rules and constraints.

Graceful Deletion If an active subject is deleted from the system, the deleted
subject should lose all right immediately.

Decision Template Overwrite Rule A GrantRight command should not be
allowed to change the decision template of an already granted right.

The Active Role constraint is enforced to simplify the access checking process. The

Role Authorization, Operation Authorization, and Object Access Authorization

are RBAC enforced constraints. Amendment Rule is like an emergency override

to allow the group to recover from unusable states. Typically, this is enforced by

a matrix entry that allows a particular role to change anything if some template

returns a yes. For example, the Chairman can change any rule if all the F2I. ,1/ I

and the College Dean agree.

The Delete Restriction is imposed on deletion of roles and object types. If

there is a subject that can bind to only one role, then deleting that role means that

the subject cannot bind to any role. This is an inconsistent state and should be

avoided. This subject should be deleted or allowed to bind to another role before

deleting this role. Furthermore, if there is a subject currently active in a particular

role, then that role cannot be deleted. Similarly, if there is at least one object that

belong to a particular type, that type cannot be deleted.

The G, r, ful Deletion rule is for deleting subjects who are currently active.

They should be immediately 1. 1.-.-- 1 out of the system with suitable notification

messages. The Decision Template Overwrite Rule prevents some subject from

changing the decision template for an entry in the matrix by using the GrantRight









command. This is enforced by ensuring that no GrantRight command grants an

already existing command. The decision template pointers for an entry can only be

changed by the Ci', ,, I)P command.

4.4.2 Expressive Power

It is well known that the HRU model has very good expressive power but is

very weak in terms of provable safety. It can be seen that the DCS-AC model also

has very good expressive power. Any HRU protection state can be converted to the

DCS-AC model.

Mapping from HRU to DCS-AC

Consider a protection system (R, C) and a state (S, O, P). Let us define a new

role for each user and allow only that user to bind to that role and call the set of

these roles TR. Similarly, define a new object type for each object and call this set

T. We define DT = {dp} where dp is a pointer to a decision template that alv--xi

return i, Let the new DCS-AC instance be (R, DT, T, TR, O, S, fo, fr, A).


V oi G 0 add a new object type oti to T and let fo(oi) = oti

V Si E S add a new role ri to TR and let fr(si) = {ri}.

A[r, ot] = {(p, null, dp): p G P[si, oi}

Now we have an instance of DCS-AC model defined by (R, DT, T, TR, O, S, fo,

fr, A). Although the system state in the two models are equivalent, the systems

themselves are not equivalent because we have not mapped the commands of the

HRU model to something equivalent in the DCS-AC model.

Mapping from DCS-AC to HRU

Similarly, we can do a mapping from DCS-AC to HRU. Here again, the two

systems will not be equivalent because of dynamic typing and decision pointers.

Consider an instance of the DCS-AC model (R, DT, T, TR, OBJ, SUB, f,, fo, A).









We can convert this into a HRU system (R', C) with the configuration (S, O, P) as

follows:


1. R' = R Rm where Rm is the set of all matrix manipulation operations
not supported by HRU.

2. S = SUB and 0 = OBJ

3. V(s,o) SUB x OBJ
(a) Vr E f,(s), P[s, o] = {p : (p, null, dp) E A[r, fo(o)] A p f Rm}

4. Add commands to perform each of the six operations if the subject has the
right similar to the one specified in section 4.4.

Note that the resulting HRU instance is a mono-operational one and hence the

safety of this is decidable in NP time. Here, we drop all typing information,

decision pointers and operations not allowed by HRU.

4.5 Comparison with existing models

One 1i ii Pr difference between the DCS-AC model and the other models is the

fact that the AC'\ I itself is an object and there is a right corresponding to each of

the above mentioned operations. If a user wants to perform a matrix modifying

operation, then his/her role should have the right to do so. It must be noted that

in TAM, R, T, TR and t are all part of the system definition and cannot be altered

by anyone within the system, whereas these are a part of the DCS-AC model

instance and can be modified by anyone who has the right to do so. TAM does not

have the notion of decision pointers either. TAM allows any number of parameters

in its commands but the DCS-AC allows at most five.
+ Dynamic Typing
Strong Tping + Decision Pointers
Arbitrary Commands

Figure 4-1: Comparison of HRU, TAM and DCS-AC models


The TAM model added the notion of strong typing to the HRU model.

The DCS-AC model has dynamic typing, static set of commands (as opposed to









arbitrary commands) and most important of all, decision template pointers that

allows the members of the group to decide on access right issues. Another i i" r

difference is the dynamic set of access rights. As mentioned earlier, the term role

as used in the DCS-AC model is different from what it means in RBAC. Here are

some differences between the two:


Role Hierarchy There is no role hierarchy in the current implementation of
the DCS-AC model. Subsection 7.3 talks about how the DCS-AC model can
be extended to implement role hierarchy.

Static Separation of Duty The DCS-AC model does not support static sep-
aration of duty. However, it is possible to implement dynamic separation of
duty using function calls. All separation of duty policies can be implemented
as dynamic which provides greater flexibility to the users.

Decision Pointers The use of decision pointers is the new paradigm introduced
in this model. As mentioned earlier, this addition is very useful in specifying
various system policies.

4.6 Features of DCS-AC Model

The access control matrix and the functions mapping various sets are stored

as tables in a backed database which is replicated across all sites. All updates

and deletions are propagated to other sites by a separate Database Services module

(DBS) which guarantees processor consistency for updates, i.e., updates originating

from the same processor will be committed at all sites in the same order. This

is achieved by assigning an owner site for each tuple in the table. When a new

tuple is to be added, the site the request originated is the owner. Modifications

to a particular tuple are forwarded to its owner which then multicasts to other

sites. The decision templates are maintained by the Decision Support Services

module (DSS) which stores the vote participants, percentage of votes required for

success and other information about the template. When the access control module

initiates a decision, the participants are notified and the votes are collected. Once

a decision is reached, the DSS passes it to the access control module which takes









further action as required. Note that in many cases, the decision pointer may point

to a template that alv--,v- returns a ; -

4.6.1 Decision Templates

Decision templates are one of the most interesting features of the DCS-AC

model. The use of group voting mechanisms allow the users to self-administer their

groups. It is quite clear that the safety of the system will depend very heavily

on the decision pointer. It will be very interesting to study the various types of

collusion attacks possible based on a given set of decision pointers. A decision

template contains the following information: (i) A list of voters along with the

weight of each entity's (role/subject) vote, (ii) number of voters for quorum, (iii)

start and end times, (iv) percentage of voter who have to agree for the vote to pass,

(v) default policies if quorum is not reached, and (iv) other bookkeeping details like

who should be notified of the result etc. The template also specifies what kind of

vote to start (ranking, simple i1: ii, ,iily, multiple rounds, etc.). It is expected that

most access requests will invoke a simple decision template that ahv--, returns .;/,

and only a few access requests (like granting a right to a role or any thing deemed

important by the group) will require a vote.

If we allow the decision pointers to be pointers to a voting process or a

function call that returns a decision based on the state of the system, we can

implement interesting policies like the separation of duty. If the global policy

states that any user who has access to objects of type 01 should not have access

to objects of type 02, then the decision pointer will execute a function that allows

the access only if the cell corresponding to [R, Oi] is null for every R in the set of

all roles the subject can bind to. However, the use of function pointers might make

the access right leakage problem undecidable and is currently not a part of the

DCS-AC model.









4.6.2 Dynamic Type Binding

The binding between objects/subjects and their types is static in TAM (HRU

does not have types). There are many scenarios in which this binding has to be

changed. By allowing the bindings to change, we can also model process work

flows. For example, if the group policy states that the review team should not

be able to access the code until it passes the testing phase. We can define three

different object types, working code, ready-for-test and ready-for-review. When the

code is ready for'. -1 ii:- the project leader or the developer can change the object

type of the files to ready-for-test. Now the testers can do their job. An additional

advantage in doing things this way is that the programmers cannot modify the files

that are being tested (if they do not have that access for objects of type ready-for-

test. If the code fails testing, the PL can change its type back to working code else,

he/she can change it to ready-for-review.

4.6.3 Dynamic set of Access Rights

As mentioned earlier, one of the differences between the DCS-AC model and

the other models is the fact that the access rights are not a part of the system

definition. When a new application is added to a system with a static set of access

rights, fine-grained access control has to be managed by the application itself. In

the DCS-AC model, when a new application is added, we can define new access

types to the system and make access control decisions at the system level. For

example, if a new audio-video application is added, we can define new access types

like j/'l;, audio file, recompress the file, cut and crop files, etc. Now, based on the

roles (like producer, sound engineer, etc.) it is straightforward to define access

control policies like a producer can pl il an audio file but cannot modify it, a

sound engineer can pl ii-, recompress, cut and crop an audio file. We can also define

special relations so that only the producers and sound engineers working with a









particular artist can access the audio files recorded by that artist. As we can see,

the realm of possibilities is very large.

4.6.4 Dynamic set of Object Types

In most real world scenarios, it is impossible to keep the set of object types a

constant. We cannot foresee all possible object types during system initiation and

although the need may not be very frequent, it is very likely that any system will

need new object types at some point of time. When a the audio-video application

mentioned in the previous section is installed, we have to create a new object

type (called audio file). It is quite possible to just use the type generic file and

individually specify the access rights for each audio file. This is how it will have to

be done in TAM. However, the main advantage of using types is the reduction in

the size of the AC' I and hence, specifying the rights for each and every audio file is

counter-productive in terms of AC\ I size. Thus it is more logical to allow the set of

object types to change with the needs of the users.

4.6.5 Fine Grain Access Control

As can be seen from the commands in DCS-AC (Section 4.4), the use of

the /,1,., I field allows us to define very fine grained access control policies. For

example, we can specify that role r has the right to grant read access to objects of

type ot ((GRANTRIGHT, read, dp) E A[r, ot]) and we can similarly specify revoke

rights for specific accesses. Another instance of fine grained access control is the

Cliq.I'OT command. If a manager can declassify a TopSecret document to Secret

but too only with the approval of the CEO, then (CHANGEOT, Secret, dpi) E

A[M n,,.,I. r, TopSecret] where dpl is a decision template that has only one voter,

the CEO. This level of granularity is not available in most access control models in

use todv.









4.7 DCS-AC Model Solution for Software Project Example

Here is a solution to the software project example mentioned in section ref-

motivation using the DCS-AC model. Let the set of roles be TR {PL, Architect,

Prog, Tester}. When the project (lets call it X) is started the following object

types are created: XDesignDoc, XCode, XWorkingCode, XTestedCode and XShip-

Code. The following roles are also created: XPL, XArchitect, XProg and XTester.

We now add the entries specified in table 4-3 to the access control matrix, A.

Here, dpi is a decision pointer that albv-i- returns P. dp2 requires a vote of

all subjects who can bind to XProg and dps requires a vote of all subjects who can

bind to PL. Entries 1,2 and 3 allow the X PL to decide who works on a project

but ensures that policy 6 (PL cannot change the role of an employee) is enforced.

This is a simplistic view of things and it is very easy to envision a system where

compile and execute are valid accesses which are used by a DCS-aware development

environment.

Thus class libraries example is solved by using the DCS-AC model. Similar

solutions are suitable for collaborative contract editing and many other distributed

collaborative applications. This example also illustrates how the DCS-AC model

can be used to model process work flow.











Table 4-3: DCS-AC Solution for Software Project Example


No. Entry Explanation


(ADDROLEBINDING, Architect, dpi) E A[XPL, XArchitect]

(ADDROLEBINDING, Prog, dpi) E A[XPL, XProg]

(ADDROLEBINDING, Tester, dpi) E A[XPL, XTester]

(ADDOBJECT, null, dpi) E A[XArchitect, XDesignDoc]

(read, null, dpi) E A[XArchitect, XDesignDoc]
(read, null, dpi) E A[XPL, XDesignDoc]
(write, null, dpi) E A[XArchitect, XDesignDoc]
(read, null, dpi) E A[XProg, XDesignDoc]
(ADDOBJECT, null, dpi) E A[XProg, XCode]
(read, null, dpi) E A[XProg, XCode]
(read, null, dpi) E A[XPL, XCode]
(write, null, dpi) E A[XProg, XCode]
(CHANGEOT, XCode, dp2) A[XProg, XWorkingCode]

(read, null, dpi) E A[XTester, XWorkingCode]
(CHANGEOT, XWorkingCode, dpi) E A[XTester, XCode]

(CHANGEOT, XWorkingCode, dpi) E A[XTester, XTestedCode]

(read, null, dpi) E A[PL, XTestedCode]

(CHANGEOT, XTestedCode, dp3) E A[XPL, XShipCode]


The PL can assign architects
to the project
PL can add programmers to
the project
PL can add testers to
the project
Architects can create design
documentation
Architects can read the docs
The PL can read the docs
Architects can write to docs
Programmers can read the docs
Progs can create code files
Progs can read the code files
PL can read the code files
Progs can write to the code files
Progs take a vote to submit
code for testing
Testers can read working code
Testers can return code
to programmers
Testers can mark code ready
for review
All PLs in the company can
look at tested code.
PL can ship code if
review team agrees









4.8 Summary

In this chapter, we defined and discussed the DCS-AC model. One of the main

features of this model is the ability of the subjects to vote on important (as defined

by the group) decisions. All subjects belong to one or more roles and all objects

belong to an object-type. The access matrix entry for a particular role and object

type contains a set of ordered pairs corresponding to the rights the role has over

the object type and the decision template that is executed when a subject of that

role tries to use that particular right over the object type. The decision template

might point to the Al, i. ;--.;. template (which ah--iv returns .;. -) or any other

template defined by the group. There are sixteen primitive operations and sixteen

commands (each of which correspond to one of the operations). These are the

only static components of the model. The group can define and modify all other

components like roles, object types, etc. dynamically. There are a few constraints

that have to be enforced when implementing this model. The commands in DCS-

AC are designed in such a way so as to allow fine-grained access control, i.e., we

can specify rules like Role X can allow a subject of role Y to bind to the role Z

instead of just a more general rule like Role X can allow a subject to bind to role Z.

It should be remembered that while all these features are really powerful, care

must be taken to avoid getting into a state that makes the system difficult to use.

The Amendment Rule constraint enables the group to recover from any such bad

states. In the next chapter, we will prove that the model is provably safe.















CHAPTER 5
SAFETY ANALYSIS

5.1 Introduction

The presence of decision pointers makes the safety analysis of the DCS-AC

model very tricky. Consider a restricted version of DCS-AC where there is only

one decision pointer in the system, dp, and that pointer ah--,i- returns true. This

is a valid restriction because, if trusted deciders control a decision, they will vote

no, so we can remove these entries from the matrix and any decision controlled by

untrusted deciders will, in the worst case, ah--,i-b result in p. We will first analyze

the safety of such a restricted model and in the next chapter, we will discuss the

safety of the full model.

5.2 Definitions

Let us now look at some definitions that will help us understand the safety

properties of the DCS-AC model.

Definition The state, S, of a DCS-AC system is a snapshot of the system at a

given time. It consists of the access control matrix A, the role binding function fr,

the object type binding function fo, and the following sets:


set of rights R,

set of subjects SUB,

set of objects OBJ,

set of object types T,

set of roles TR (TR C T), and

set of decision templates DT.









Definition For a given state S, object type ot, and right p,


s,p,ot {s : s E SUB A 3 r E f,(s),t E (TURU0) such that (p,t,dp) E A[r,ot]}

In other words, 4s,p,ot is the set of all subjects who have the right p for objects of

type ot in S. We can get the set 4s,p,ot in O(ISUBI TRI IRI) time as follows:

function getPhi (S, p, ot)


1. result = 0

2. for all s SUB
(a) for all r fr(s)
i. for all (p',t',dp) E A[r,ot]
A. if p' p then
result = result U {s}
Process next s

3. return result

Definition Given two states, S and S', and a command, a, we S -, S' if the

command a can be executed on S and S' is the result of performing the operation

in a on S (i.e., applying a on S results in S').

Definition Given two states S and S', and a sequence of commands a (containing

k commands, al, a2, ..., ak), we il


S ,Sif k 0 S S'k 1 S-, S'
S S' if
k > 1 = S -1 Si A Si ,-' S', where a' = a2, a3,..., ak

Definition For a given DCS-AC state S, object o, and right p, we i- that a

sequence of commands a results in a leaking state if and only if


S -- S' = 4)S,,p,f(o) 4S,p,fo() / 0


Let us now define the access right leak problem in the context of the DCS-AC

model.









Definition For a given DCS-AC state S, object o, and right p, the access right

leak problem is a decision problem is the question, does there exist a sequence of

commands on S that results in a leaking state.

5.3 Attributes of a State

In order to help us keep track of the commands that have been executed and

those that can be executed, we identify certain attributes which are dependent on

the current state of the system. Each of these attributes can be active (i.e., the

command has been executed), enabled (the command has not been executed but

there is some role in the current state that can execute the command), or inactive

(the command has not been executed nor can any role execute the command in the

current state).

For any state St (reached by executing 0 or more commands on the starting

state SO), the following attributes are valid:


1. HasRightr,0ot,p',t This attribute tracks the GrantRight commands and
is said to be active for St if (p', t, dp) E A(r', ot') for some dp E DT.
If the attribute is not active, we -i,- that this attribute is enabled if
3 r, dp' such that (GRANTRIGHT, dp') e A(r, ot')

2. CanB.:,.1,r,/ This attribute tracks subject-role bindings and is said to be
active for St if r' E fr(s'). If the attribute is not active we -i- that this
attribute is enabled if 3 r, dp' such that (ADDROLEBINDING, dp') E
A(r, r')

For a given starting state SO and a descendant state St (reached by executing 1 or

more commands on the starting state So, i.e., 3o such that l|l > 1 A So St),

we identify the following attributes that are valid for St and all states that result in

executing a sequence of commands on St:


1. NewRole This attribute is said to be active for St if one of the commands
we have executed on SO is a CreateRole command. It cannot be active for
So. If the attribute is not active, we -i,- that this attribute is enabled if
3 r, d' such that (CREATEROLE, d') E A(r, F)









2. NewOT This attribute is said to be active for St if one of the commands we
have executed on So is a CreateOT command. It cannot be active for the
initial state S. If the attribute is not active, we -;v that this attribute is
enabled if 3 r, d' such that (CREATEOT, d') E A(r, F)

3. NewSubject,, This attribute is said to be active for a state St if one of the
commands executed is a AddSubject command with the initial role r'. These
attributes cannot be active for S. If the attribute is not active we -v- that
this attribute is enabled if 3 r, dp' such that (ADDSUBJECT, dp') E A(r, r')

These attributes are activated by executing the corresponding commands.

Active(S') is the set of attributes that are active in a state S' and Enabled(S')

is the set of attributes that are enabled in S\.

5.4 Proofs

Let us now look at a few lemmas and theorems that will lead to a polynomial

time solution to the ARL problem for at DCS-AC system without voting.

Definition We -i- that two states S' and Sj (with the same starting state SO) are

equivalent in terms of access right leakage if:


S' is a leaking state #z S is a leaking state



Axiom 1 In a DCS-AC system with an initial state S, two sequences of com-

mands, al and a2, result in equivalent states if the active attributes of the two

r, -.il:,.,i state are the same.


(S ->, S1) A (S -, S2) A (Active(S1) = Active(S2)) 1 S1 S2

Lemma 2 For a given state S, object o, and right p, if there exists a sequence of

commands a that result in a leaking state, then there exists a sequence of commands

a' such that:


* a' results in a '.., /':ui state and









a does not contain iwi;, command that revokes a right or deletes a subject,
object, role, object type or access.

Proof Let a = al, a2,..., oak and let ai be the first revocation or deletion command.

Let j (1 < j < k) be the smallest number such that the sequence al

ac, ..., aj results in a leaking state S'. Clearly, j / i since ai is a revocation or

deletion command.

Case 1: j < i

If j < i, then the sequence a1 results in a leaking state and does not contain

any revocation or deletion commands (since ai is the first such command and

j < i) and hence a1 is the sequence we are looking for.

Case 2: j > i

Consider the sequence a2 = al, ..., ai- i+, ..., aj. We know that the

commands ai+l, ..., aj can be executed even if we had executed ai (which removes

something from S). Moreover, all commands check for the presence of some right

and not for the absence. Therefore, the commands in a2 can still be executed and

hence, this sequence will also result in a leaking state.

Repeating the above step for all revocation and deletion commands in a, we

get a', a sequence which does not contain any revocation or deletion command and

results in a leaking state if a results in a leaking state. I

Lemma 3 For a given state S, object o, and right p, if there exists a sequence of

commands a that result in a leaking state, then there exists a sequence of commands

a' such that:


a' also results in a '. i.:,'i state and

a' does not contain i,:1, AddObject, AddAccess, or C('!h igeDP commands.

Proof Let a = al, a2,..., a, and let ai be the command that adds a new object

ol. We construct a1 by removing ai and all other commands in a that change









the object type of ol. Since Clhi.,,. OT is the only command that depends on the

existence of ol, all the other commands can still be executed.

Since the presence or absence of ol does not affect the right leak for o (as per

the definition of right leak problem above), if a results in a leaking state, then a1

also results in a leaking state.

Repeating the above steps for all AddObject commands, we get a sequence a2

which does not contain any AddObject commands and results in a leaking state if a

results in a leaking state.

Using similar arguments, we can remove all AddAccess commands from

a2. Moreover, since there is only one decision pointer in the system, C'lI'h,, 1)P

commands can ignored.

So we now have a sequence a' which does not contain any AddObject, AddAc-

cess or Clh,i,, I)P commands and results in a leaking state if a results in a leaking

state. I

Corollary 4 For a given state S, object o, and right p, if there exists a sequence of

commands a that result in a leaking state, then there exists a sequence of commands

a' such that:


a' also results in a I. .rl.:,.,i state and

a' does contains only CreateRole, CreateOT, AddSubject, GrantRight,
AddRoleBinding, and C('!I i .OT commands.

Lemma 5 For a given state S, object o, and right p, if there exists a sequence of

commands a that result in a leaking state, then there exists a sequence of commands

a' such that:


a' also results in a I. .rl.:,.,i state and

a' does not contain more than one CreateRole and one CreateOT command.









Proof Let a = c a2, ..., am. We will construct a new sequence, ao, as follows:


1. Let a create i new roles, rl, r2, ..., ri.

2. Remove all CreateRole commands in a commands except the first one (only
rl is added).

3. Replace all occurrences of rj (1 < j < i) with ri in all the remaining
commands.

The roles have no pedigree (i.e., the creator of a role does not have any special

rights over the role). Therefore, if some role r' can grant a right or allow a subject

to bind to r2, then r' can do the same to rl. Since new roles have no pedigree, if

some role, r, can execute a command a that affects rj in some way, then r can

execute a to affect rl in the same way. Therefore, for a given state S, if a results in

a leaking state, then ao results in a leaking state and vice versa.

Similarly, we can remove all but the first CreateOT command from a1 and the

resulting sequence, a' results in a leaking state if a results in a leaking state and a'

contains no more than one CreateRole and one CreateOT commands. |

Remark When the only CreateRole command is executed, it activates the

NewRole attribute. Similarly, the execution of CreateOT command activates the

NewOT attribute.

Lemma 6 For a given state S, object o, and right p, if there exists a sequence of

commands a that result in a leaking state, then there exists a sequence of commands

a' such that:


a' also results in a 1. a.. ,:,i state and

a' does not contain more than |TR\ + 1 AddSubject commands.

Proof By lemma 2, we can assume that a does not have any revocation or deletion

commands.









Let a contain n commands that add a new subject with the initial role

rl. AddRoleBinding is the only command other than AddSubject that directly

addresses a subject.

Let gp(k, ri) be the statement that if a adds k new subjects with initial role rl,

then there exists a sequence of commands that results in a leaking state and adds

only one new subject with initial role rl.

Base Case: k= 2

When the first subject si is created, f,(si) = {ri}. When the second subject

s2 is created, f,(s2) C fr(si), therefore, any new role binding added for s2

can also be added for sl. Let us construct a new sequence a- by removing the

AddSubject(r', ri, 82) command, replacing every occurrence of s2 with si in all

AddRoleBinding commands and retaining all other commands.

Let S -, S' and S -,, S1. By construction, Si has all the rights in Si

that S2 has in S' and neither si nor s2 were a part of S. We also know that S' is a

leaking state (since a results in a leaking state). Now, we will prove that S1 is also

a leaking state.

Case 1: The newly created subject s2 caused the leak.

If s2 gets the right p over o in S', then si gets p over o in S1. Therefore, if s2

was the cause of the leak in S', then sl will cause a leak in S1.

Case 2: The right leak was due to some other command in a.

Since all the commands other than those that have s2 as a parameter have

been retained in a-, if commands other than the ones affecting s2 caused the leak

in S', then those same commands will cause a leak in S1. Therefore, S1 also results

in a leaking state.

Hence, if a adds two new subject with initial role ri, then we can get a new

sequence that also results in a leaking state but creates only one subject with

initial role rl. Therefore p(2, ri) is true.









Induction Step: Assume p(k 1, ri) is true (k > 2).

Let the k subjects added by a with initial role be sl, 2, ..., Sk. We can con-

struct a sequence of commands, k which does not add the subject s2 but still

results in a leaking state using the construction mentioned above. Now, we have a

sequence of commands that adds k 1 new subjects with initial role rl that results

in a leaking state.

Since p(k 1, ri) is true, we can replace Uk with a new sequence a' that adds

only one new subject with initial role rl and still results in a leaking state.


p(k- 1, r ) = p(gk, r1)


Therefore, by the principle of mathematical induction, p(k, ri) is true for all

positive integer values of k. If k = 0, then we already have a sequence of commands

that result in a leaking state and adds no more than one subject with initial role

ri.

Applying the above result for every role, we can construct a sequence of

commands that add only one subject for every role in the state. By lemma 5, we

can retain just one CreateRole command in a, therefore the number of roles after

the execution of all commands is at most one more than the number of roles in

S. Therefore the new sequence will have at most ITR + 1 number of AddSubject

commands.

Each of these ITR + 1| AddSubject commands activates a NewSubject, attribute.

If the initial role of the new subject is r', then the corresponding AddSubject

command activates the attribute NewSubject,,.

Lemma 7 For a given state S, object o, and right p, if there exists a sequence of

commands a that result in a leaking state, then there exists a sequence of commands

a' such that:









a' also results in a 7. .r :,,i state and

a' does not contain more than Nc(S) GrantRight commands, where Nc(S)
7(ITRI + 1)(ITI + 2)(ITI + IRI + 2).

Proof We are interested only in those GrantRight commands that grant

p, ADDSUBJECT, CREATEROLE, CREATEOT, GRANTRIGHT, AD-

DROLEBINDING, and CHANGEOT rights because:


1. By the definition of access right leak problem for the DCS-AC model,
granting some role a right p' that is not one of the sixteen DCS-AC system
rights or p (the right we are interested in) does not affect the access right leak
problem.

2. By lemma 2, we are ignoring all revocation and deletion commands and by
lemma 3, we can ignore all AddObject, AddAccess, and C',ia,. I)P commands.
Since we are not executing these commands, we need not execute GrantRight
commands that allow roles to execute these commands.

Applying lemmas 2, 3, 5, and 6, we can construct a sequence of commands ac from

a that results in a leaking state and contains:


no revocation or deletion commands

no AddObject, AddAccess, or C'l,,,, I)P commands

no more than one CreateRole and one CreateOT command

no more than ITR + 1 AddSubject commands.

Let each GrantRight(r, ri, t, ot, pi) command activate the HasRightr,ot,p,,t at-

tribute. We know that pi has to be one of the seven rights identified above.

Furthermore, if a GrantRight command, aj, activates a attribute that was active

in the initial state S or was activated by an earlier command ai, we can ignore this

command since there are no revocation or deletion commands. We construct a new

sequence of commands a' from a1 that does not contain any GrantRight command

that activates an already active attribute. Since we are throwing away only those









commands that are meaningless in the context of access right leak, a' will still

result in a leaking state.

Therefore, the number of GrantRight commands in a' is no more than the

number of HasRightr',,ot',p,t, attributes (active or inactive). We know that:


number of possible values for r' is < ITRI + 1

number of possible values for ot' is < ITI + 2 1

number of possible values for p' is 7.

number of possible values for t' is < ITI + 2 + IRI (since t' c T U R).

Let S -,, S'. This means that the number of HasRight attributes in S' is no more

than 7(|TRI + 1)(ITI + 2)(ITI + 2 + IRI).

Therefore, the number of GrantRight commands in a' is no more than 7(ITRI +

1)(|TI + 2)(ITI + IRI + 2). I
Lemma 8 For a given state S, object o, and right p, if there exists a sequence of

commands a that result in a leaking state, then there exists a sequence of commands

a' such that:


a' also results in a I .d ':r,,j state and

a' does not contain more than NR(S) AddRoleBinding commands, where
NR(S) = (ITRI + 1)(ISUBI + TRI + 1).

Proof Applying lemmas 2, 3, 5, 6, and 7, we get a new sequence of commands ao

from a which also results in a leaking state.

Now, each AddRoleBinding(r, s, ri) command activates the CanBinds, attribute.

We construct a new sequence of commands, a' by removing all AddRoleBinding



1 We can create one new role and one new object type. Since TR C T, in the re-
sulting state, IT'I can be up to 2 more than ITI.









commands that activate a attribute that was already active in S or was activated

by an earlier command in a'.

Therefore, the number of AddRoleBinding commands in a' is no more than the

number of CanBind attributes in that instance of DCS-AC. Moreover, a' does adds

no more than one new role and no more than TRI + 1 new subjects (by lemmas 5

and 6 respectively).

Therefore, the number of AddRoleBinding commands in a' is not more than

(ITRI + I)(ISUB + ITRI + 1).

Since we are removing only those AddRoleBinding commands from a, that do

not change the state of the system, a' will also result in a leaking state. I

Definition An enabler command is a command that activates a currently inactive

attribute. Therefore, for a state S, Enabled(S) is the set of inactive attributes for

which an enabler command exists.

Definition For a given state S, we i- that a sequence of commands is monotonic

if and only if the sequence contains only enabler and C'li,,.j OT commands

Corollary 9 For a given state S, right p, and object o, if there exists a sequence

of commands a that results in a leaking state, then there exists a sequence of

commands a' that is monotonic and results in a '. r .i.:,j state.

Lemma 10 For a given state S, the set of commands that activate the attributes in

Enabled(S) can be executed in rwi,; order and the resulting state will be the same.

Proof Let A(n) be the proposition that for a sequence of n commands a (=

ac, a2, ..., an) that activate n enabled attributes, for any permutation 7r of the

commands ac, a2, ..., a, (S ~ S,) = (S -~, S,) where ac is the permuted

sequence of the commands in a

BASE CASE: n = 2 (There are only two permutations, 1, 2 and 2, 1)

a = a1, a2. Let u' = a2, a1









Let a activate the attribute Xi and a2 activate X2. Let S -, S, and

S -->7 S111.

S, is the state obtained as the result of adding the attributes X, and X2 to S

and S,, is the result of adding the same two attributes to S.

S, S,,. Hence A(2) is true.

Induction Step:

Assume that A(k) is true for all k(2 < k < n).

Let 7r be a permutation of the commands in a and let a, = a',..., a', be

the permuted sequence of commands. Furthermore, let S ---> S,. A(n) is true if

S, = ,7.

Case 1: a' = a ,

Let a-I = O', ..._ and S ,, S1. Since = an,


S1- ST (5.1)


Let Tr' be a permutation of the commands a, ..., o'-_l. Let the new sequence

formed by the permuted commands be o'-


(n 1) (s ~, Sn-1) (5.2)


Now if r' is a permutation such that r'(Tr(cai)) = ai, then


-1 a1, a2, .,an-1 (5.3)


From 5.1, 5.2, and 5.3,

S- = S, (5.4)

But, S -= S,.

.. -- .









Case 2: a, / an

Let 7(an) a (1 < j
I/ / I /
A(n 1) = S -, S,, where O" = a ', ..., a._l, Or_l, l, ,..., O-_2, O, O


A(2) = S -S 2 S', where 0r2 O-1, .j_li, O4_l, Cj+l, -..., 1n- 21, n j

Since a' an,


A(2) = S -^2 S1, where a2 = a1,..., _, O a_, jI,., -n_2 21an, 2 an

Since an is the last command, we can follow the same steps as in Case 1 and prove

that S, = S,.

.. Vk (2
By the principle of induction, since the base case is true and (Vk(2 < k <

n)A(k)) = A(n), A(n) is true for all n > 2. |

Definition Let the number of attributes that are not active in a state S be N(S).

From the above lemmas, we know that


N(S) < 1 1 1 + (TR + 1) + NG(S) + ,NR(S)


Theorem 11 The access right leak problem for a given DCS-AC state can be

decided in jp .1/;,;, ..,,/.;, time.

Proof Let the initial state be So, and let o and p be the object and right we are

interested in. We will now provide a polynomial time algorithm to decide the access

right leak problem for (SO, o, p).

We know from corollary 9 that So can lead to a leaking state if and and only if

we find a monotonic sequence of commands.

Initialization Step

We create the set InactiveAttributes which contains all attributes that are

inactive in S. Initially, InactiveAttributes = {NewRole, NewOT}.









V r E TR add NewSubject, to InactiveAttributes.

V r TR, V ot T, V p' E R, Vt (TU R)
if HasRightr,ot,p,t V Active(S) then add it to InactiveAttributes.

V s E SUB, V r ft(s), add CanBinds,r to InactiveAttributes.

The above step can be completed in O(N(So)) time. Once we have identified the

inactive attributes, we can proceed to the next step.

Saturation Step

We will now saturate the instance, i.e., activate every attribute that can be

added till nothing more can be added. Starting from SO, we execute all the enabled

commands in the current state (Si) to reach a new state (S"+1) and repeat this step

till no more attributes can be activated.

By lemma 10, we can execute the commands that enable the attributes

in Enabled(Si) in any order. We execute them all taking care of the following

book-keeping steps:


If the NewRole attribute is activated, then:
1. For all subjects currently in the system, add a corresponding attribute
(CanBinds,re,, where s is the subject and rne is the new role created).
2. For all object types, rights, and targets, add HasRightr,,, ot,p,t to
InactiveAttrinutes.

If the NewOT attribute is activated, then add corresponding HasRight
attributes.

If a NewSubjectr, attribute is activated, then for all roles rl currently in the
system other than r', add CanB.:,,. to InactiveAttributes, where snew
is the new subject added.

Remove all attributes that are activated from InactiveAttributes once the
enabling command is executed.

Repeat the above step till we reach a state S" for which Enabled(S8) = 0.

At this point the system is saturated and we cannot activate .ni, new attribute.









Since there are at most N(So) attributes, this step takes O(N(S0)2) time. We now

proceed to the next step.

Type Checking Step

Let S = (A',R', T', T,, SUB', OBJ', f', f;). Now, we can tackle the

Clri,.j, OT command as follows: We first identify the set of leaking types, LT

and then check if o can be changed to any of these types.

LT = {otlot E T' A Ks,p,ot 4so,p,fo(o) / 0}


We can identify the elements of the set LT in O(IT| ISUBI ITRI IRI) time.

Once we have identified the elements of LT, we can check if the type of o can

be changed to any of these types by creating a T iP.w. lI-,,, ie graph, G = (V, E)

where G is a directed graph such that V T' T' and


E = {(ot, ot2) ot, ot2 E T'A3r TR such that (CHANGEOT, ot, dp) E A'[r, ot2}

That is, the nodes in G correspond to object types in S8 and there is an edge from

ot1 to ot2 if some role can change the object type of an object from otl to ot2.

Now, the problem of deciding if the object type of o can be changed to one of

the .,I..,. ',,,/, is reduced to a graph reachability problem which can be solved

by performing a depth first search starting from fo(o) (the object type of o in the

initial state) and checking if the current node is in LT. If one of the types in LT

can be reached from fo(o), then there is a sequence of commands that can lead to

a leaking state else there does not exist a sequence of commands that result in a

leaking state.

The graph can be constructed in O(T|12) time and the graph traversal also

takes the same amount of time. The type checking step takes O(ITI ISUBI ITR p

IRI) time.









Of the three steps mentioned above, the saturation step takes the most amount

of time and hence the ARL problem can be decided in O(N(S)2) time. |

5.5 Summary

In this chapter, we restricted the DCS-AC model and saw how to decide in

polynomial time whether a given state could result in a leaking state by executing

an arbitrary sequence of commands if voting is disallowed. We assumed mono-

tonicity and proved that there is a polynomial upper bound on the number of

meaningful commands (i.e., commands that when executed result in a change of

state). Using this, we constructed a directed state graph where each node of a

graph corresponds to a state and two nodes are connected if there is a command

which when executed on the starting state results in the ending state.

We then identified those states which result in a leak and if there is a path

from the node corresponding to the starting state to a node corresponding to one

of the leaking states, then the system can leak the right. The commands that will

result in a leaking state is the sequence of commands that correspond to the edges

along such a path. Hence the access right leak problem for this restricted version of

the DCS-AC is decidable in polynomial time. In the next chapter, we will see how

to solve this problem if voting is allowed.















CHAPTER 6
TRUST AND VOTING

6.1 Introduction

In this chapter we will analyze the safety of the DCS-AC model where subjects

are allowed to vote. Since we cannot deterministically predict how the subjects will

vote we will approach the problem from a different angle. We assign a numerical

value, trust-level, to each subject which represents the amount of resources a

malicious entity needs to expend in order to make the subject vote against the

best interests of the group. We will identify three simple approaches on how

subjects can be I F i, 'I" and analyze the access right leak problem based on these

approaches.

6.2 Trust and Trust-Worthiness

One of the key questions in any vote is "How much can we trust the voters to

make the right decision?". There are many aspects involved in trust, some of which

are identified below:


understanding of and belief in the mission of the group

sound decision-making process

rational behavior

susceptibility to blackmail or bribery

protection of identity

Different groups give different weight-ages to these and other aspects of trust.

Based on these, we assign a trust level to each subject s denoted by 0(s), which is

the amount of resources required to turn the subject s. Our main concern here is









the susceptibility of the subjects to make a wrong decision. By wrong, we mean a

decision that is not in the best interests of the group. The subject might decide to

do the wrong thing by intention (needless to -,i, our trust level in such a person

would be low). We assume that we know the trust level of all subjects in the group

and that this trust level is constant. For the sake of simplicity, we will assume that

each subject in the system has a unique trust level.


0(s) 0(s2) S1 S2

Note that we do not talk about how the trust levels are assigned as this may vary

from group to group depending on the group proirities. We should consider all the

factors mentioned above and other aspects that the group might feel important.

We could use a reputation-based trust management scheme like the model defined

by Shmatikov and Talcott [57] or a feedback-based scheme similar to the one used

in eBay [58]. In our safety analysis, we will assume that each subject has a unique

trust-level that is assigned outside of the DCS-AC and is correct.

6.2.1 Approaching Trust

There are many v-- v of looking at trust and susceptibility. The key idea in

here is to look at trust level as the amount of resources needed to make a particular

subject or group of subjects vote in a manner that is against the best interests of

the group. With this in mind, we will now look at three different approaches to

analyzing susceptibility through trust levels as defined here.

Ad-Approach

In the first case, if someone can make a subject si make a decision in a certain

way, then that person can make any other subject 82 make the same decision in

the same way with no additional effort if 0(si) > 0(a2). We will call this the

Advertisement approach (ad-approach) since we can look at this as p liing for an

advertisement which all the voters will see. If the ad is good enough to convince si,









then s2 will also be convinced. We will use OA(s) to denote the trust in a subject s

under the ad-approach. It must be noted that in this approach, one i1l" will cover

all decisions required.

Pay-As-You-Go Approach

It is possible to bribe or cheat the voters to turn one decision at a time. This

means that more resources are required to convince the same voter if he/she gets

to participate in another decision down the line. We will call this the Pa i-,- --ou-go

approach (P-approach) and use Op(s) to denote the trust in a subject s under this

approach.

Honest Politician Approach

In the words of former U.S. senator Simon Cameron, "an honest politician

is one who when bought, stays boul!l The key idea behind this approach is

the assumption that all the subjects are hI,.i, -1 pcl i. i, ii- In this case, 0(s) is

the amount of resources that someone has to expend to make si make a certain

decision (that person has to expend 0(s2) additional resources to "turn" s2). In

addition, once bought, the subject stays bought and no additional resources are

required if the subject gets to vote on another decision later. We will call this the

Honest Politician approach (H-approach). We will use OH(s) to denote the trust in

a subject s under the H-approach.

Hybrid Approach

The approaches mentioned above are very simplistic and in reality, a mixture

of these approaches is more likely to be used. These three approaches provide a

starting point for discussion and are more useful in introducing the ideas discussed

here. We hope to extend this to model real-life approaches in the near future. We

will concentrate only on the first three approaches here.









6.2.2 Decision Templates

In order to clarify how decision templates work, let us look at a simple decision

template. Here, all votes are weighted equally and parameters like quorum, voting

period, percentage of votes required for a ;/, vote are all part of the template.

Each such voting template is represented by the tuple (VR, k, q, td, Yd) where,


VR is a set of roles that can participate in the vote,

k is a number between 0 and 1 which represents the ratio between the
minimum number of ;, votes required to pass and the total number of
participating voters,

q is another number between 0 and 1 which represents the quorum (i.e., ratio
of minimum number of voters required to participate and the total number of
voters),

td is the time duration over which the vote is active (example: 2 d4,i-), and,

yd is the default decision which is returned if the deadline has passed and the
quorum has not yet been reached.

In addition, the set of decision pointers, DT, also contains an Al, ';;,- Yes template

(dyes) which ahv-i- returns i,. The reason for this is that many decisions do not

require a vote. An example of the template is ({F ,. ,li/i, Staff}, 0.5, 0.8, 2 d A-,, N).

In this template, all subjects who can bind to the roles Faculty and Staff can par-

ticipate in the vote which requires a simple ini j. iily with at least 1II'. voter

turnout. If after 2 d4 i- the quorum is not reached, a result of No is returned. If

after two di-,, at least 1II'. of the voters have cast their votes, then a Yes deci-

sion is returned if at least half the votes cast are ;, votes, if not a result No is

returned.









In our model, each subject gets to cast one vote even if he/she can bind to

more than one role in Vp. A discussion of the actual working of the voting mech-

anism is beyond the scope of this work and we will restrict ourselves to a brief de-

scription of the life-cycle of a vote. When a group decision is called for, we instan-

tiate a vote v based on the template. V (E,, Vote,, Voted,, T,, k,, q,, default)

where:


E, is the set of all eligible voters

Vote, is a mapping between each subject and his/her vote in the decision.
The possible values are D (defer), Y (Yes), N (No), and, A (abstain)

Voted, is the set of all eligible voters who have cast a valid vote (Y, N, or, A)

T, is the deadline for the vote which is obtained by adding td to the time of
vote initialization.

k, is the value of k in the template

q, is the value of q in the template

default is the value yd of the template

E, = {s SUBVR n f,(s) 0}

Vote, : E, {Y, N, A, D}

Voted, = {s E, E Vote,(s) E {Y, N, A} }

Initially, since nobody has voted yet,


Vs E E,, Vote (s)= D


When an eligible voter, s, casts a valid vote (Y, N, or, A), his/her vote is

updated in Vote, and s is added to Voted,. When the deadline T, is reached, all

new votes are rejected and a decision is reached.









We identify the following sets:


Y, = {s E,|Vote,(s) = Y}

N, = {s E,|Vote,(s)= N}

A, = {s e E,Vote(s) = A}

We first check for the quorum,
Voted, >
IEJ -
if this is false, we return the default decision. If every subject who voted has

abstained, (|Y, + N1, = 0), we return the default decision. Next, we check if

enough yes votes have been cast.

IY >k
>k
IY, + N, -

if this is true, we return yes and we return no otherwise.

6.3 ARL Problem And States

Since excecution of certain commands is dependent on the subjects who are

allowed to vote, we have to factor our trust in the subjects while deciding the

safety of the system. With this in mind, we redefine the access right leak problem

for a DCS-AC system with voting as follows:

Definition For a given state So, object o, right p, and, budget T, the access

right leak problem (ARL) is a decision problem, does there exist a sequence of

commands in So with trust level less than T that results in a leaking state.


ARL {< S, o, p, T > 13a such that So -- St and


St,p,f,(o) so,p,fo(o) / 0 and'(a) < T}

where (a) is our trust in the sequence of commands a by applying one of the

three approaches.









In other words, can a malicious party, with a given budget, corrupt enough voters

to enable an unauthorized subject access to an object.

Let N,(SO) denote the number of commands that can be executed on the

initial state SO and all its descendent states. We are only concerned with the

commands CreateRole, CreateOT, GrantRight, AddSubject, AddRoleBinding, and

C'li,,,. OT (this is due to Corollary 4). As proven in the lemmas 3, 5, 6, 7, and 8,

the total number of such commands is bounded.
N,(So) < 1 + 1 + (ITRI + 1) + NG(S) + NR(S) + (T TR + 1)

< 4 + N(S) + N(S) + ITI
Definition For a given DCS-AC system with initial state So, we define the set of

all possible reachable states, SO as follows:

So {SI(S So) V (ca such that S'- S A S' E S)}


The size of this set is dependent on the number of commands that can be executed

on the initial state and its descendants. Each state can be represented by a N,(So)-

bit number where each bit corresponds to a particular attribute. The bit is 1 if the

corresponding attribute is active in that state and 0 otherwise.


o0o1 < 2N1(s0)

6.4 Trust Analysis of DCS-AC

Let us now prove the tractability of the ARL problem for a DCS-AC system.

As mentioned earlier, we will use the trust-worthiness of subjects to decide on the

trust-worthiness of the system.

6.4.1 State Graph

We will now construct a directed graph Gso = (V, E) which corresponds to a

DCS-AC system with the initial state So (We will call this graph the State Graph

of SO). The set of vertexes is V = S and there is an edge from vertex Si to Si









labeled (a, r) if S" is the result when a subject bound to the role r executes the
command a in S'.

Since each state has a unique set of properties, there cannot be more states
than the total number of properties in any given path.

VI = 1S < 2N(so)

In any given state, we cannot execute more than N,(So) commands and each of

these commands can be executed by at most ITp roles.

El < IV1 ITRI (S N s) < TR I N0(SO) 2N(S)

If we use an .,1i ,i:ency list, we can construct the graph in O(|IE). Therefore, the
graph can be constructed in O(ITRI N(So) 2 (So)) time.

Let SL denote the set of all leaking states.

SL = {S( Se s1,ot,p )S0,fo(o),p 0}

As mentioned in the previous chapter, we can identify the elements of SL in
O(IV ITI TRI ISUBI IRI) time.

Before looking at the three approaches to trust from the DCS-AC point of

view, let us define a few useful sets. For a decision d = (VR, k, q, Yd, td), let W(d)
be the set of r(d) weakest (in terms of susceptibility) voters. These voters are the

most likely to vote against the best interests of the group.

W(d) = {s s c V(d) A s, S2, ..., T(d) C V(d) such that


i / j Sz / sj A Vie [1, r(d)] 0(sj) < 0(s)}









For a command a, let W,(a) denote the set of voters that are most likely to vote

against the best interests of the group.


Wc(a) = W(d)

where d is the decision that guards the command. Moreover, some subject has

to issue the command in order to execute it. Therefore, our trust in a command

has to include our trust in the role that can issue the command. Let 7(r) denote

our trust in a role r. Our trust in a role is the same as our trust in the least

trustworthy subject that can bind to that role.


7(r) = min{0(s)|s E SUB and r E f,(s)}

Needless to -iv, our trust in the decision pointer dyes is 0.

6.4.2 Ad-Approach

Let OA(d) denote our trust level in a decision. In ad-approach, OA(d), is the

maximum trust level of all the voters in W(d).


OA(d) = max {OA(s)| s c W(d)}

Let d be the decision template that guards a command a. If the right that guards

a is enabled, then we can trust a only as far as we can trust d. Let QA(a) denote

our trust level in a command a. Here, we are looking at the command by itself

with no prior "history". There may be more than one role that can issue the

command. Let rl be the least trust worthy of all the roles that can execute the

command.


QA(a) = max(OA(d), y(rl))









Now, for a given sequence of commands a(= a a2, ..., On), let 'A(a) denote the

trust level in a using the ad-approach.


TA( ) = A( i) such that Vj E [1, n], A(Qj) < A( i)

In order to determine the minimum cost required to ensure a leaking state, we

have to find a path from So to SL that has the least TA value. We achieve this by

doing a modified depth first traversal on the graph.


Function DFT(v)

//The array visited[] is global and initially set to false

//The value MinCostA(SO) is initially oo

//The stack is initially empty.


1. visited[v] = true

2. if v = SL then
(a) let a be the sequence of commands in the stack
(b) c = 'A(sigma)
(c) if (c < MinCostA) then MinCostA = c
(d) return

3. for each u such that (v, u) E E
(a) if visited[u] = false then
i. push a into stack where a is the label of the edge (v, u)
ii. DFT(u)
iii. pop a from stack

We invoke this function by calling DFT(SO).

< S, 0, p, T > ARL t T >_ MinCostA(SO)

The above depth-first traversal can be completed in O(IEI) time. Hence the ARL

problem using the Ad-approach can be solved in O(ITRI 2Nv(S)) time.









6.4.3 Pay-As-You-Go Approach

Let Op(d) denote our trust level in a decision. In this approach, Op(d), is the

maximum trust level of all the voters in W(d).


Op(d) Op(S)
sCW(d)

Let d be the decision template that guards a command a. If the right that guards

a is enabled, then we can trust a only as far as we can trust d. Let Qp(a) denote

our trust level in a command a. Here, we are looking at the command by itself

with no prior "history". If r, is the least trust worthy role that can issue the

command a,

Qp(a) Op(d) + 7(r)

Now, for a given sequence of commands a(= ac, a2, ..., a,), let p(cr) denote the

trust level in a using the this approach.


Ip(a7) -Y p(5)
ai E

In order to determine the minimum cost required to ensure a leaking state,

we have to find a path from SO to SL that has the least 'p value. We achieve this

by using the single-source shortest path algorithm starting from SO. For each edge

(Si, Sj), the edge weight is bp(a) where a is the label of the edge.

Let the minimum cost to reach SL be MinCostp(So).


< So, 0, p, T > ARL # T > MinCostp(S)

Here again, the single source shortest path takes O(IE|) time (since we are using

.,1i ,i:ency lists) and hence the ARL problem can be solved using the P-Approach in

O(ITRI 2N^(o)) time.









6.4.4 Honest Politicial Approach

In the Honest Political approach, a subject once "bou, hli stays bought. There

are two problems with applying an algorithm similar to the ones used for the other

approaches. Consider the two decisions d, and d, and two subject sl and sa such

that: (i) sl and s2 are both valid voters for dl and s2 is a valid voter for d2, and (ii)

si is among the potentially weak voters in d, while s2 is not.


sl, 2 E Voters(di) and s2 E Voters(d2)


si E W(di) and S2 V W(di)


1. If S2 E W(d2), i.e., 82 is among the potentially weak voters in d2, then instead
of spending resources on both si and 82, a malicious entity can "buy" only S2
and still get both the decisions thus saving on the resources required to buy
81.

2. If S2 V W(d2) but there exists a subject S3 G W(d2) such that OH(si) +
OH(S3) > OH(s2), then it would be cheaper to buy s2 instead of both si and
S3.

The above two scenarios can be extended to any number of subjects and any

number of decisions such that replacing a single subject can lead to a cascading

effect on other decisions if the subject being replaced is among the weak voters in

the other decisions.

As we can see, the main problem is with voters who can participate in more

than one decision in a sequence of decisions. Our solution to this problem is very

simple. If a subject si with a trust level of OH(81) participates in n(< 1a ) decisions

in a sequence of commands a, then let 0'(si) denote the cost per decision in the

sequence.

e(sl) 81









Let the set V(o) denote the set of all voters in all the decisions in a.


V(a) = U,,GVoters(di) where dtis the decision that guards ci


Let W,(a) denote the minimal set of voters required to get all the decisions in a.

Let us now look at an algorithm to find this set.


Function Ws(a)

//Returns the minimal set of voters

//Initially W, is an empty set


1. sort all subjects in V(a) according to their 06

2. For each c in a
(a) Let di denote the decision guarding c
(b) Let count be the number of voters in ai already bought. count
|Voters(di) n Ws\
//We now have to find T(db) count eligible voters
(c) while count < 7(di)
i. Find s E Voters(di) Ws with smallest O8
ii. Add s to Ws
iii. count = count + 1

3. Return W,

Now, let 'H(a) denote the trust level in a using this approach.


TH(a) > OH(S)
sew,(<7)

In order to determine the minimum cost required to ensure a leaking state, we

have to find a path from So to SL that has the least 4H value. We achieve this by

using the DFT algorithm given above (we calculate 4H and MinCostH instead of

TA and MinCostA.


< S0, Op, T > ARL # Tr > MinCostH(SO)









We know that the length of the longest possible sequence is N,(So). We also

know that the maximum number of voters that can participate in a decision is

ISUBI. Hence, we can find the 4H for any sequence of commands in O(ISUBI

N0(So)) time. Therefore, we can decide the ARL problem using the H-approach in

O(|SUBI N,(So) ITRI 2N(S)) time.

6.5 Summary

In this chapter we looked at the safety analysis of the DCS-AC model with

voting. We assumed that each subject has a numerical trust-level and introduced

three approaches to trust and susceptibility namely, Ad, Honest Politician and

Pay-As-You-Go. We then saw how to determine the trust in a vote, a command

and a sequence of commands based on each of these three approaches. With this

as building blocks, we analyzed the safety of the DCS-AC model with a modified

access rights leak problem.

The key idea in the Ad-approach is that if a malicious entity can convince a

subject, s, to vote in a manner that is not in the best interests of the group, then

that entity does not need any additional resources to convince another subject

whose trust level is less than that of s. In the Pay-As-You-Go approach, each

subject has a specific amount of resources required to make him/her vote in a

manner that is not in the best interests of the group and the malicious entity

has to expend additional resources for every other subjects and also for the same

subject if he/she is required to vote again in another decision.

The most complex of the three approaches is the Honest Politician approach,

in which, a subject is "bou,!3l for the entire set of decisions. This complicates

the safety analysis since a malicious entity is better off spending resources on a

more expensive subject who can participate in many decisions as opposed to a large

number of less trustworthy subject each of whom can participate in one decision.







83

In order to solve this problem, we looked at cost per decision while deciding the

least expensive set of voters.

In each of these three approaches, we construct a directed graph which we

call state graph and use graph traversal algorithms to solve the access right leak

problem. There is a combinatorial explosion of the number of states and we proved

the decidability of the ARL problem in each of these three approaches by providing

exponential time algorithms.















CHAPTER 7
NEXT STEPS

The model as presented is powerful, flexible and scalable. However, more

work needs to be done in order to make this model model real-life policies. Some

of these are enhancing the commands in the model, extending the model itself to

allow subject-to-object privilege definitions, incorporating a role hierarchy and

time-limited access rights. As mentioned earlier, a 1 i i,' feature of the DCS model

is the use of decision templates which can protect against single malicious user

attacks. Further work needs to be done in analyzing multi-user collusion attacks.

7.1 Enhancing DCS Commands

There are some additions that can be done to improve the model. The com-

mands as described here are all mono-operational (i.e., perform only one primitive

operation). In many cases, the subject creating a new object has some special

rights with respect to that object, i.e., the creator has the right to read/write the

object or grant rights to others. While someone has the GrantRight privilege for

objects of that type, this issue is more critical for creation of new roles and object

types. If someone creates a new role or object type, the usability of this new role or

object type is severely restricted if no one has the right to allow subjects/objects

to bind to that role/object type. Therefore an additional operation needs to be

performed that allows the creator's role some basic rights.

The safety analysis needs to be revisited since the roles and object types have

pedigree and we will have to factor this into the analysis. However, the resulting

system would be more usable.









7.2 Special Relations

We would like to be able to specify subject-to-object level access rights, for

example, even though all programmers have the right to read any code, only the

programmer who wrote a particular class has the right to modify it. We can imple-

ment this by creating a new object type or a new role for each class/programmer.

This is inefficient and a simpler way is to use Special Relationships. These are a

mapping from (subject,object) pairs to roles. (fs SUB x OBJ TR). We can

define a role Class Writer and specify fs(Pi *.,1'1ii r, class) = {ClassWriter}

for each class. Now, each time an access request is made, we should check for any

special relations between the subject and the object before checking for the role

and object type (the reason being, special relations are usually more "pc .- ilil!

than regular roles for that particular object). This clearly changes the definition of

all the commands and the safety analysis but provides a very useful way to specify

finer-grained access control.

7.3 Role Hierarchy

One of the 1 i i" differences between the roles as used in the DCS model

and RBAC is role ,, 'r,. /I,; We can implement role hierarchy by maintaining a

partial ordering of the roles in the form of a directed graph, GR = (V, E) where

V C TR and (ri, r2) E E if and only if r1 inherits all the rights from r2. When an

access request is made, we first check for special relations, failing which the rights

of the user's role is checked. If this fails, a breadth first search is performed on GR

with the mode corresponding to the user's role as the starting point. At each node

visited, the corresponding role is checked for the right to perform the requested

access. We use breadth first search instead of depth first search since roles higher

up on the hierarchy are more "pcv.-v, !Ili than those further down the graph. It

might be useful to constrain the role ordering to be ... i-, i for security purposes.

This can be ensured if the role hierarchy can be specified only when the role is









defined and cannot be changed. This is too rigid and can hurt the utility of the

model. Therefore, we can allow the hierarchy to be changed anytime but the graph

could be checked for cycles before committing the change. Since the role graph is

not likely to change frequently, this is an acceptable overhead on performance. The

addition of role hierarchy increases the overhead while searching for all the users in

a role1

7.4 Use-Cases and Scenarios

One of the most important steps in proving the usability of the model is to

identify various scenarios and show how this model can be used there. For example,

we can model the CISE department in terms of subjects, roles, objects, etc. and

show how we can use the DCS model (Only Ph.D. candidates can register for

doctoral research credits and a Ph.D. student can bind to the Ph.D. candidate role

if his/her supervisory committee chair nominates him/her and all the members

of the committee agree). One other scenario we can consider is the operations of

a large organization like IEEE. The idea is to show how the DCS model can be

used in these scenarios, starting from bootstrapping the system to getting it fully

functional.

7.5 Multi-User Collusion Attacks

The use of decision templates makes the DCS model very powerful and helps

minimize the role of the local domain system administrators. This also opens up an

interesting area of research, multi-user collusion attacks. For a given state of the

system, if a group of subjects want to tip a vote (with a given decision template,

dpl) in their favor, and they try to do so by allowing some of their buddies to

bind to some roles which participate in that vote, how many AddRoleBinding



1 We may have to find the list of all users who can bind to a role for voting and
notification purposes.









commands do they need? If the AddRoleBinding commands require another vote

(Z-1, dp2), they will have to be able to carry those votes in order to get a favorable

result for dpi. The question is, for any given dpi and dp2, the minimum number of

"conspirators" required to win the vote dpl is the minimum number required to win

dp2. A more complex case is when you need to control two votes, dp2 and dp3 to

win dpl.

7.6 Time-Limited Access

Another useful addition is Time Limited Access (TLA)2 Instead of

returning a simple yes/no answer, the decision pointer could return the time for

which the access is valid. If the access is denied, then it returns a zero else it

returns the time for which the access is valid. During that time, the user is granted

access to the object without starting the decision-making mechanism. This is very

useful for pn. ':;: -;" or substitutes. For example, if the user Alice who can bind to

the role Instructor is leaving town for a week, she can allow Bob (bound to role

TA) to temporarily bind to the role Instructor. We can also create a new role

sub Instructor with a subset of the rights of Instructor. For example, Bob can

not assign grades to the students. In order to implement TLA, we need a separate

data structure that stores the time period of validity. The TLA structure should

either periodically remove expired entries or check for validity each time an access

is requested. This again might increase the turn-around time for an access request

but on the other hand, it can be very useful since it can help avoid frequent calls to

time consuming decision pointers.


2 TLA could also stand for Three-Letter Acronym















CHAPTER 8
CONCLUSION

The access control model described here is designed for the Distributed

Conferencing System version 2 (DCS v.2). However, this model can be used in

any distributed system that requires highly available access control services and

user driven decision making capabilities. We have formally specified the model

and analyzed its various advantages with respect to existing models. We have also

provided algorithms to map a state in a DCS system to an equivalent HRU state

and vice versa and proved that the access right leakage problem is decidable in NP

time. The software project example illustrates the usefulness of this mode. As seen

in chapter four, this model satisfies many interesting properties of access control

systems and supports user-defined voting templates. The presence of decision

templates allows the members of the group to decide on their own group policies

and vote on important decisions. This democratic approach ensures .fiii,, 1.r: for

the groups and provides greater flexibility in terms of access control.

We have shown that the model is provably safe in terms of the access rights

leak problem. Since some of the access control decisions are made through voting,

the security of the system depends on our trust in the voters. This leads us to the

three approaches to trust that are mentioned here. The Ad-Approach is simplistic

and the analysis is very straight forward. The Pay-As-You-Go approach is slightly

more complicated and the Honest-Politician approach is the most difficult of the

three to analyze. In all three approaches, we reduced the problem to some form of

graph reachability and have provided algorithmic solutions to the same.

This type of analysis can help us prepare against multi-user collusion attacks

and is heavily dependent on accurately assigning trust-levels to all the subjects.







89

In reality, a hybrid of these three approaches is likely to be used and this work

provides a starting point for further work in this area. In conclusion, the model

presented here is scalable, useful, provably secure, and very flexible.















REFERENCES


[1] B. W. Lampson, "Protection," in Proceedings of 5th Princeton Symposium on
Information Sciences and S1;-/. i- Princeton, 1971, pp. 437-443.

[2] G. Scott Graham and Peter J. Denning, "Protection-principles and practice,"
in Proceedings of Spring Joint Computer Conference. AFIPS, 1972, pp.
417-429.

[3] Steven J. Greenwald, "A new security policy for distributed resource man-
agement and access control," in Proceedings of the 1996 Workshop on New
S.. -,, P',,,n.,- 1996, pp. 74-86, ACiM Press.

[4] Markus Lorch and Seth Proctor and Rebekah Lepro and Dennis Kafura and
Sumit Shah, "First experiences using XAC'\ 11 for access control in distributed
systems," in Proceedings of 2003 ACI[\ Workshop on XML '.. i;,i, 2003, pp.
25-37, AC\ I Press.

[5] Ian Foster and Carl Kesselman and Gene Tsudik and Steven Tuecke, "A
security architecture for computational grids," in Proceedings of the 5th AC I[
Conference on Computer and communications ,. .ii;~ 1998, pp. 83-92, ACMi\
Press.

[6] M. Webb and D.L. Wilson R.E.N. i.--i ,i-Wolfe and C.L.Ramirez and H.
Pelimuhandiram and M. Montes, "A brief overview of the dcs distributed
conferencing system," in Proceedings of Summer Usenix Conference, Nashville,
TN, 1991, USENIX, pp. 437-452.

[7] Andras Belokosztolszki and Ken Moody, \ I i-policies for distributed
role-based access control systems," in P -1.. 2002: IEEE 3rd International
Workshop on Policies for Distributed S- ,'ii- and Networks, 2002, pp. 106
115.

[8] Anek Vorapanya, Lr,,,.--Scale Distributed Services, Ph.D. dissertation,
University of Florida, 2000.

[9] James Gosling and Bill Joy and Guy L. Steele Jr. and Gilad Bracha, The
Java LI'..i',i,': Sp / ....:.,,/,n, Addison-Wesley Professional, Boston, MA, third
edition, 2005.

[10] Herbert Schildt, Java: The Complete Reference, J2SE 5 Edition, McGraw-Hill
Osborne Media, 2004.