The following paper was originally published in the
`
`Proceedings of the 7th USENIX Security Symposium
`
`San Antonio, Texas, January 26-29, 1998
`
`A Comparison of Methods for Implementing
`Adaptive Security Policies
`A
`
`Michael Carney and Brian Loe
`Secure Computing Corporation
`
`For more information about USENIX Association contact:
`
`1; Phone:
`2. FAX:
`
`510 528-8649
`510 548-5738
`
`office@usenix.org
`3. Email:
`4. WWW URL: http://www.usenix.org/
`
`EMC V. IV
`
`IPR20l7-00338
`
`EMC v. IV
`IPR2017-00338
`Ex. 1018
`1
`
`Ex. 1018
`
`1
`
`

`
`A Comparison of Methods for
`
`Implementing Adaptive Security Policies
`
`Brian Loe
`
`Sc 6 11. re C70 mp at my (.73'o‘I"])0r‘(1i[0‘Iz
`:3/)l'75 /long La/s;'r:'
`/?,0(1(/
`I?0._<:c«~mTIZr—i
`.-°il.[‘I"I?.'I?y(:',.S'0t'(I, 5:511
`
`
`
`c:~77zmTZ:
`
`tor. \.,.s-ecvz/xz"r.:c0mp'ut’27ng.com
`
`_\l i cl.1ael C 81:11.16)‘
`(f3'077z])ulmg Clorpow/.tf27o-22p
`S'c:('iz1.7"r.~.
`226'”/5 t/..()ng .i[,,(1,/re Road
`t/?0.sci*2‘zT//6.
`jlI‘I'xm2.c;.;~'0‘/a 55.l],_‘)’
`
`r;—n2mT/: c(1r1zry
`
`((,“l1,'l"(C0‘I7?])Utt‘IZg.C077?
`
`Abstract
`
`1
`
`Introduction
`
`Tlie securit_y policies for computing resotlrces must,
`match the security policies of the organizatioiis that
`use then‘); therel'ore. coinputer security policies 1‘l‘i11St
`he (ulaplirci to meet the changing security en\-‘iron-
`ment of their nser—ba.se.. This pa.pe1' presents [our
`1'nethotls for ilnpleinenting atlapttive security poli-
`cies for a.1'cliitect11res wliicli separate the definition
`of the poli<:.y in a Security Server from the enl'orce-
`nient which is clone by the kernel. The four inetliotls
`tllS('11SSG(.l include
`
`o reloading a. new sect11'ity database for the Se.ct1-
`rity Server,
`
`0 expantling the state and security <,lat,a|.>ase ol'
`the Se<'1.1rity Server to inclu<le more than one
`l'1’1()(.l6‘ of operation,
`
`and
`0 iinplelnenting another Securit_\; Servel‘
`lianding oil‘ control for security co1'nput.a.tions,
`and
`
`concurrent Seclirity
`inultiple,
`o lI1]])l€I1](:¥1]ltl11g
`
`Servers <-3‘<I.(ill controlling a. sul.>set ol'p1'oc
`
`Eacli of these methods Comes with a
`
`ol'
`
`tra<le—
`
`olls: policy Ilexiliility, l’unctional llexibilit.y. .sec1,1rity.
`1'elia|_>ility, and perlbrinance. Tliis paper evalna.t.es
`eacli ol’ the iinplernentations with respect
`to each
`of these criteria. Although the inethods (lescri|.>e(.l
`in this paper were iinplernentetl for the Dist1'ib1.1te<,l
`T1'1,1St@tl Operating Systenl (DTOS) prototype, this
`paper desc1'il.>es geileral researcli, and the conclu—
`sions drawn from this work need not he liinitecl to
`
`that clevelopnient platl'orm.1
`
`1 This work was supported by Reine Laboratory c<:>ntracts
`F‘3OGO2—95—C—O0-'17 and F3O602—9(f7'—C~O2]l,O. Portions of the
`DTOS Overview found in Section 4 appealecl in [Sl'\'TC96].
`
`Real o1‘ga.1iiza.t.ions do not have static securit_\; poli-
`cies.
`Ratlieiy the_\f
`liave <lyna.1nic policies that
`change. eitlier as 'a i'natt.er of course, or to alloxv
`The
`them to react
`to exce1:>t,ional circtlinstances.
`coin pnting resources of {‘J](,)rE.:(‘.)r OI‘g'21.1]lZ'<tl>lO11S ninst re-
`llect
`the o1‘gaiiiza.ti<)11‘s need for secnrit.y while all
`lortling users the Ilexil.>ilit_y 1‘eqt,1irecl to operate in a
`(hanging en\'ironn’1ent..
`
`Any inipleinentation 01' atlaptive se<'1n‘ity 1.)1‘(:‘,S€IltS
`its own set of a.<,l\/'a.nt.ages amt (llSE1tl\7EtI’]l€tg(?S. While
`this paper coinpares four l‘t1(?t—ll()(lS for i1‘nple.menting
`a.dapt.ive security policies. it is i1nport,a.nt to keep the
`needs of the oi‘ga.1iiza.t.i()i1s in mind in or<ler to axle-
`quat..e.ly <ton1pa.1'e iinpleinentations ol' a.cla.pti\='e secu-
`.I‘ity. Section 2 outlines some of the possible scenar-
`ios requiring a.<la.pli\re security policies a11dpro\«'i<les
`a ntnnl_>er ol‘ examples of a.tla.pti\re policies that are
`useful
`to the later clisclission. Section 3 tlescribes
`
`the range of possible inipleinentations for 2-1(l'c1])ti\='@
`security given the basic securit_\j atrcl1it.ec.ture ol' the
`DTOS prototype and pro\rides a hriel'sl\'etcl1 ol' the
`iinplernenta.tions (llS(‘.11.'.\.'S€(l
`in Section.
`Section -4
`provitles more |.>a.cl{groun<l on DTOS, which was
`used to implement eacli of the four niethotls de-
`SC1'll.)€Ll
`in this paper. Section 5.1 <lescril.)es the cri-
`teria. against which iinpleinentations ol‘ a.dapti\¢e se-
`curity may be Ineasurecl. The final subsections of
`Section :3 describes in greater detail
`the four spe-
`cilic iinplernentations resea1‘clie<.l at Secure (_iTo1np11t—
`ing (_7oi‘poratio11 and e\-'a.lua.tes eacli with respect to
`the criteria. l'roni Section 5.1.
`
`2
`
`

`
`2 Motivating Examples for Adaptive
`Security
`
`T he lirst example of adapti\re sec.u1'ity consists of
`org'aniza.t.ions that need to change their policies at
`regular in terya.ls. For exam ple, a. ban k may ha.\'e one
`security policy e.nl'orced during business hours and
`
`another policy enforced a.l't.er hours. Tlie busine s
`hours policy would grant broad sets of permissions
`to various
`of employees in order complete nor-
`mal banking transactions: lioweyer, a more restric-
`tive policy would be in elI'ect. a.l'ter hours to prevent
`systein users from altering |.>anl;ing data in unin-
`tended ways.
`
`Some organizations may need to release sensittiye
`documents at specilic times. For commercial orga-
`nizations it may be a. press release of new product in-
`l'orn‘1ation that. must not be ay'a.ila.l.>le l'roi'n the web-
`
`server until a specilied t.ime. Military organizations
`may liave. similar needs to make inl'orma.t.ion a.\=a.il—
`a.ble to allies on a tin'ied—relea.se basis. Co11\-*ei'sely.
`todayis comn'ierc.ia.l pa ‘tner or military ally may be
`
`
`an tomorrow‘s adver aiy. in which case they should
`not be a.llo\\'ed to recei\-‘e various forms 01' inl'orma—
`tion.
`
`their se-
`Other organizations may need to adapt
`curity policies based on the tasks performed by
`the users.
`For example.
`in the banking e.\;ai‘r1ple
`cited a.bo\*e. some tasks may be critical to perform
`despite the more restrict.i\='e policy enforced alter
`5:00 Pl\’1. High—priority or urgent.
`t.a.sl<s may need
`to be granted special permissions to complete on-
`going operations despite. the general change of pol-
`icy. Other t.a.sli—ba.sed policies may make use of an
`assured pipeline, like that proposed by Boebert and
`
`I{a.in [.l3K8.3]. A sured pipelines address situations
`
`
`in which a.
`.. ,.ries of tasks must be perl’orn‘1ed in a
`part.icula.r order and the control {low must be re-
`stricted. An a.dapt,i\re policy might change the
`of permissions assoc.ia.ted with a. single process as
`it completes a. series 01' operations. As the process
`
`c.omplet.es one operation. the perinission
`chang
`to allow the process to complete the next operation
`but
`to prevent it from revisiting any obyjects that
`it needed for earlier operations. A related secu-
`rity policy would be the C~lii1‘1ese Wa.ll introduced
`by Brewer a.nd Nasli [BN89], which
`intended to
`prevent conflicts of interest. in commercial settings.
`Briefly, under a. Chinese Wa.ll security policy a sub-
`ject may initially be allowed permission to an entire
`class of objec.ts. but as soon as the subject accesses
`
`one element of the. cl;
`permissions to
`any
`other object of that cJa...s are denied.
`
`Role-|,>ase<l security policies form another class of
`a.da.ptive secturity policies. A role
`dist.i1‘1guislie<,l
`l,iroi'n a task in that an indi\:‘idua.l has an on—going
`need to complete a. set of tasks.
`(be [S( )6].
`[F(,‘.K9»3]., and [Hol'9'7].)
`In comi'nercia.l S<:‘l.ltillgS,
`roles may be used to enl.'or<:e separation of duties
`[C\»\’87]. For exainple one role may be granted au-
`thority to issue purcliase orders while another has
`
`authority to pay for those purchas 3.
`I‘-lowe\/'e.r, for
`small coinpanies it. may be necessa1'y for one indi-
`vidual
`to perlorin actions in more than one role.
`though 11ot. necessarily at one time to provide the
`proper controls and o\.'ersight.
`In military opera»
`tions it may be necessa.ry for an indi\-'idua.l to per-
`form actions in more than one role simultaneously.
`For example. in the Navy the role of the Watch Ol-
`licer on a. ship 1'na.y be perI'ormed by the Chief E11-
`gineer. This person may need to lullill both roles
`siiinulta.neousl\'. Sirnilarly. the (.‘.ornma.nd Duty Ol-
`licer may need to perform actions reserxred for the
`(.f‘oi'i‘1niia.nding Ollicer in times of emergency. Priv-
`ilege to iiivoke tliese dual roles should be reserved
`for extreme situa.t.ion,s.
`
`Multi—le\«‘el security (.\lLS) rules as applied in the
`
`militr
`and intelligence communities form a. linal
`class of examples of security policies that nnist. be
`ada.pti\-‘e. Adaptive policies may allow either a. re-
`laxation or selecti\«'e hardening of conli<lent.iality re»
`strictions. Under MLS rules all objec.t.s a.re la.bele<.l
`according to the sensitivity of the data. they con-
`tain (e.g.. Top Secret. Secret, (f.‘.onl1de.ntia.l. and Un-
`classified). By the simple security rule, users and
`s1.1b_jects
`allowed access to obser\»'e o|.>_jects only
`if their clearalice level
`is equal
`to or exceeds the
`sensitivity of the object (see [BL73]). During an
`
`eme1'gency it may be nec.c.ssary t.o consolidate lev-
`els into two leve.ls: one for Secret and Top Secret.
`liles. and another for the rem,a.inder. Tlius. under
`the relaxed‘r11les, someone formerly cleared for Se-
`cret. could access liles l'ormerly labeled as 'l7()].> Se-
`cret. For example. military ollicers may only have
`clearance to the Secret level. but once t.lie.ir troops
`are under lire. they may need to access Top Secret
`inl,'orma.tion such as the locat.ion or capabilities of
`enemy forces. Coiiversely, conlident.iality rules and
`other security measures could be "‘lia.rde1'1ed' based
`on DEFCON alert. stat.us or following detection of
`a possible intrusion. Tliere are a. number of ways to
`"harden”
`system. For example. one could increase
`internal controls, perform lull audits rather than
`lective audits, or require additional authentic.a.tion
`measures.
`
`3
`
`

`
`3
`
`Implementation Space
`
`Tire DTOS p1'ot.oty]:>e provides a security arcl1itec—
`ture that sepa.ra.tes the eniorcenient. oi’ the security
`policy liroin its deiinition. Since this type ol‘securitt\_-'
`architecture
`not unique to the DTOS prototype.
`resnit.s from this paper apply to a \=ariet.y oi,‘s.\/rst.ern.s
`with similar a.rc.hitectures.
`
`l.Ciements avaiia.l_>ie to adapt
`clude the ioiiowirrgz
`
`the security policy in-
`
`o the nuinber or coinpiexity oi‘ the da.ta.l.>a.ses that
`a. Securit_\«' Server uses to initia.iize its internal
`state '
`
`o the nurnl.>er oi‘ Security Servers a\-'aiial,>le to the
`rnicrohernei for security co1nput.a.tions
`
`o the control over which Secr.1r'it,._\; Server rnaites
`sec.11rit.y c.o1nputations on behalf of the rnicro—
`l\'e1‘r1ei
`
`Although the number oi‘ possible irnpiernentations
`is large. this paper descril ?s the following represen-
`tati\'e irnpiernentations:
`
`o One Security Server and nnritipie da.ta.ba.ses
`-— adaptilrg the 1i>oiicy by forcing the Semi-
`rity Ser\=er to re—initia.iize from a. new securit.y
`database.
`
`0 One Security Server and one data.|.>ase »»»»»»»~ adapt.-
`ing the policy by expanding the internal state oi‘
`the Security Server a.n d increasing the complex-
`ity of the security database to describe more
`than one set oi’securit._\,~' policy rules and by pro-
`viding the Security Server with a rnechanisrn for
`changing its mode of operation.
`
`0 Multiple Sect11‘it.y Servers with a. single actixre
`server providing one point of control over so-
`curit,.v\-= cornputations ~~ adapting the policy by
`providing a. inechanisrn to hand oil.' the respon—
`sibiiit.y of computing
`decisions from one
`server to another. Tirus, one and only one Se~
`curit).-' Server,‘ delines the policy at any given
`time.
`
`0 i\=Iuitipie, concurrent Security Servers with re»
`sponsibiiity for security cornputations parti-
`t.ioned l_>y tasks —— adapting the policy by as-
`signing a pointer to a speciiic Security S(-?I‘\='(-:‘1‘.
`to each new process.
`In t.his method, wlrenever
`a. process 1na.i;es a. request
`to the 1'1']iCI,'Oi{GI‘1]<:‘l
`for service, the inicrokernei submits requests for
`
`cornputations to the Security .‘j<:*r‘\.~'<;>1* that
`acc
`is associa.ted with that process and which de-
`iines the security policy with respect.
`to that
`process.
`
`4 DTOS Overview
`
`Tiris section provides an ove1‘\.'iew oi' DTOS. the op-
`erating svstern used to irnpiernent. the tour rnethods
`ciiscussed in this paper.
`
`DTOS was designed around a securit,\,—' a1'ciritecture
`t.hat separates eniorcernent
`irorrr
`the delinition oi‘
`the 1)<)ii<'.y that is enl'orc.ed. Tiiis a.rchitec.t.ure allows
`the system secur.ity policy to be ciranged without
`altering the e.nl'orce1nent. rneci1a.nis1'ns. The policy is
`deiined as a iimction that maps a pair oi" security
`
`contexts to a set oi’ permissions.
`sach pair oi’ se-
`curity contexts represerrts the se<t1,11'it.y c.onte.\:t oi‘ a
`sul.)je<'.t and the security context oi" an object
`that
`the sul.>_ject at.ten'ipts to access.
`(.7ur'1'e11t.iy. DTOS
`iinpiernents sec1xr'it.y contexts consisting of level, do-
`
`main. user. and group. but the set oi‘ attributc: .. that
`i'orn'r
`a. securit._\; context
`is configurable.
`.l§ni'orce.—
`inent consists oi’ de.t.<—_*1'rnining whether the permis-
`sions speciiied by the policy are a.d,equate for an ac-
`cess being attempted. Tire generality oi" the iI)':l"()S
`security arciritecture has been studied
`part oi’
`the. DTl."()S program [.‘3'ec.9T]. The conclusion of this
`stu<,ly
`that a. large Variety o.l'securit._\j policies, use-
`ful
`i,'or both military and cornrnerciai syst.<~1’1‘1s. can
`b e inrpiernen ted.
`
`a. microi<er—
`I)'[‘()S design consists 01'
`The ba.sic
`nei and a collection oi‘ se1'\>e1‘s.
`Tire rnicroi<er—
`
`t.ypes and
`nei irnpiernents sexrerai primiti\-‘e ob_ject
`provides lnterProcess (fo1‘ii1rn11nication (lP(,.‘.). while
`the serxrers pr-ovide, various operating systern ser-
`\>ic.es such as files, autiientication. and a. user in-
`t.er'ia.ce [7'i\'i93. Min9»3]. Oi" particular interest.
`is a
`Sec-’z17"ity .§'e7"m~r' that deiines the policy enforced by
`the D]i(T1’Oii€1‘1‘1(:‘i a.nd also possibly by other ser\«'ers.
`Wiren a request. made for a service provided by
`the rnicrokernei. the rnicroiternei sends identifiers for
`the sec.urit.y contexts of the sul,>‘jec,.t. and object to
`the Security Server. Tirese identiiiers are rel'erred
`to as 56.1-u.rrT/.y tic/c7‘1.lr:/1ic7'.s or SID A contfext. con-
`tains a.tt.ribute.s about. a. sul.>_iec.t or object that are
`neces ary tor inaitilrg security decisions. For exam-
`ple. the context may <:onta.in the domain oi‘ a. subject
`or the type oi‘ an object.. or the level of a. subject. or
`object. The inl'or1na.tion tira.t rnaiaes up the context
`is dependent on the policy. The actual contexts are
`
`4
`
`

`
`local to the Security Server and are not a\»aila.|,>le to
`the microkernel. The Sec.u1'it.y Ser\«'er then computes
`permissions for the context pair, as defined by the
`policy that it represents. and replies to the micro-
`kernel. The microkernel is ignora.nt ol' the context
`of each entity since it only en['orces the permissions
`that the l3 computes on its behall'. Fi1ia.lly, the rui-
`crokernel <le.te.1'i‘nines if the permissions required for
`the request were present. in the reply. Other servers
`can communicate with the Security Server in a sim-
`ilar lasliion.
`
`i1nplement.ing an
`For example., a Security Server
`.\:'l.':LS policy might rnaintain subject and ob‘jec.t con-
`texts consisting ol'a. level. For the inicrokernel to en-
`force the simple security‘ and ”‘—prop.ert.y ol' the Bell
`and La.l’a<lula model [BLT3], the Security Se.r\»‘er will
`grant a write permission only it‘ the level for the ob-
`‘ject security identilier <lominat.es that of the level lor
`the su|_>‘]ect security identilier. and it will grant read
`perrnis ion only if the level for the subject,
`identi-
`lier dominates that for the ol.>ject. identifier. Both
`pe.rmissions may be granted if the le\«'els are equal.
`A lile server would check for write. permission be-
`fore allowing a request
`to alter a. file. An alterna-
`
`tive 9ecurit.y Server rnight provide U. X—like access
`controls by niaintaining a user and a. group for each
`subject context. and a.n owner, group, and access
`control bits for each object context.
`This type of
`Seciirity Sert-‘er: will grant pe1'missi()1is based on the
`accerr" control bits depending on whether the user in
`
`t.he subject context. 1na.tclies that ol‘ the owner and
`whether the groups match.
`
`A prototype. DT()S.' rnicrokernel and S<:‘<'11i'ity Server
`has been built by Secure (fomputin g. The n‘1icroker—
`nel
`based on i\“Ia.cli. de.\>eloped at Ca1'r'iegie Mellon
`
`I’ iixersity [Loe93. Ras9l]. A version of the Lites
`
`Y‘
`en'i,ulato1'. modilied by the go\='erurue1it, pro-
`
`\iides secured U
`‘
`IX l'unctionality.
`
`
`The object types in'1plementecl by the rni<:rokernel
`include ((1.3.
`3
`t/1.7"(:(1(l. a.nd port. Tasks and threads
`
`represent
`the actixre sul.>_iec.ts. or process s,
`in the
`tem.
`F'a.<:.li
`task has a security context that
`used for security decisions in\«'olving that task. The
`state of each task includes virtual n'iemo1'y consist-
`ing ol'a. set ofclisjoint memory regions, each of which
`is backed by a server that is used to swap pages of
`the region in and out of physical 1'nemory. Each
`task contains a collection of tlireads. each of which
`is a sequential execution. that share the tasks vir-
`tual memory and other resources. A server is im-
`plemented
`one or more tasks.
`
`unidirectional c.o1‘mnunic.ation chan-
`The ports
`nels that the tasks use to pass inessa.ges. Tasks use
`
`to name ports, and these are kept in an
`('(1]2(1(r1Tl/1?/.z'€..s'
`IPC name space on a. per task basis. Each capa-
`bility specifies the right to either receive from or
`seud to a particular port. These capabilities rna.y
`
`be transferred to another task by sending a in .
`, age
`
`l3‘or each port there is exactly one receive capabilit\-'
`
`‘T'l1eret'ore, at most. one task can receive mes.
`.g
`from the~port.
`IPC
`2r.s;iic'li1‘oii<)i1s in that. mes-
`sa.ges are queued in the port and the sending task
`does not wait until its message has been recei\=ed.
`An exception is when the microkernel is the re.c.ei\s'-
`ing task,
`in which case the sender waits until
`the
`
`tgfi‘.
`1nicroke1'nel finishes processing the l]’1(:"
`
`a }\'Ia.cli microker—
`ge
`Sen din g or 1'e<'.ei\:i11g a me‘
`nel operation to which DTOS has added security
`controls that enlorc.e the security policy. Thus. pos-
`session of the appropriate capability for a port is
`necessary but not sullicient in order to send or re-
`ceive a. message lrorn that port. The. security con-
`texts oi" the task and the port must also permit the
`
`or vration. The policy also constrains what capabil-
`
`
`ities may be p .
`sent or rece.i\re,d by
`:ed in a messag
`a. task.
`
`Tlie Securit.,\-' Server receives requests l'ron'i the ini-
`crolcernel through the 7ni(-r’o/r(:rm/ .s-(:(.-in'-il;z/ port and
`lrom other se1'\-'ers through a gcrzcml .s‘ec-'z1.7“'zTt;y port.
`Requests c.onta.in Your e.lements:
`
`0 an operation identilier ~—— allowing the Security
`Server to specit'y liistory-based policies tliat de-
`pend on the sequence of operations made on an
`o|,>‘ject,
`
`o a subject security identilie1' (SS1) —— represent-
`ing the securit_\,' context of the sub_jec.t.
`
`0 an o|,>ject security iclentilier (OSIT) — represent~
`ing the security cont<—>.\'t ol"the ob_ject.. and
`
`0 a send capability [or a reply port.
`
`Tlie Security Server replies by sending the permis-
`sions l'or that pair to the reply port (Figure l). Not
`shown in this ligure is the fact that the Security
`Serxrer bot.h delines and enforces a policy for the
`requests that it recei\-‘es. It might allow security de-
`termination requests from some subjects, but not
`from others. Similarly, it might allow security de-
`terrninatioii requests from a particular subject only
`v LL I-—
`for certain (831,081) 1
`'
`'
`
`Sec.t11'ity enforcement. as described above would be
`
`
`very expe11si\-'e due to the la.1 ge number of inessag
`tliat must be exclia.11ged between the rnicrokernel
`and the Security Server. The solution in DT’(‘).‘5
`
`5
`
`

`
`5 Comparison of Implementations
`
`This section of the paper descril,>es each ol' the meth-
`ods l'or clianging the security,’ policy in greater detail
`along with the capabilities and lii‘nitat.ions presented
`by eacli.
`l-lowex-'er. we hegin |,>y descrihiiig the crite-
`ria against whicli the Your implementation methods
`are eva.lua.te<,l
`in Section -3.1. The methods them-
`
`selves are desc1'i|,>ed in Sections
`
`t,.lirougli 5.5
`
` l;
`
`. Network Serverl
`
`File Server
`
`6
`
`Fig1ii‘e 1: Security Server .lnte1'action
`
`5.1 Criteria for Evaluation
`
`stem
`An a.dapt.i\re security policy for a coinputer
`must have the llexihility to meet
`the se.curity re-
`quireine.nt.s ol' the organiza.tion that lields the
`s-
`tein. There are two types of llexihility to consider:
`
`0 .l*’()licy' llexil.>ilit.y --~ the raiige of policies that a
`system can support before and altei,‘ a. transi-
`tio11 |)et.we,e,n policies.
`
`0 Functional llexiliility aw the aliility ol‘ users to
`coniplete tasks despite the transition of policies.
`
`
`the ex-
`l"Iow<»‘ er. greater llexiliility rna.y come at
`pense ol' se<7urit.y. and the g1 ater con'11.>l<~.»\.,\'.it.y re-
`quired l'or some types of transitions niay also liaxre
`an irnpact. on the relial.>ilit.y ol‘ the syst.ei‘1'i.
`
`The criteria. identilied here are not in<lependent ol’
`one another; in l'a.ct. examining \»'arious in‘iple.1nenta.—
`tions ol' ada.pt.i\=e security le.ads to a. series ol‘ trade-
`olls with respect to these criteria. The conclusions
`that ‘are. drawn lrom the ai‘ia.lysis ol‘ the tour imple-
`nientations rellect
`the nature of the depen<lenc.e ol'
`the criteria upon one a.not.lier.
`
`Policy Flexibility In the context of a.dapt.ive se-
`curity. the concept ol' policy llexibility could be mea.—
`sured by the amount of cliange one is allowed to
`11]d.l{€ and whetlier the system can enforce an a.rl,>i~
`trary new policy. Tlitts, policy flexibility depends
`on the nurnber (or lack) ol‘ c.o11stra.i1‘1ts tha.t must be
`satisfied by the successoi‘ policy for a. given prede-
`cessor policy.
`
`Fulictional Flexibility 19‘unctiona.l lleXi|,>ility ad-
`dresses whetlier the policy transition
`gra.c.el'ul or
`harsh with respect to the a.pplica.tions that are run-
`ning at the time of the transition. A harsh t1'a.nsition
`might be like turning oll.‘ the power and re—|,>ooting
`the systein, wliereas a. graceliil transition may ap-
`pear seeinless to the user and most applications on
`
`to ca.che (SSl.O.9l) pairs with their perrnissions in
`the nncroliernel [i\='lii'i95l. When the microliernel re-
`ceives a request.
`it lirst looks in the caelie lor the
`a.ppropria.te (.5 1.081) pair.
`ll’ tha.t pair is in the
`caclie. the n‘1icrol<ernel u
`the cached entr
`. Oth-
`
`it sends the pair to the Sectii*it.y , ._ yer to
`erwise.
`determine the perinissioiis, usually also cacliing the
`reply.
`(Part. of the perinission set. returnet.l
`is per-
`mission to cache the reply
`cacliing would not be
`permitted for permissions graiited lor a single oper-
`ation by a. dynainitn policy.) Since sending to and re-
`c.ei\='ing l'1'on‘i a. port are l1']l(fI'()l\’€.l'l]<?l operations con-
`trolled by the policy, the cache must be preloaded
`with permission for the Security Server to send and
`i‘ec<—.*i\-‘e lroin the (lP,Slgl18lt(”(.l ports.
`
`
`
`In order to irnpleinent a. (,lill'erc:nt policy (either by
`clianging the current J3 or by referring to a new ll)
`there must he a in<~.>cliaiiisinlo1' llushing permissions
`lrom the rnicrol<ernel‘s caclie. Otlie1'\\‘ise. if the new
`
`stein for a
`policy renioves permissions lroin the
`specilic (SS1, OSl) pair, and the nii<'rol;ernel has
`already cached the permissions for that pair,
`t.lie.n
`the 1nic.1'ol:ernel would continue to enforce the old
`
`the J3 delining the new
`policy rather than consult
`policy.
`’l‘lierel‘o1'e, the l3 must isst.1e a coinmand to
`the 1DlC1‘()l{GI‘l1(:‘l. and a.i‘iy other sei'vei's registered as
`caching permissions determined l.>y the IS, telling it
`to llnsh its cache.
`]?lowe\rer, it would be in’ipra.ct.ic.a.l
`lor the l'11lC1‘Oli€1‘I]@l
`to [lush every perrnission in its
`caclie; if it did, then the entire s xstem would come
`to a. halt. Therel'ore. some ])G]']1'1lSSlO]'lS are hard
`coded. Tliese include some of the basic permission
`required for IPC l.)et.wee.n the subjects coniprising
`the operating system itsell‘.
`
`The sepa.ra.tion l.><->t\‘\>e(=.1'i policy and enlorcernent in
`the DTOS prototype inalie it a.t.tra.<tt.ive for study-
`ing adaptive security. The work descirilied in this
`report discusses reli11e1nents to the design that are
`important for these policies.
`
`

`
`7
`
`a.11<l OSIS to pe1'1’11issio11s. The Sec111‘it.y S1;-*1*\«‘e1' then
`tells the 11‘1i<'1'<1l<e1‘11e.l Lo ll11sl1 its caclie ol' pe.1‘111is—
`sions. and l'1'om t.l121.t. point. o11wa.1'cl,
`the policy «le-
`li11e<.l by the Sec111'ity Se1'\><->1‘
`the policy e11l'o1‘ced
`by the 111ic.1'oke1'11el. Tlie sa111e co.11’1111a11<l can be 1.1se<l
`to 1‘eplace one table with a11ot.l1e1'. Once the Secti-
`1'ity Se1'\re1* has loa.cle.<,l
`the new policy.
`it.
`tells the
`1’1'1ic1‘ol<e1'11el to [lush its cztche. and the 11e\1~' policy
`e11l'o1'ce<l by the 111ic1rol{e1'11el.
`
`the policy can be. encap-
`Tlie co11'1111a.11cl to 1'eloa.<l
`sL1la.Le<,l
`in a. 1,1se1‘—i11\«'ol<ecl p1'og1'a.m 01'
`iii some au-
`t.o1’1‘1a.t.ecl process which cl121.11ges
`the policy at.
`the
`t.1'igge1-i1'1g of some e\re11t..
`'Tl111s,
`the policy can be
`l i he
`cl1a.11ge<l at
`1-e.g11la.1'
`i11t.e1‘\*a.ls using a. proc
`the UENIX 11t.ilit.y c7"011.. 01' by 21.
`l.>e1.cl;g1‘o1111<,l process
`which 1'1‘1o11it.o1's the sysl.e1’11 for i11t1‘usio11 e\re11t.s.
`
`Policy Flexibility This 1‘11etho<l relies lieayily o11
`the t.e1.|.>les
`tliati can be loaclecl
`into the Security
`.5e1'\»'e1'
`l'1'o11‘1 the sec111'ity <.lat.a.l.)a.se. Since the tables
`are i11<,lexe<.l by the SSI 211111 OSI. the 11'1a.1‘1age111e1‘1t.oi"
`the syst.e111
`easiest. if the Sec111‘ity Se1*\re1* loads 21
`11e\1~' policy wliicli is si1’11ila1‘ to the old one; t.l111s lim-
`iting the g1‘a.1’111la1*it.y of the allowal,>le policy c.l1e11‘1ges.
`A 1'a<lical cliange ol’ policy 1*eq11i1'e.s t.l1e1.t each e11tit.y
`in the syst.e1'1'1 l1'c1.\7e. 21'sec111'it.y c.o11t.ext. wliicli c2111 be
`1'ecog11iz.e<.l by the act.i\.‘e Seciirity Se1'\~'e1‘ both bel'o1‘e
`a.11<l al'te1' the policy cl1a.11ge.
`
`For i1‘1it.ia.l policies l.>ase<.l o11 Type I311lo1'ce1’1‘1e11t.3 (
`[B.l{85]) o1‘ MLS access rules. it wo11l<l be <lillic1,1lt. to
`11‘1al\'e 1'21.<lical cl1a.11ges in the policy.
`l?j\=e1~y e11t.it.y
`t.l1a.L lias a type or <lo1‘1‘1ai11 associated with it. 1’n11st.
`
`also l121.\v'e the at.t.1'ib11t.es 11ec
`‘a.1'y for e11l'o1'ci11g the
`<lill'e1‘e.11t. policy.
`‘T'l111s.
`to clizmge l'1'o1’11 a Type E11-
`
`lo1'ce11'1e1'1t. policy to a.
`l._
`_\I—lil<e sec111‘it.y policy.
`it.
`
`woiild be 11ecessa.1'y for ol)‘ject.s z111<l proce
`-is to liaye
`at.l.1'ib11 11ec.essa.1'y for both sec111rit.y 11'1ecl1e111is1‘1’1s.
`For ob_iect.s it. is iiecessary to 111a.i11t.ai11 coiitexts for
`the se11sit.iVity level of the obiect. as well as the users
`
`a.11<l g1-o1.1ps which 111a.y liaye acc
`s to the ol.>‘ject..
`For s1,1b_ject.s,
`it. is nec ssa.1'y to 11'1a.i11t.ai11 the clea.1'-
`z111ce level of the s11l.)‘ject.
`Well as the user of the
`s1,1bject..
`it. is also iiecessary to 1'11a.i11t.a.i11 a. <lat.ab21.se
`listing the. group 111e1nbe1‘sl1ip.
`
`'?'A t.l111ml:>nail sketch ofTy1)e E11fo1'ce1ne11t‘. cles "1‘ibesit as :1
`
`type of 111a11<lat.or_v acc
`., co1it.1'ol policy in which each object.
`lms a s<-2cu1‘it.y at:t.1‘il;»ut.e known as :1 type and each sllbjr-:Ct has
`
`(L11 at.t11‘ib11t.e known
`ii (Z0771/a1”
`§11l3ject.$ are g1‘a11t.e<,l acc
`to rez-icl, wri
`_ or execute object,
`bz-ised on the c1on'1ai11~t.ype
`
`pair. Roles can be co11st.1*u<:(.e<.l for Ilsers by forming
`of
`(l()1h8.l11$ in wliich users 111:1)’ lmve s11bject.s ope1‘z1t.ing.
`
`
`
` t.e111. A l1211'sl1 policy t.1'a11sit.io11 1.1121.y p1'e\Ie11t,,
`11se1*s
`l'1'o1‘11 pe1‘l'o1‘mi11g 11ecesse11'y. possil>ly 1,11*ge11t.,
`1'21t.l1e1‘
`t.l1a.n 21.llowi11g the111 to co1’11plet.e their
`t._z1.sl<s in an e\»'olvi11g secu1‘it.y e11\«'i1'o1111'1e.11t.. Tlie ide.a.l
`
`to allow 11e<.
`. 1.1'y t.a.sl\'s to co11’1ple.t.e while. t.e1'1‘11i—
`11e1t.i11g taslis that are 1101.. only <lisa.llo\-11etl 1,11’1<le1‘ the
`new policy, but. which 1‘ep1‘ese11t. a sec111'ity 1‘isl\'
`iii
`the new e11vi1*o1111’1e1'1t..
`
`o1‘
`111ecl1a11is1'11
`a.
`existeiice of
`Security Tlie
`i11t1'o<l11ce sec.11—
`11'1etho<l ol' cl1a.11,gi11g policies 1‘1‘1a.y
`1'it.y \r11l11<.>.1‘e1.l_)ilities.
`in ass ssing a 111et.l1o<,l of policy
`z1cle1pl.at.io11. one 1111.1st. co11si<le1‘ the sec111'i1.y 1'isl<s tvliat.
`are i11l1e1~e11t.
`in that. 1’11ethod.
`F111't.l1e1'1'1‘1o1'e, eacli
`
`type of policy t1'a11sit.io11 11'111s(, be as.
`seal
`['01 the
`1‘ela.t.i\'e <lillic1.1lt.y ol‘ p1'o\-'i<li11g lo1'111aJ a.ss111‘a.11ce ey-
`iclence i11 S11]I)]')OI‘l of the policy t.1'a11sit.io1'1.
`
`Reliability Each 11’1et,l1o1l of policy t.1ta11sitio11 i11-
`t1‘onl11ces a. 111ea.s111~e ol’ co111plexity into the syste111.
`(,,‘l1a.11gi11g policy 1'11a.y expose the sysl.e.111 to ce1‘t.e1i11
`'
`1 v1'l1icl1 dec1'e' "e the st.al_>ilit.y ol' the e1‘1t.i1'e
`
`
`t.e111.
`
`cl1a.11ge policies
`to
`al,>ilit.y
`Perfoi-inalice ’.lI“l1e
`011
`the iieecls of the 11se1'
`lot
`q11i(‘.l{l_\;'
`lias i11‘ip21.ct.
`se.c1.11'it.y,
`J'1111c.t.io11ality.
`21.11cl 1‘eliabilit.y. A coiiiplex
`l1aI1<l—oll,' 11’1ay allow g1'ea1.t.e1' llexibilit.y bet.\11e.e11 poli-
`cies e11l‘o1~ce<l
`l>el'o1'e and 21.l‘t.e1' the t1'a11sit.io11.
`l.>1.1t. it
`
`may also p1'ese11t. g1'ea.te1‘ sec1.11'it.y risks. A less com-
`plex l1a11<.l—oll‘ 111a.y p1'o\>icle pe1‘l'o1'111v21.11ce gains at. the
`expense of l'1111ct.io11a.l
`o1‘
`llexil,>ili1.yt:’
`
`5.2 Loading A New Policy Database
`
`l'o1' imple111e,11t.i1’1g 21. liew secu-
`One possible 1'11et.l1o<l
`1‘it.y policy is to c.l1a.11g‘e. the \va._\/
`that.
`the Sec1,11'ity
`,‘Se1‘\»'e1* clelines it. by <:1'e21t.i11g 21. seco11<l <l'c1t.21,|.>a.se z1.11<.l
`1'e—i11it.ializ.i11g the Sec111'it.y Se1'\>e1'. A metliod for (lo-
`iiig this e,xist.e<l 011 the DTOS p1'ot.ot.\rpe. Du1'i11g the
`boot. p1*ocess,
`the 11'1ic1‘ol<e1'11el ope.1ra.t.es 011 21 hard-
`coclecl caclie 01' pe1'111issio1'1s u1’1t.il the Sec111*it.y Se1'\»'e1'
`is 1'ea.<ly l'o1' ope1'e1tio11. Once.
`the .‘3‘ec111'it.y .Se1'\='e1‘
`has i11it.ia.liZe<.l, the 1‘11ic1ol{e1'11el places the com111d.11d
`SSI_l0adfiec1.1rity_policy on the secu1'ity port. of
`the Sec111-it-.V Serveiz Tliis c.o111111a.1'1<.l ca.1.1ses the Se-
`c.111'it.y Se1'\re1: to 1'ea.d the sec.111'it.y <l21.t.a.l,>21.s<‘e to con-
`st.1~1.1ct. a. t.a.|_>le i11 its i11te1'11a.l meinory t.l1a.t. 1‘1'1a.ps SSls
`2l"e1'fo1‘1na11ce seemed to a 11at.111'al C1'it.e1'io11 to inclucle.
`U11t"c>1~t.1111:Lt.ely. the pe1'for1na11c,e cluta is i11<:o1nplet.e. Despite
`this pmbleni. the a.11t.l1o1's have choseii to i11cl11de])z-u‘t.ial (liiliil
`alt.l1oL1gl1 it. is so1ne.v\'l1at. in<:o1'1<:l11sive.
`
`

`
`Functional Flexibility Since the t.ransit.ion be-
`t,w<->en policies during t.l1e loading of a new policy
`nearly atomic.
`this implement.at.ion is quite liarsli
`on running applications. Any a.pplica.tion which
`ceases t.o have permission t.o perlbrm any task un-
`
`der
`the new rules
`ntially orplianed. Tliis
`abrupt. cliange ol‘ belia.\«'ior is pro|.>a.l.>ly accept.a.ble.
`and may even be desirable in some cont.e.x’t.s (e.g..
`inilitary eniergencies). Howe\»'er.
`in some c.ont.e..\t.s
`
`this abruptnes would cause CO]'l.'$l(l(:?1"<‘1.l.)l(:‘. dilliculty.
`In t.he banliing example presented in S<?<:t.ioii 1., there
`may be occasions when a part.icular user must. co1n~
`plete a specilic t.ra.nsa.ction |.>el'ore the. end of’ t.he day.
`.H,owe\.‘ei', if the policy t.ra.nsit..ion time occurs at 5:00
`Pl\~l sharp a.nd t.he user needs an atlditional lilteen
`t.o twenty nii11ut.es to complete t.he task.
`tlien the
`policy may hinder bank employees lrom completin g
`\rit.a'.l tasks. This would doul.>tl<-.=ssly be una.ccepta.ble
`under this scenario.
`
`Security The imrnedia.c._\,~' ol‘ the transition of this
`method pro\.~'ides for the grea.t.est. securit.y; the users
`always know exa.c.t.ly which policy
`the current. pol—
`
`icy. As will be shown below. thi.
`not always the
`case wit.li other methods.
`
`Although the security dat.a.ba.se is a. critical object
`that. should be prot.ect.ed from una.ut.hori7.e<.l mod-
`ilication.
`t.he sec.urity da.t.a|_>a.se could be changed
`while the system
`in opera.t.iona.l mode. Assum-
`ing that. the system lielded with a.dequa.t.e pliysi—
`cal and procedural securit._\; c.onst.raint.s.
`t.he securit.y
`dat.al_>ase more s11s<:ept.ible to replacement. or mod-
`ilication during operation than the dat.aba.se (and
`systein) would be t.o a.t.t.acl<s conductetl between suc-
`cessive boots ol’ t.he system.
`ll’ st1bve1't.e<l sol‘t.wa.re
`could replace t.lie intended da.t.a.base with a dillei‘e11t.
`lile, the system would enforce the wrong policy.
`
`Tlie issue of who can aut.li