Large system installations are increasingly configured using high-level, mostly-declarative languages. Often, different users contribute data that is compiled centrally and distributed to individual systems. Although the systems themselves have been developed with reliability and availability in mind, the configuration compilation process can lead to unforeseen vulnerabilities because of the lack of access control on the different components combined to build the final configuration. Even if simple change-based access controls are applied to validate changes to the final version, changes can be lost or incorrectly attributed. Based on the growing literature on provenance for database queries and other models of computation, we identify a potential application area for provenance to securing configuration languages. 

Anderson, Paul

Cheney, James

Large system installations are increasingly configured using high-level, mostly-declarative languages. Often, different users contribute data that is compiled centrally and distributed to individual systems. Although the systems themselves have been developed with reliability and availability in mind, the configuration compilation process can lead to unforeseen vulnerabilities because of the lack of access control on the different components combined to build the final configuration. Even if simple change-based access controls are applied to validate changes to the final version, changes can be lost or incorrectly attributed. Based on the growing literature on provenance for database queries and other models of computation, we identify a potential application area for provenance to securing configuration languages

Edinburgh Research Explorer

     Edinburgh Research Explorer                                      Toward Provenance-Based Security for Configuration LanguagesCitation for published version:Anderson, P & Cheney, J 2012, Toward Provenance-Based Security for Configuration Languages. in The4th Usenix Workshop on the Theory and Practice of Provenance.Link:Link to publication record in Edinburgh Research ExplorerDocument Version:Publisher's PDF, also known as Version of recordPublished In:The 4th Usenix Workshop on the Theory and Practice of ProvenanceGeneral rightsCopyright for the publications made accessible via the Edinburgh Research Explorer is retained by the author(s)and / or other copyright owners and it is a condition of accessing these publications that users recognise andabide by the legal requirements associated with these rights.Take down policyThe University of Edinburgh has made every reasonable effort to ensure that Edinburgh Research Explorercontent complies with UK legislation. If you believe that the public display of this file breaches copyright pleasecontact openaccess@ed.ac.uk providing details, and we will remove access to the work immediately andinvestigate your claim.Download date: 28. Apr. 2017Toward Provenance-Based Security for Configuration LanguagesPaul Anderson and James CheneyUniversity of Edinburghdcspaul@ed.ac.uk, jcheney@inf.ed.ac.ukAbstractLarge system installations are increasingly configuredusing high-level, mostly-declarative languages. Often,different users contribute data that is compiled centrallyand distributed to individual systems. Although the sys-tems themselves have been developed with reliability andavailability in mind, the configuration compilation pro-cess can lead to unforeseen vulnerabilities because ofthe lack of access control on the different componentscombined to build the final configuration. Even if sim-ple change-based access controls are applied to validatechanges to the final version, changes can be lost or in-correctly attributed. Based on the growing literature onprovenance for database queries and other models ofcomputation, we identify a potential application area forprovenance to securing configuration languages.1 IntroductionIn a computing infrastructure, system configuration [3]is the task of assigning configuration parameters to allof the individual components so that the overall systembehaves according to requirements. The infrastructuremay be a datacentre, or a distributed cloud application,or any other composition of connected systems. Typi-cally, there will be many thousands of parameters whichcontrol the behaviour of the individual systems, and therelationships between them.To manage this complexity, special-purpose system-configuration languages have evolved, such as LCFG[4, 1] and Puppet [9, 2]. These allow the configurationrequirements to be specified in a relatively high levelway, and the languages are compiled down to generatethe individual configuration parameters. The system con-figuration task can then be thought of as “Programmingthe Infrastructure” [5], with the configuration parame-ters analogous to the machine code, and the configurationspecifications analogous to a high-level program.However, configuration languages are significantlydifferent from programming languages. Most modernconfiguration languages adopt a (more or less) declar-ative approach to specifying the desired configuration.The configuration tool is then responsible for generatingand sequencing the actions necessary to transform thecurrent configuration into the desired one. This decou-ples the description of the configuration from the processof deploying it, and the configuration language becomespurely a data description language.Because of the complexity, manual configuration oflarge infrastructures has become largely impractical, andconfiguration tools are now ubiquitous. However, thesetools and languages are in their infancy. Unlike theprogramming languages used in mission-critical applica-tions, there has been very little attempt to formalise thesemantics, or verify their implementation. This can leadto a substantial discrepancy between the rigour of an ap-plication, and the infrastructure on which it depends:“In his case study about Linux system engi-neering in air traffic control, Stefan Schiman-ski showed how scalable Puppet really is andhow it can guarantee reliable mass deploymentof the Linux-based, mission critical applica-tions needed in air traffic control centers.”1.One specific problem is the lack of ability to track theprovenance of particular configuration parameters. Largeconfigurations are collaborative endeavours, involvingmany authors, and often spread across different organi-sations, so separation of concerns is an important consid-eration, and it is typical to see a hierarchy of classes withvalue-inheritance (rather than type inheritance). This al-lows a chain of users to successively specialise descrip-tions provided by others (see section 2 for an example).In practice, it can be extremely difficult to determine thesections of code, and the corresponding people who havecontributed to the final value.1FOSDEM 2011 (http://lwn.net/Articles/428207/)1Understanding the provenance of the resulting config-uration parameters is important simply for managing theconfiguration — in the case of configuration errors, forexample, it is clearly essential to understand who hascontributed to a parameter, and in what way. However,the ability to identify the provenance of each parameteris also prerequisite for creating a more secure tool whichsupports a fine-grained authorisation of the configurationparameters. This type of authorisation is not supportedby any of the existing high-level, declarative tools, andit is difficult to prevent anyone with access to the config-uration source from modifying any aspect of the entiresystem.This paper is intended to introduce system configura-tion languages as a potentially new and important ap-plication area for provenance, particularly with regardto securing and auditing changes to configurations. Weprovide some examples of configuration problems whichcould be avoided (or at least mitigated) by developingprovenance-aware configuration languages and accesscontrol mechanisms. We highlight the lack of formal se-mantics for existing languages as a significant problem,and identify what we believe are promising next steps totake in solving these problems.2 An ExampleThis section shows a (greatly simplified) example of theway in which large configurations are structured, and thekind of problems which can occur in practice:1. Alice works for the company that supplies the con-figuration tool, and she develops generic templates,including one for a typical server machine. This hasdozens of fields, including one for the “timeserver”which is the address of the machine against whichto synchronise the operating system time. By de-fault, this is set to some reliable, well-known publicservice:class genericServer {timeServer = ts@reliable.com...}2. Bob is the senior sysadmin for widgets.com and hedevelops templates for use in the company. Theseinherit values from the distributed templates. Boboverrides some of the default parameters, but leavesmany at their default value — in particular, thetimeserver default seems reasonable and he doesn’tchange it.class widgetServer isa genericServer {...}3. Carol is the sysadmin for the sales department andshe inherits Bob’s templates, again overriding somevalues to localise them, but leaving most (includingthe timeServer) with their defaults:class salesServer isa widgetServer {...}4. Dave is the technician who configures the individ-ual machines. He just assigns one of Carol’s tem-plates to the machine and overrides a few host-specific parameters such as the machine name andaddress:class serverA isa salesServer {ip = 1.2.3.4...}Carol carefully checks the new machine (serverA)and verifies that everything is ok. In partic-ular, the timeServer has the reasonable valuets@reliable.com.Of course, in practice, there will be several thou-sand parameters, possibly hundreds or thousands ofmachines, and probably hundreds of classes. So thisstructure is designed to support a separation of con-cerns. For example, Dave can install the machinejust by supplying the IP address and it gets installedwith the policy defined by Carol. Carol only wor-ries about departmental policy, assuming that Bobhas taken care of company-level policy, etc.5. At some point, Carol wants to experiment with alocal timeserver. So, she might change her templateto:class salesServer isa widgetServer {timeServer = ts@sales.widget.com...}Nobody else needs to be concerned with this, andall the sales machines will now switch to using thenew timeserver.6. At some later point, Alice ships a new version of thegeneric templates. These define a new timeserverfor some reason — perhaps a mistake, perhaps amalicious intervention, or perhaps something whichis appropriate for many companies — although notfor widget.com:class genericServer {timeServer = ts@unreliable.com...}2The generic templates are too large to inspect indetail, but Bob is careful. Before he makes themlive, he performs regression testing by doing a testcompilation and inspecting the values which havechanged in all the machines, such as serverA.Some things may have changed on Carol’s ma-chines (and presumably they are acceptable), but thetimeserver will not have changed (because of the lo-cal override) and won’t appear to be a problem. Sothe new templates are made live.7. At some later time, Carol decides to withdraw herlocal timeserver, so she removes the override:class salesServer isa widgetServer {...}At this point, all of the machines in the sales de-partment inherit the unreliable server. The usersblame Dave who says he hasn’t changed anything.Carol says she just put the configuration back tothe default, so it can’t be her fault. Bob says hehasn’t changed anything for months, so it can’t behis fault! In a large system, it may not be obvioushow the machines have ended up with the unreliablevalue, and where it came from. This takes a gooddeal of human communication to sort out, defeatingthe separation of concerns.Most configuration languages would allow us to addvalidation to the resource values, so someone (probablyBob) could specify that the timeserver must have someparticular property (perhaps being a member of specificdomains). But the validation can only take place on thefinal instantiated values. So this prevents the bad config-urations being deployed, but it still means that the prob-lem is not detected until later, and the root cause is noclearer. Not only would Carol be prevented from de-ploying her change, but no further configuration changescould be deployed until this had been resolved (or theunwanted override re-instated).3 Access controlPerhaps it was not appropriate for Carol to change thetimeserver at all (company policy, perhaps). In this case,a fine-grained access control would have allowed Bob toprevent Carol from setting this value. As noted, suchcontrol requires a clear notion of provenance though.Vanbrabant et al. [10] proposed a solution to this whichinvolves analysing the differences between successiveconfigurations, in the context of Puppet [2], a popular,open-source configuration language. However, in theabsence of provenance information, this mechanism at-tributes all of the changed values to the user initiating thechange. In our example, Carol would have been blamedfor the failure, although she did not author the offendingresource, nor was she the appropriate person to fix theproblem.We suspect that computing provenance for real con-figuration languages such as Puppet will present signif-icant challenges; we have already noted that the seman-tics (and even the syntax) is not clear, and certainly notformal. It is also evolving with reasonably frequent ad-hoc additions and changes. However, it is also likely thatthere are language constructs which make it particularlydifficult to derive a useful provenance. For example,the inheritance operation illustrated above has a clearlycorresponding provenance derivation (left projection).There may be other composition operators where the cor-responding provenance derivation is simply a union —for example appending two lists, or adding two numbers— in such cases the final provenance for a value mightsimply say “everyone was responsible for this in someway”.It is possible for a configuration to produce acceptableparameters, but still be suspect in some way. For exam-ple, there is something fragile about the configuration re-sulting from stage 6. It now depends on Carol’s overridevalue for its correctness — which was not previously thecase.As another example, suppose (after untangling theabove mess), Bob sets the timeserver field of widget-Server to ts@widget.com and also installs fine-grainedaccess control rules that say that only Bob can set thetimeserver in any widgetServer. Carol, independently,sets the timeserver in salesServer to ts@widget.com,inadvertently duplicating Bob’s setting. This is fine, be-cause Carol’s change confirms Bob’s setting, so thereis no visible change in the end result for the accesscontrol checker to complain about. However, later thetimeserver needs to be upgraded and Bob tries to setthe widgetServer.timeServer to ts2@widget.com.Carol’s change now overrides Bob’s, and the final con-figuration does not change, so the change is allowed buthas no effect, and Bob does not notice this. The nextday, when the main server is switched off, everythinggrinds to a halt, and Carol tries to manually set the timeserver to a local machine to get the sales machines run-ning again. However, since this change does affect thefinal time server value, the change is disallowed since itis not made by Bob. Recovering from this inconsistentstate requires Bob to either deactivate access control orrevert to a consistent configuration and and coordinatewith Carol.It is worth pointing out that part of the problem here isthe distributed way that configurations are managed: thefiles Alice, Bob, Carol and Dave are editing are all likelyto be versioned, but may be hosted on different systems3under no central control. Centralizing this informationin a database that maintains the final version of the con-figuration, and controlling all users’ access to this infor-mation, might help make it easier to detect bad changesearlier, but this mode of operation would be far less ap-pealing and convenient than the conventional file-basedapproach: users would have to formulate bulk changes interms of queries and updates, and all users (including Al-ice, not an employee of widget.com) would have to haveaccounts on the database.Thus, we seek an alternative solution that preserves thegood properties of the conventional distributed approachto configuration while also addressing the problems dis-cussed above. These problems could be identified earlierif we could specify finer-grained policies controlling thechanges made by intermediate users, not just the end re-sult.In the rest of the paper, we suggest ways that prove-nance techniques developed in the context of databasescould be adapted to this problem.4 Next steps and open questionsWhere-provenance [7, 6]. As a simple first step, weenvision adapting the usual notion of where-provenanceso that each value is tagged with the identity of the userwho last set or overrode it. This, for example, wouldmake it easier to see that the unreliable time server in step7 of the example was due to Alice’s change (unnoticed byBob and Carol), so that Dave should not be blamed.Dependency tracking [8]. Next, we could considertagging the final value with a set of all of the users thathad some influence over the value (e.g. by specifyingor overriding the value). In the example, Carol wouldsee that the time server value was influenced by bothher and Alice; this information may make it easier forCarol (or others) to track down the right person to askabout the problem. This type of dependency informationis already maintained by the LCFG [1] compiler, but thefile-based input allows this to be attributed only at thelevel of the source file, rather than the user, so it cannoteasily be used for access control. It is also susceptibleto the previously noted problem where the set of userswith some potential involvement in a resource can be-come very large.Override history. A refinement of this approach is toreplace each value in the system with a sequence oftagged values, with one distinguished, “actual” value andpossibly other potential values. The tags indicate whichuser caused a possible value, and the order of the list in-dicates the order in which the values were set and over-ridden. The first element is the current value. In the ex-ample, Carol would initially see the list[ts@sales.widget.com{Carol},ts@reliable.com{Alice}],indicating that she overrode Alice’s reliable server.When Alice changes the server to an unreliableone, Carol would see [ts@sales.widget.com{Carol},ts@unreliable.com{Alice}], so that Carol may beable to alert Bob of the problem before reverting the salestime server to the default.In all of the above examples, it is possible that theprovenance information could grow much larger than theraw data, leading to information overload. Thus, insteadof expecting users to examine all of this information, weenvision defining policies that constrain the provenanceof the values in the final result, or (extending the ap-proach of Vanbrabant et al.) constrain the changes usersare allowed to make in terms of both the data and itsprovenance.Either approach, we believe, requires developing a for-mal semantics for a realistic configuration language, sothat we can extend it with provenance and specify desir-able security policies or properties. This presents a num-ber of challenges, because (like many languages usedin practice) Puppet and similar configuration languageshave grown organically, rather than being designed witha formal specification in mind in advance. Defining theirsemantics formally is perhaps the main challenge for fu-ture work.References[1] LCFG website, 2012. http://www.lcfg.org.[2] Puppet website, 2012. http://www.puppetlabs.com.[3] ANDERSON, P. System Configuration, vol. 14 of Short Topics inSystem Administration. SAGE, 2006.[4] ANDERSON, P. LCFG: a Practical Tool for System Configura-tion, vol. 17 of Short Topics in System Administration. UsenixAssociation, 2008.[5] ANDERSON, P. Programming the datacentre - challenges in sys-tem configuration. In Microsoft Technical Report MSR-TR-2008-61 - The Rise and Rise of the Declarative Datacentre (May 2008).[6] BUNEMAN, P., CHAPMAN, A. P., AND CHENEY, J. Provenancemanagement in curated databases. In SIGMOD (2006).[7] BUNEMAN, P., KHANNA, S., AND TAN, W. Why and where: Acharacterization of data provenance. In ICDT (2001), no. 1973 inLNCS.[8] CHENEY, J., AHMED, A., AND ACAR, U. A. Provenance asdependency analysis. Mathematical Structures in Computer Sci-ence 21, 6 (2011), 1301–1337.[9] TURNBULL, J. Pulling Strings with Puppet: Configuration Man-agement Made Easy. Apress, September 2008.[10] VANBRABANT, B., PEERAER, J., AND JOOSEN, W. Fine-grained access control for the puppet configuration language.In Large Installations Systems Administration (LISA) conferenceedition (December 2011).4

Toward Provenance-Based Security for Configuration Languages

http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.363.6808

Toward Provenance-Based Security for Configuration Languages

Abstract

Similar works

Full text

Available Versions

Edinburgh Research Explorer