Mark J Sier

Guillaume Dupont-Nivet

Cor Langereis

Alan L Deino

John D Kingston

Andrew S Cohen

Magnetostratigraphy of the Hominin Sites and Paleolakes Drilling Project (HSPDP) Baringo-Tugen Hills-Barsemoi core (Kenya)

Keywords: ICDP, Lower Matuyama, Gauss, Kaena, Mammoth, Drillcore orientation

The principal objective of the Hominin Sites and Paleolakes Drilling project (HSPDP) is to study the relationship between climate and environmental change and the implications on human evolution in eastern Africa. For this purpose, HSPDP has recovered a 228 meter core in the Chemeron Formation of the Baringo Basin (Kenya).

The Chemeron Formation spans approximately 3.7 Myr, from around 1.6 to 5.3 Ma, and has yielded many vertebrate fossils, including fossil hominins. The magnetostratigraphy of the Baringo core contributes to the chronological framework. A total of 567 individual paleomagnetic samples were collected from 543 levels at regular intervals throughout the core and 264 were processed using thermal and alternative field stepwise demagnetizations. In most samples, distinct Low-Temperature (LT; 20-150°C) and High-Temperature (HT; 150-550°C) Characteristic Remanent Magnetization (ChRM) could be determined. Typical demagnetization behaviors and some rock magnetic experiments suggest titanomagnetite acts as the main carrier of the HT ChRM with pervasive secondary overprints in normal polarity expressed by the LT component. Normal and reversed polarities were identified based on the secondary overprints LT J o u r n a l P r e -p r o o f Journal Pre-proof ChRM directions, either parallel or antiparallel to the HT ChRM directions respectively.

Our study identified four paleomagnetic reversals interpreted as the Matuyama-Gauss, Gauss-Kaena, Kaena-Gauss and the Gauss-Mammoth transitions. These boundaries provide chronostratigraphic tie-points that can be combined with those derived from 40 Ar/ 39 Ar dating of tuffs (Deino et al., this issue) and together indicate that the HSPDP Baringo core has an age range of ~3.3 Ma to ~2.6 Ma. The consistent paleomagnetic and radioisotopic age constraints are incorporated into a Bayesian age model of the core (Deino et al., this issue).

Introduction

Many evolutionary changes in the human lineage are argued to have been strongly influenced by changes in the climatic and environmental conditions (e.g. [START_REF] Behrensmeyer | Climate Change and Human Evolution[END_REF][START_REF] Joordens | An astronomically-tuned climate framework for hominins in the Turkana Basin[END_REF][START_REF] Vrba | Paleoclimate and Evolution, with Emphasis on Human Origins[END_REF]. Understanding the relationship between paleoclimatic/paleoenvironmental variation and evolutionary change is one of the key scientific questions in the field of human evolution. The Hominin Sites and Paleolakes Drilling Project (HSPDP) addresses this question by reconstructing the paleoclimate and paleoenvironment record at targeted sites in the East Africa Rift System [START_REF] Campisano | The Hominin Sites and Paleolakes Drilling Project: High-Resolution Paleoclimate Records from the East African Rift System and Their Implications for Understanding the Environmental Context of Hominin Evolution[END_REF]Cohen et al., 2016). These sites in Kenya and Ethiopia correspond both in space and in time to important periods of our evolutionary past. A total of over 2 km of sediment cores has been recovered from six paleolakes [START_REF] Campisano | The Hominin Sites and Paleolakes Drilling Project: High-Resolution Paleoclimate Records from the East African Rift System and Their Implications for Understanding the Environmental Context of Hominin Evolution[END_REF]Cohen et al., 2016). Precise chronostratigraphic control of the cores is essential for establishing potential links between paleoclimate, paleoenvironment, and evolution.

The main aim of this paper is to present the magnetostratigraphic interpretation of the 228 meter long Baringo-Tugen Hills-Barsemoi (BTB13) core drilled in 2013. The estimated age range targeted for the BTB13 core was 3.3 to 2.6 Ma (Cohen et al., 2016).

Within this time period many important events and transitions occurred in terms of human evolution and climate. At ~3.4 Ma the earliest evidence for processing meat has been identified in Dikika, Ethiopia [START_REF] Mcpherron | Evidence for stone-tool-assisted consumption of animal tissues before 3.39 million years ago at Dikika, Ethiopia[END_REF], followed by the earliest known stone tool technology, the Lomekwian, at around 3.3 Ma [START_REF] Harmand | 3.3million-year-old stone tools from Lomekwi 3, West Turkana, Kenya[END_REF].

Another major transition occurs at around 2.6 Ma when the more widespread Oldowan stone tool technology makes it appearance [START_REF] Braun | Earliest known Oldowan artifacts at >2.58 Ma from Ledi-Geraru, Ethiopia, highlight early technological diversity[END_REF]. Furthermore, the first appearance of the genus Homo at 2.8 Ma [START_REF] Villmoare | Paleoanthropology. Early Homo at 2.8 Ma from Ledi-Geraru, Afar, Ethiopia[END_REF] and Paranthropus [START_REF] Walker | 2.5-Myr Australopithecus boisei from west of Lake Turkana, Kenya[END_REF] fall within the period covered by the BTB13 core. Around this same period, Northern Hemisphere glaciations began to enhance global climatic variations [START_REF] Raymo | The Initiation of Northern Hemisphere Glaciation[END_REF]. This combination of hominin evolutionary and climatic events during an interval of strong Plio-Pleistocene climatic fluctuations provides an excellent opportunity to test evolution models (e.g. deMenocal, 2004;[START_REF] Foley | Speciation, extinction and climatic change in hominid evolution[END_REF].

The main benefits for drilling cores are two-fold. On the one hand, drilled cores enable the study of a long continuous sections, not constructed from correlated short outcrop sections. A second important benefit is that the drilled sediments have been less exposed to weathering. This improves not only the quality of the paleoclimatic record J o u r n a l P r e -p r o o f but also the paleomagnetic record as weathering may alter the preservation of primary magnetization.

Reconstructing the stratigraphic positions of magnetic polarity reversals of known age (i.e. magnetostratigraphy) in cores usually relies on the paleomagnetic inclination, as the paleomagnetic declination cannot be established because of the rotational movement of the core segments during the drilling process. A downward inclination, in northern latitudes indicates a normal paleomagnetic direction whereas an upward inclination indicates a reversed paleomagnetic direction. However, the HSPDP sites are located at low latitudes, where the inclination of the Earth´s (paleo)magnetic field is sub-horizontal, making it ineffective to use inclination for reconstructing the magnetostratigraphy. For the HSPDP project we developed a set of custom paleomagnetic processing techniques (for details see Sier et al., 2017). The first method uses the sedimentary fabric as expressed in the anisotropy of the magnetic susceptibility (AMS), and the second uses the occurrence of secondary viscous (paleo)magnetic component oriented in the present-day field for orientating primary paleomagnetic directions. For this study, we use both methods and our results match with the 40 Ar/ 39 Ar ages from the same core (see Deino et al., this issue for discussion).

Geological setting

The drill site (latitude 0.5546°N, longitude 35.9375°E) is located in the Baringo Basin/Tugen Hills, which is part of the Central Kenya Rift Valley, west of Lake Baringo (Fig. 1). The basin contains the most complete late Neogene sequence of the East African Rift with a duration of 16 Myr [START_REF] Behrensmeyer | Geology and geochronology of the middle Miocene Kipsaramon site complex, Muruyur Beds, Tugen Hills, Kenya[END_REF][START_REF] Chapman | Chronostratigraphy of the Baringo Basin, Kenya[END_REF][START_REF] Hill | Paleoanthropological research in the Tugen Hills, Kenya[END_REF] and a thickness of ~3 km [START_REF] Gilbert | Miocene Cercopithecoidea from the Tugen Hills, Kenya[END_REF]. The sediments are divided into a number of formations. The Chemeron Formation, which was first formally described by [START_REF] Mccall | Late Tertiary and Quaternary sediments of the Kenya Rift Valley[END_REF], ranges in age from 5.3 to 1.6 Ma [START_REF] Deino | this issue. Chronostratigraphy of the Baringo-Tugen-Barsemoi (HSPDP-BTB13-1A) core -40Ar/39Ar dating, magnetostratigraphy, tephrostratigraphy, sequence stratigraphy and Bayesian age modeling[END_REF]. It is exposed in the eastern foothills of a westward tilted horst block within the basin. The formation consists of lacustrine and subaerial sedimentary strata and relatively minor siliceous tuffs.

The 228 meter long core was recovered at a distance of about 20 meters from cliff exposures [START_REF] Campisano | The Hominin Sites and Paleolakes Drilling Project: High-Resolution Paleoclimate Records from the East African Rift System and Their Implications for Understanding the Environmental Context of Hominin Evolution[END_REF]. The cored strata are correlated to dated outcrops ranging from ~2.6 to 3.3 Ma (Cohen et al., 2016;Deino et al., this issue). The upper part contains five cyclic deep-lake diatomites correlated in outcrop to Diatomite 5 to J o u r n a l P r e -p r o o f Diatomite 1 from youngest to oldest [START_REF] Deino | this issue. Chronostratigraphy of the Baringo-Tugen-Barsemoi (HSPDP-BTB13-1A) core -40Ar/39Ar dating, magnetostratigraphy, tephrostratigraphy, sequence stratigraphy and Bayesian age modeling[END_REF][START_REF] Kingston | Astronomically forced climate change in the Kenyan Rift Valley 2.7-2.55 Ma: implications for the evolution of early hominin ecosystems[END_REF]. The lower part of the core consists of fluviolacustrine deposits and floodplain paleosols (Scott et al., this issue). Full stratigraphic descriptions are reported in Scott et al. (this issue).

Methods

Sampling of BTB13 core

Paleomagnetic samples were collected directly after the splitting of the core at the US National Lacustrine Core Facility (LacCore) at the University of Minnesota (USA). The vertically drilled 228 meters long BTB13 core (for drilling details see Cohen et al., 2016) was sampled at 543 levels for a total of 567 paleomagnetic samples in regular intervals throughout the core, with an average spatial resolution of around 0.41 cm. The sample stratigraphic position was measured with < 0.5 cm precision. The orientation with respect to the top of the core was then marked on each sample. Samples were collected using several methods. Most samples were extracted using an drill press equipped with a water-cooled diamond-coated 2.5 cm diameter bit. Levels too soft for drilling were sampled by gently pushing custom-made quartz containers, with standard paleomagnetic sampling dimensions (25 mm diameter, 22 mm length), into the sediment. Levels that were too fragile for drilling but not soft enough for insertion of the quartz cup containers were carefully carved out in blocks of 2x2 cm. Some levels also had small unoriented samples collected for rock magnetic experiments. With these various techniques, all lithologies encountered in the core could be sampled. Only intervals where the core was broken up as a result of the drilling process were avoided.

After labelling, the samples were wrapped in laboratory-grade air-tight cellophane and stored at temperatures below 5° Celsius.

Rock magnetism

In order to help identify the magnetic mineralogy, several rock magnetic measurements were undertaken. To quantify the characteristic behavior of the magnetic mineralogy of the individual samples during heating and cooling, thermomagnetic curves were measured in air on a modified horizontal translation-type Curie balance J o u r n a l P r e -p r o o f with a sensitivity of about 5 x 10 -9 Am 2 [START_REF] Mullender | Continuous drift correction and separate identification of ferrimagnetic and paramagnetic contributions in thermomagnetic runs[END_REF] at the Paleomagnetic Laboratory Fort Hoofddijk, Utrecht University, the Netherlands. Four samples were powdered with a mortar, and weights were measured on a laboratory scale. The powder was put in a small container on a quartz rod, and the container was closed with quartz wool. The magnetic field was cycled between a minimum of 100 mT and a maximum of 300 mT. Heating and cooling cycles (with rates of 6° and 10°C/min) were run using cycles 20-300, 200-400, 300-700 °C (Fig. 2a).

Hysteresis curves of 50 samples (see Supplemental Table S1) were measured on a vibrating sample magnetometer (VSM, MicroMag Model 3900; Princeton Measurements). The hysteresis parameters (the saturation remanence M sr , saturation magnetization M s , the remanent coercive force H cr and he ordinary coercive force H c ) give information about the domain state or paleomagnetic stability of magnetic minerals in the samples (Dunlop et al., 2002a). A correction for paramagnetic contribution was applied to the hysteresis curves and the hysteresis parameters were determined. The ration of the hysteresis parameters (M sr / M s ) were plotted against (H cr / H c ) in a Day plot [START_REF] Day | Hysteresis properties of titanomagnetites: Grain-size and compositional dependence[END_REF] and using the approach of Dunlop (2002a,b), were interpreted in terms of (mixtures of) superparamagnetic (SP), single domain (SD), pseudo single domain (PSD) and multi domain (MD: Fig 3b).

Furthermore, 26 samples (Fig. 2b) were subjected to an IRM acquisition (using a 2G pulse magnetizer, 2G Enterprises) up to 1T, then given an IRM of 0.3T in the antiparallel direction to separate higher from lower coercivities, and then a stepwise thermal (TH) demagnetization of these separated components of the natural remanent magnetization (NRM) in 12 temperature steps in order to further help mineral identification by means of unblocking temperatures [START_REF] Heller | Rockmagnetic studies of Upper Jurassic limestones from Southern Germany[END_REF].

Demagnetization and ChRM directions

Stepwise progressive TH demagnetization of the NRM was performed for 262 samples up to a maximum of 600° Celsius, in 12 or 14 temperature steps using an ASC thermal demagnetizer (residual field < 20 nT) at the Fort Hoofddijk Paleomagnetic Laboratory (Utrecht University, the Netherlands) and the Centro Nacional de Investigación sobre la Evolución Humana (CENIEH) in Burgos (Spain). After each step the remaining NRM was measured with a 2G DC-SQUID cryogenic magnetometer. NRM intensities were typically several orders of magnitude higher than the instrument J o u r n a l P r e -p r o o f sensitivity (~3x10 -12 Am 2 ). During the demagnetization process, the specimens were kept in a shielded environment. No notable differences of results between the two laboratories have been observed. Stepwise progressive Alternating Field (AF) demagnetization was done for two pilot samples up to a maximum of 100 mT, in 16 alternating field steps using the integrated AF demagnetizer of the DC-SQUID magnetometer of the CENIEH. However, these resulted in unclear component separation compared to thermal demagnetizations such that thermal demagnetization was exclusively used for further samples. After a pilot study of 100 samples carefully demagnetized with numerous temperature steps, further selected samples were processed with optimal demagnetization steps.

The demagnetization results were interpreted in terms of components to identify the ChRM directions using Paleomagnetism.org, an online multi-platform open source environment for paleomagnetic data analysis [START_REF] Koymans | Paleomagnetism.org: An online multi-platform open source environment for paleomagnetic data analysis[END_REF] providing a suite of techniques to statistically interpret the results [START_REF] Creer | Palaeomagnetic and palaeontological dating of a section at Gioia Tauro, Italy: Identification of the Blake event[END_REF][START_REF] Deenen | Geomagnetic secular variation and the statistics of palaeomagnetic directions[END_REF][START_REF] Fisher | Dispersion on a Sphere[END_REF][START_REF] Kirschvink | The least-square line and plane and the analysis of paleomagnmetic data[END_REF][START_REF] Zijderveld | Ac Demagnetization of Rocks: Analysis of Results, Methods in palaeomagnetism[END_REF]. A minimum of four consecutive steps was considered to define ChRM directions.

Anisotropy of magnetic susceptibility (AMS)

The Anisotropy of Magnetic Susceptibility (AMS) was measured for 210 samples (see Supplemental Table S2) with an MFK1-FA Kappa Bridge before demagnetization.

AMS is useful for determining a dominant orientation of magnetic minerals within a sample. In sedimentary rocks AMS can be used to determine the tectonic and/or sedimentary fabric potentially preserved in the rocks (e.g. [START_REF] Hrouda | Magnetic anisotropy of rocks and its application in geology and geophysics[END_REF]. An ellipsoid describes the AMS geometrically with defined minimum (k min ), intermediate (k int ), and maximum (k max ) axes. During deposition and compaction, sedimentary rocks generally acquire an oblate ´sedimentary fabric´, which can be recognized by having k min directions clustering perpendicular to the bedding plane. The other axes generally are (sub) parallel to the bedding plane with no preferred orientation unless affected by tectonic or depositional processes.

J o u r n a l P r e -p r o o f

Reorientation of ChRM directions

Due to the rotational movement of the drilling, the azimuthal orientation of the HSPDP cores are lost. Additionally, the low latitudes of core locations hampered the use of the inclination of the paleomagnetic direction as a proxy for paleomagnetic polarity. To overcome this challenge, we have used two independent methods to reorientate the BTB13 and other HSPDP cores. First, the AMS principle tensor directions preserve the orientation of the sedimentary fabric and thus enables the bedding dip to be estimated (see Sier et. al., 2017 for more details). To be effective, a bedding dip of at least 15 degrees is required and the dip direction should be known. This can be achieved by drilling dipping strata or by drilling at an angle or both. If the dip direction is unknown or has large variations in direction, this method cannot be used for identifying magnetic polarity zones. The second method uses as an indication of the north, the possible occurrence of a secondary present-day overprint on top of the ChRM direction [START_REF] Fuller | Magnetic orientation of borehole cores[END_REF]. This method requires the occurrence of this secondary overprint, the preservation of the original ChRM, and that both components can be distinguished from another. In practice, not all samples meet these preconditions (see below).

Results

Anisotropy of magnetic susceptibility (AMS)

A total of 240 AMS measurements of the BTB13 core paleomagnetic samples were processed (Supplemental Table S2), of which 32 outliers were ignored because of indications of measurement errors during the measurement process (L, F, P values of 1,000). The remaining 208 are plotted in Figure 4. The stereographic projection show a typical distribution for a sedimentary fabric. The k min axes cluster around the vertical, and the K max and K int distributed along the horizontal. The anisotropy (P) of most samples is fully expressed by foliations (F) in the 0-2% range. This foliation is generally higher (average 1.4 %) and more variable from 5.25 to 130 meters below surface (mbs) compared to below 130 mbs (average 0.6 %), with notable peaks above 2% and up to 7% at 180 mbs, 120 mbs, 110 mbs, and 90 mbs. From 25 mbs to 50 mbs, there is a progressive increase in K min inclinations from ca. 45° to 80°, which J o u r n a l P r e -p r o o f corresponds to a shallowing of bedding dip from 45° to 10°. Generally, high K min inclinations between 50 mbs and 210 mbs, indicate continuance of a consistent dip.

Exceptions are short intervals at 145 mbs, 160 mbs, and 195 mbs. Below ca. 210 mbs, lower K min inclinations point towards increased bedding dip. Note that occasional spuriously low K min inclinations cannot relate to bedding dip changes, but rather to variable rock magnetic properties caused by lithological variations or strata disturbed by faulting.

The results of the AMS reveal the sections of the core with flat-lying bedding orientations are not suitable to infer normal and reversed polarities. The cause of this is firstly that the orientation of the magnetic directions will be indistinguishable from the bedding dip. In addition, the declination of the K min cannot be used to estimate the dip direction as previously done to recover the orientation of the WKT14 core (Sier et al., 2017) and ultimately recover the paleomagnetic polarity. Even in the more steeply dipping portions (5.25-50 mbs and below 210 mbs), comparing K min inclinations with ChRM declinations yields unfortunately very variable declinations with no consistent pattern from which to infer paleomagnetic polarity (Supplemental Table S2). This may be attributed to variability in the AMS results, but also the variability in the ChRM directions that may include mixed primary and secondary directions (see below).

Demagnetization Results

A total of 543 BTB13 core levels have been sampled for paleomagnetic analyses of which 264 samples were thermally or alternating field demagnetized, 257 samples were of sufficient quality to yield interpretable directions (see Supplemental Table S3).

The Zijderveld diagrams (Fig. 5) show a low-temperature (LT) component from 20°C to 150-200°C occasional extending to 250°C. The high-temperature (HT) component follows the LT from 175-250°C to 550-600°C. For a large majority of the samples, demagnetization was completed above 550°C with a maximum of 600°C, but in some cases, samples were fully demagnetized by 350°C. The relationship between the LT and HT can be divided into two groups. One group has parallel LT-HT components whereas a second group has LT components, which are antiparallel or at a high angle to the HT component. This distribution is typical of an LT component representing a modern secondary overprint exclusively in a normal polarity orientation and a HT J o u r n a l P r e -p r o o f component with a primary magnetization of normal or reversed polarities. This was often observed in previous paleomagnetic studies in the volcanic-rich East African Rift (e.g. [START_REF] Deino | 40Ar/(39)Ar geochronology and paleomagnetic stratigraphy of the Lukeino and lower Chemeron Formations at Tabarin and Kapcheberek, Tugen Hills, Kenya[END_REF][START_REF] Dupont-Nivet | Magnetostratigraphy of the eastern Hadar Basin (Ledi-Geraru research area, Ethiopia) and implications for hominin paleoenvironments[END_REF].

Rock magnetic results

Rock magnetic properties were explored to help identify the nature of the observed LT and HT components so that their secondary and primary origins can be better assessed. Previous paleomagnetic studies from the surrounding outcrop section of the same stratigraphy have indicated a dominance of Ti-rich titanomagnetite in the magnetic carriers [START_REF] Deino | this issue. Chronostratigraphy of the Baringo-Tugen-Barsemoi (HSPDP-BTB13-1A) core -40Ar/39Ar dating, magnetostratigraphy, tephrostratigraphy, sequence stratigraphy and Bayesian age modeling[END_REF]. This is often the case in the rift valley, which is dominated by volcanic environments and often leads to well preserved primary magnetizations. Pervasive secondary overprints carried by less stable Ti-rich magnetite in larger multi-domain grains are usually observed with normal polarity present-day field orientation (e.g. [START_REF] Dupont-Nivet | Magnetostratigraphy of the eastern Hadar Basin (Ledi-Geraru research area, Ethiopia) and implications for hominin paleoenvironments[END_REF][START_REF] Joordens | An astronomically-tuned climate framework for hominins in the Turkana Basin[END_REF]Sier et al., 2017).

However, the properties may be different in the core material, which may be less affected by post-depositional alteration compared to outcrops.

NRM intensities are generally high (Supplemental Table S2) suggesting, along with high bulk susceptibility values (Supplemental Table S3), that magnetite-like (ferromagnetic) minerals are important contributors to the magnetization.

Curie Balance thermomagnetic runs (Fig. 2a) show a loss of magnetization mostly between 200°C and 500°C with the destruction of the magnetic phase and no creation of new magnetic phases. This is generally consistent with the thermomagnetic behavior of magnetite but contrary to the expected behavior for iron sulfides that would transform into magnetite in that temperature range.

The IRM acquisition and thermal demagnetizations (Fig. 2b) show two groups of higher and lower coercivities respectively, which demagnetize following the two components LT (0-150°C) and HT (150-550°C) similar to most of the thermal demagnetizations of the core (see above). In both high and low coercivity groups, the LT component shows a marked decrease ca. 125-150°C and the HT component is mostly decreasing steadily from 150°C to 550°C. Sometimes a marked decrease around 500-600°C can be observed in the high coercivity group.

Hysteresis curves (Fig. 3a) can be separated into two groups. One group (BTB13-1A-43Q-1-102 and BTB13-7Q-2-58 in Fig. 3a) shows no indication for high J o u r n a l P r e -p r o o f coercivity minerals. The second group show wasp-waisted hysteresis curves (BTB13-1A-50Q-3-2/68Q-2-14) indicating the presence of higher coercive minerals or a mixture of lower and higher coercivities [START_REF] Tauxe | Potbellies, wasp-waists, and superparamagnetism in magnetic hysteresis[END_REF]. These behaviors correspond well with the results of the IRM demagnetization presented above. Saturation generally reached near 200 mT may correspond to magnetite or an iron sulfide such as greigite but indicate no influence of the high coercivity goethite or hematite minerals in those samples (e.g. [START_REF] Roberts | Magnetic properties of ssedimentary greigite (Fe 3 S 4 ): An update[END_REF][START_REF] Vasiliev | Early diagenetic greigite as a recorder of the palaeomagnetic signal in Miocene-Pliocene sedimentary rocks of the Carpathian foredeep (Romania)[END_REF]. H c values are around 10 to 20 mT with H cr values between 25 and 60 mT. These values are not diagnostic and may correspond to magnetic minerals such as (titano)magnetite, fine-grained maghemite or iron sulphide such as greigite, and pyrrhotite [START_REF] Özdemir | Effect of crystal defects and internal stress on the domain structure and magnetic properties of magnetite[END_REF][START_REF] Peters | Selected room temperature magnetic parameters as a function of mineralogy, concentration and grain size[END_REF]. The Day plot, a plot of ratios M sr /M s and H cr /H c , shows that nearly all values fall within the SD domain with a group near or on the SP boundary (Fig. 3b).

These SP values may correspond to very fine-grained magnetic minerals from detrital sediment material and/or be produced in situ by post-depositional processes such as diagenesis and pedogenesis (Dunlop, 2002a(Dunlop, , 2002b)).

In summary, the rock magnetic properties of investigated samples, along with the demagnetizations and AMS results, are not distinguishable from properties of nearby outcrop results that have been previously shown to be dominated by magnetite with variable Ti content and grain-size typical of volcanic-rich sediments of the East African rift. The dominance of a low coercivity component demagnetizing mainly in the 200-550°C range is consistent with the presence of titanomagnetite with significant Ti content. The phase of higher coercivity demagnetizing below 200°C is consistent with goethite, however it is not suggested by hysteresis curves and may instead relate to high Ti titanomagnetite. The higher coercivity fraction demagnetized between 500-600°C remains enigmatic. It may relate to very fine-grained hematite that does not appear on the hysteresis dominated by magnetite. Rock magnetic data of the BTB13 core investigated here are not distinguishable from a dominant titanomagnetite behavior that was identified in the outcrop as being the primary carrier of magnetization [START_REF] Deino | 40Ar/(39)Ar geochronology and paleomagnetic stratigraphy of the Lukeino and lower Chemeron Formations at Tabarin and Kapcheberek, Tugen Hills, Kenya[END_REF][START_REF] Deino | this issue. Chronostratigraphy of the Baringo-Tugen-Barsemoi (HSPDP-BTB13-1A) core -40Ar/39Ar dating, magnetostratigraphy, tephrostratigraphy, sequence stratigraphy and Bayesian age modeling[END_REF]. This supports the assumption that the LT component may be interpreted as a secondary normal overprint on a primary HT component as observed in previous outcrop paleomagnetic results.

J o u r n a l P r e -p r o o f

Identification of the ChRM directions and polarities

As mentioned above (Section 4.1), re-orientation of samples by means of AMS (Sier et al., 2017) proved inefficient because of mostly horizontal bedding orientation throughout the core. Changes in dip of the bedding was also observed during the sampling when stratification was expressed in the sediment, showing relatively steep bedding in the upper 20 to 30 meters to nearly flat lying in the middle part with occasional steep intervals, especially in the lowermost 20 to 30 meters of the core.

However, these observations only provide an approximate and patchy record of bedding dip. These variations were not related to the placement of the core split at different orientations but to actual changes in the bedding orientation. This is confirmed by the AMS measurements of 210 samples throughout the core (see Supplemental Table S2), indicating a significant flattening of the bedding below 50 mbs and occasional local variations at 145 mbs, 160 mbs, 195 mbs, and generally below 210 mbs.

For re-orienting the samples, we therefore used only the normal overprints. As mentioned above (Section 4.3) two groups of demagnetization diagrams can be identified. We first have interpreted the group showing antiparallel LT and HT directions as having a primary reversed HT direction. Directions were calculated from LT as well as HT components using line fits. To re-orient those samples, the HT directions were simply rotated the amount necessary to rotate the LT component towards the north (e.g. LT with 270° needs to be rotated 90°, the corresponding HT direction has also 90° added, see also Supplemental Table S3). In a few samples, a reversed direction is clearly indicated by a high angle between the HT component and the LT component. However, HT and LT are not antiparallel because of an LT component less strongly expressed and overlapping with the HT component. For these few samples a great circle was fit to the points over the overlapping components. The direction of the LT component was assigned to the point on the great circle closest to the antiparallel of the HT component direction, similar to the great circle method developed by [START_REF] Mcfadden | The combined analysis of remagnetization circles and direct observations in palaeomagnetism[END_REF] for overlapping directions (see Supplemental Table 4). These methods enabled identification and subsequent reorientation of reversed polarity samples.

Identifying normal polarity directions by this method is generally more challenging than identifying reversed polarity direction, because normal overprints are not always expressed (i.e. originally reversed samples without a normal overprint J o u r n a l P r e -p r o o f cannot be distinguished from originally normal directions with or without a normal overprint). Nevertheless, we initially interpreted all samples with parallel LT and HT directions as of normal polarity and re-oriented them by rotating the LT towards the North. When plotted stratigraphically (Fig. 6), this resulted in zones of exclusively normal polarity direction and zones with mixed normal and reversed polarity directions. This shows that originally reversed directions have been interpreted as normal directions that are now mixed within reversed polarity zones. Based on this dataset our best approximation for identifying polarity reversals was to position them at the boundary between exclusively normal zones and mixed reversed and normal zones. The first identified reversed sample after an exclusively normal zone therefore defines the boundary. Based on this method, we identified four reversals precisely at 19.79 ± 0.1 mbs, 125.86 ± 0.3 mbs, 154.64 ± 0.145 mbs and 199.635 ± 0.245 mbs, respectively, defining two normal and three reversed zones (Fig. 6). However, it is possible that the boundary is located slightly into the normal zone because of potential unidentified reversed directions in this normal zone. Although a few reversed samples may have been missed over the reversals, we argue that large errors in the positioning of paleomagnetic reversals are unlikely given that the core has been sampled at high resolution. For that matter, in the critical intervals around potential reversals, a second set of closely spaced samples were analyzed to define the reversal interval as tightly as possible.

Discussion

Re-orientation of rotatory drilled cores near the equator for magnetostratigraphic purposes is a major challenge. Cores drilled at higher latitudes have their magnetostratigraphy determined on the basis of changes in paleomagnetic inclination. A change from a downwards to upwards inclination (and vice versa) indicates a reversal. However, near the equator the inclination of the Earth"s magnetic field is near zero and changes in inclinations are most likely the results of secular variation. As a result, the determination of the magnetic polarity in cores near the equator on the basis of inclination is not possible. For the HSPDP project we have used two methods to circumvent this issue (for more details see Sier et al, 2017). The first method based on AMS requires a constant bedding dip throughout the core of at least 15° in order to separate the bedding signal from the intrinsic noise in the AMS data. A significant J o u r n a l P r e -p r o o f eastward dip of the strata was present near outcrops at the BTB13 drill site [START_REF] Deino | this issue. Chronostratigraphy of the Baringo-Tugen-Barsemoi (HSPDP-BTB13-1A) core -40Ar/39Ar dating, magnetostratigraphy, tephrostratigraphy, sequence stratigraphy and Bayesian age modeling[END_REF]. For this reason, the BTB13 core was drilled straight down, unlike the Turkana core, as no added angle was thought to be needed for the AMS reorientation method (see also Sier et al., 2017). However, during the splitting and sampling of the core it was observed that the bedding dip had some variation (Cohen et al., 2016) and it was confirmed by the AMS data to be mostly flat lying below 50 mbs (Fig. 4 and Supplemental Table S2). As a result, the reorientation of the BTB13 core by means of the AMS reorientation method was not successful as it failed to identify zones of magnetic polarity. The procedure was unsuccessful even in portions of the core with sufficient dip to apply this method, especially in the upper 50 meters. This is explained by the variability in the quality of the AMS directions that may relate to variations in lithology and rock magnetic properties. It is also related to the high variability in ChRM directions due to the presence of overlapping secondary overprints sometimes fully erasing the primary component. This underlines that this method requires high quality ChRM and AMS data in addition to a good control of bedding orientations.

The second method, based on the direction a secondary paleomagnetic component, however, was successfully applied to the BTB13 core. This method was shown to be applicable because of the occurrence of a secondary low-temperature component normal overprinting a high-temperature component with primary normal or reverse directions. This pattern observed in the BTB13 core Zijderveld diagrams (see Fig. 5) could be confirmed by similar paleomagnetic components in outcrops of the same stratigraphic intervals [START_REF] Deino | 40Ar/(39)Ar geochronology and paleomagnetic stratigraphy of the Lukeino and lower Chemeron Formations at Tabarin and Kapcheberek, Tugen Hills, Kenya[END_REF][START_REF] Deino | this issue. Chronostratigraphy of the Baringo-Tugen-Barsemoi (HSPDP-BTB13-1A) core -40Ar/39Ar dating, magnetostratigraphy, tephrostratigraphy, sequence stratigraphy and Bayesian age modeling[END_REF]. Furthermore, the rock magnetic behaviors explored in the core samples were shown to be very similar to the outcrop indicating magnetite with variable Ti content as the main carrier of the LT and HT components. This validated this assumption of a normal LT overprint on a primary HT ChRM. When present, the two (unoriented) directions could be separated in the majority of the samples. However, in some samples, two directions resulting from overlapping directions were present but lacked a clear separation of components. We managed to obtain and separate LT and HT directions in these samples by using an adapted great circle analysis (see Section 4.4 and Fig. 5). ChRM directions from HT components were re-orientated by rotating the LT declinations towards the north assuming they are normal overprints. Plotting the resulting directions clearly identify five paleomagnetic polarity zones with reversed zones showing mixed reversed and J o u r n a l P r e -p r o o f Journal Pre-proof normal (Fig. 6). To estimate the reversal position, we used the first reversed sample after an exclusively normal zone. To confirm reversals,we we decreased samples spacing in critical intervals.

With the help of the radiometric ages obtained from the same core (see Deino et al., this issue), we could identify the paleomagnetic reversals at the zone boundaries. A unique correlation to known reversals could be readily achieved based on the other 29 control points that were used to develop a Bayesian chronostratigraphic model for the BTB13 core. These include 40 Ar/ 39 Ar dating of tuffs obtained directly from samples from the core, but also by correlating dated outcrops tuffs to the core based on geochemical correlation identification (Garello et al., this issue). In addition, extra control points were obtained from ages of Diatomites 1 through 5 based on outcrop calibration by 40 Ar/ 39 Ar-dating of intercalated tuffs [START_REF] Deino | this issue. Chronostratigraphy of the Baringo-Tugen-Barsemoi (HSPDP-BTB13-1A) core -40Ar/39Ar dating, magnetostratigraphy, tephrostratigraphy, sequence stratigraphy and Bayesian age modeling[END_REF][START_REF] Kingston | Astronomically forced climate change in the Kenyan Rift Valley 2.7-2.55 Ma: implications for the evolution of early hominin ecosystems[END_REF].

The top reversal can be directly correlated to the nearest outcrop (~20 m) where the Matuyama-Gauss reversal has been identified within Diatomite 4 and several core to outcrop correlations of 40 Ar/ 39 Ar dates [START_REF] Deino | this issue. Chronostratigraphy of the Baringo-Tugen-Barsemoi (HSPDP-BTB13-1A) core -40Ar/39Ar dating, magnetostratigraphy, tephrostratigraphy, sequence stratigraphy and Bayesian age modeling[END_REF]~2.61 Ma or the point marked "A" on figure 6 in Deino et al., this issue). Finding the Matuyama-Gauss reversal within the same diatomite in the BTB13 core supports the validity of our paleomagnetic methods. The three reversals observed below the Matuyama-Gauss are interpreted to correlate to the Gauss-Kaena, Kaena-Gauss and Gauss-Mammoth.

Reversal ages are based on the geomagnetic polarity time scale (GPTS 2012;[START_REF] Gradstein | The Geologic Time Scale[END_REF] except for the Matuyama-Gauss transition that has been shown to be slightly older [START_REF] Deino | this issue. Chronostratigraphy of the Baringo-Tugen-Barsemoi (HSPDP-BTB13-1A) core -40Ar/39Ar dating, magnetostratigraphy, tephrostratigraphy, sequence stratigraphy and Bayesian age modeling[END_REF]. Instead, an age of 2.608 Ma was used based on the median of the GPTS12 marine stack [START_REF] Lisiecki | A Pliocene-Pleistocene stack of 57 globally distributed benthic δ 18 O records[END_REF], and evidence from the Boring Volcanic field [START_REF] Hagstrum | Paleomagnetism and 40 Ar/ 39 Ar geochronology of the Plio-Pleistocene Boring Volcanic Field: Implications for the geomagnetic polarity time scale and paleosecular variation[END_REF]. For a detailed discussion on that matter see Deino et al. ( Throughout the core, the resulting age model reveals three main intervals of accumulation rates, from relatively fast rates from 3.2-2.9 Ma to a slower accumulation rates down from 2.9-2.7 Ma and higher rates from 2.7-2.6 Ma (Deino et al., this issue).

Within the control points and in accordance to these accumulation rates, alternatives to the proposed correlations of observed polarity reversals are virtually impossible. Within the upper part of the Gauss we have identified two isolated reversed samples at 66.52 mbs (2.70 Ma) and 91.52 mbs (2.82 Ma), which could indicate paleomagnetic excursions, but this remains speculative as we are dealing with single samples and no excursion has been previously identified in the considered time interval.

Conclusions

We have analysed a total of 264 paleomagnetic samples and our results identify four paleomagnetic reversals. The Matuyama-Gauss (2.602 + 0.013 Ma), the upper Kaena (3.032 + 0.015 Ma), the lower Kaena (3.116 + 0.015 Ma), and the upper Mammoth (3.207 + 0.015 Ma). These four reversals serve as important inputs for the multidisciplinary high-resolution Bayesian chronostratigraphic model of the BTB13 core (Deino et al., this issue). Our rock-magnetic results indicate that the magnetic properties of the remanent magnetizations in the core are similar as in the outcrop with a normal polarity secondary low-temperature component overprinting a primary normal and reverse high-temperature component carried mostly by titanomagnetite. For recovering the polarity zones of the BTB13 core, we have used two independent methods; the first makes use of the preserved AMS sedimentary fabric, whereas the second makes use of either parallel or antiparallel secondary overprints. Because of the near flat-lying orientation of strata in most of the BTB13 core, and the variability in AMS and ChRM direction, the AMS sedimentary fabric method could not be applied successfully to this specific core. However, the secondary overprint method gave clear magnetozones with opposite directions, thus enabling us to identify four reversals.

J o u r n a l P r e -p r o o f  Paleomagnetic study of the core identified four paleomagnetic reversals.  Ages of the reversals are consistent with 40Ar/39Ar dating of tephra s from the same core.

J o u r n a l P r e -p r o o f

Figure 1 :

 1 Figure 1: Map of the Baringo area with geological setting, top left insert shows topographic map of East Africa. Location of BTB13 site (latitude 0.5546N, longitude 35.9375E). Stratigraphy of this figure is described in[START_REF] Deino | this issue. Chronostratigraphy of the Baringo-Tugen-Barsemoi (HSPDP-BTB13-1A) core -40Ar/39Ar dating, magnetostratigraphy, tephrostratigraphy, sequence stratigraphy and Bayesian age modeling[END_REF][START_REF] Kingston | Astronomically forced climate change in the Kenyan Rift Valley 2.7-2.55 Ma: implications for the evolution of early hominin ecosystems[END_REF]

Figure 2 :

 2 Figure 2: A) Thermomagnetic experiment showing the typical high-field magnetic moment upon heating (red) and subsequent (blue) cooling in successive temperature ranges measured on Curie balance. Sample BTB13-1A-49Q-3-14 has a depth of 142.99 mbs. B) Non normalized plotted TH IRM demagnetization. Magnetization versus temperature.

Figure 3 :

 3 Figure 3: A) Hysteresis curves of samples BTB13-1A-50Q-3-2 (146.64 mbs), BTB13-1A-68Q-3-2 (196.17 mbs) and BTB13-1A-43Q-1-102 (123.44 mbs), BTB13-1A-7Q-2-58 (23.86 mbs). A) Day plot of M sr /M s and H cr /H c ratios. The solid and dashed lines represent mixing curves of Dunlop (2002a,b), with SD = single domain, SP = superparamagnetic, and MD = multidomain. The data points (green squares) are from BTB13 core. SD range: M sr /M s 0.5 to 1 H cr /H c and 1 to 2, PSD rage: M sr /M s 0.5 and 0.04 H cr /H c : 2and 5, MD range: M sr /M s 0 to 0.04 H cr /H c : more than 5.

Figure 4 :

 4 Figure 4: A) AMS results BTB13 samples with k1, k2 and k3 axis. B) Only k3 axis of BTB samples. C) P, the degree of AMS (k1/k3) plotted against Km, the mean susceptibility. D) Shape parameter T plotted against P the degree of AMS (k1/k3).

Figure

  Figure made using Anisoft42 software.

Figure 5 :

 5 Figure 5: Typical Zijderveld (1967) diagram examples of two samples (a, b) with reversed ChRM (red arrow) after reorientation of the low temperature overprint to normal directions (blue arrow) and one example of a sample which shows a great circle and for which the two directions could not be fully separated (c, d) Closed/open circles denote projection on a horizontal/vertical plane.

Figure 6 :

 6 Figure 6: Plotted LT/LC (low temperature/ low coercivity) corrected ChRM directions of the BTB13 core. Black dots are interpreted ChRM directions used for interpretation. Grey dots are normal ChRM directions within reversed zone and thus are excluded.Black diamonds are directions obtained by great circle analysis. See text for further explanation. For more detail about lithology seeCohen et al., 2016.

  this issue). The top of the Mammoth chron boundary estimated at 199 + 0.245 mbs is also well constrained near ~184-202 mbs to within ~3.18-3.22 Ma (see age control points G on figure6ofDeino et al., this issue), by core and outcrop 40 Ar/ 39 Ar ages. However, between 101 mbs and 184 mbs (C and F on fig.6ofDeino et al., this issue) the age model is constrained mainly by paleomagnetic reversals and relatively imprecise 40 Ar/ 39 Ar ages from the core. In this section, our methods to determine the reversal positions (see Section 4.4 above) allows for the upper reversal of the reversed Kaena subchron to be higher than indicated, and the lower reversal to be J o u r n a l P r e -p r o o f lower. Interestingly, placing the lower 3.116 Ma Kaena reversal (APTS12 age) lower in the core than indicated (154.6 mbs) would fit better with provided 40 Ar/ 39 Ar age near that interval (159.4 mbs; 3.089 ± 0.026 Ma). In any case, sediment accumulation rates in the interval including the Kaena (B-G; ~2.72 to 3.22 Ma,Deino et al., this issue) do not vary drastically, suggesting the age model is robust.

Acknowledgements

Acquisition of the BTB13 drill core and sampling was funded by the International Continental Drilling Program and US-NSF grants (EAR-1123942, BCS-J o u r n a l P r e -p r o o f 1241790, EAR-1338553, and EAR-1322017). MJS was funded by Netherlands Organisation for Scientific Research grants NWO-ALW 823.01.003 and is currently funded as a Juan de la Cierva post-doctoral fellow. GDN acknowledges funding from Marie Curie CIG FP7 grant 294282 "HIRESDAT". We thank the Kenyan National Council for Science and Technology and Kenyan Ministry of Mines for providing research and export permits, and the National Environmental Management Authority of Kenya for providing environmental permits for the drilling in the Tugen Hills. We also would like to acknowledge DOSECC Exploration Services for drilling supervision, the team of the US National Lacustrine Core Facility (LacCore) for help during drilling and sampling. Finally, we would like to thank the two anonymous reviewers whose comments greatly improved this paper. This is publication number XX of the Hominin Sites and Paleolakes Drilling Project.

The following are the supplementary data related to this article. S1: Hysteresis properties taken from paramagnetic corrected hysteresis curves. Sample ID, Level: stratigraphic level in metres below surface (mbs), relevant hysteresis parameters: saturation magnetization M sr , magnetization M s , remanent coercive force H cr , coercive force H c , and their ratios M sr /M s H cr /H c , Range: PSD pseudo single domain. S2: AMS, Sample ID, Level: stratigraphic level in mbs, Km (mean susceptibility), L (lineation), F (foliation), P (anisotropy degree), Pj (corrected anisotropy degree following Jelinek, 1981), T (shape parameter; oblate shape for 0 < T ≤ 1, prolate shape for -1 ≤ T < 0; Tarling and Hrouda, 1993), K1dec, K1inc, K2dec, K2inc, K3dec, K3inc (declination and inclination of the maximum, intermediate and minimum axes of the anisotropy tensor); K11, K22, K33, K12, K23, K13 (the six tensor elements). S3: S4: Great Circle (GC) palaeomagnetic results. Sample ID#: sample identification; Level: stratigraphic level in metres below surface (mbs); Dec GC: declination of GC in degrees; Inc GC: inclination of GC in degrees; Intensity: intensity of calculated GC in E -6 A/m; MAD: Maximum Angular Deviation; Min Step GC: minimum step of GC in mT and (°); Max Step GC: maximum step of GC in mT and (°)

Supplemental Table

Supplemental Table

Supplemental Table

Supplemental Table

Declaration of interests

The authors declare that they have no known competing financial interests or personal relationships that could have appeared to influence the work reported in this paper.

The authors declare the following financial interests/personal relationships which may be considered as potential competing interests:


Fabien Autrel
email: fabien.autrel@telecom-bretagne.eu

Frédéric Cuppens
email: frederic.cuppens@telecom-bretagne.eu

Nora Cuppens-Boulahia

Keywords: acces control, security policy model, security policy administration, implementation, OrBAC

come

Introduction

As information systems are getting more and more complex, security administrators must face multiple problems related to conguration and security. Those systems generally use wired and wireless connectivity and various hardware which run multiple OSes on which several applications are ran.

In such a context the specication and enforcement of a security policy is a very tedious, complex and error-prone task. Eventually each hardware (a rewall for instance) and software (SELinux for instance) security component conguration are managed manually. This requires learning several conguration languages and writing conguration les for each component. Some administration tools exist to help in the conguration of components but they are almost only targeted at network components. For example Firewall Builder [Firb] or Firestarter [Fira] help the administrator by making easier the specication of security rules. However when it comes to system and application security, the list of tools is drastically shortened.

This article presents MotOrBAC version 2, a tool which as been developed to write security policies. MotOrBAC provides multiple functionalities such as (1) policy specication based on the OrBAC model [KBB + 03], (2) potential and eective conict detection, (3) policy simulation and (4) administration policy specication. MotOrBAC has been developed on top of the OrBAC application programming interface (API), a java API we have developed to ease the integration of our OrBAC implementation. The previous version of MotOrBAC was developped using java and prolog whereas the new version is written in pure java. The new version is also more modular as it uses the OrBAC API.

MotOrBAC aims at giving the user the possibility to specify all his/her security requirements independently of its enforcement. To do so MotOrBAC implements the OrBAC model which species the security requirements at the organizational level. Each security component can be represented as a sub-organization of the organization representing the information system that manages the sub-part of the global policy associated with this component.

Once the policy specication at the organizational level is done, concrete entities corresponding to the information system users, actions and objects can be introduced. This way the policy designer can simulate the security policy by checking the concrete security rules inferred by MotOrBAC.

Centralizing the expression of the security policy oers a framework to analyze its consistency. Since the OrBAC model allows the expression of positive (permission) and negative (prohibition) privileges, conicting security rules can be introduced. MotOrBAC can detect those conicts and help the policy designer solve them.

Most of current security models make the hypothesis that only one administrator will write and maintain the information system security policy. As those systems become more and more distributed, this hypothesis is no longer adapted. MotOrBAC implements the AdOrBAC [START_REF] Cuppens | Administration model for Or-BAC[END_REF] administration model which uses the concepts developed in OrBAC (thus making OrBAC a self-administrated model). Using AdOrBAC, policy administration rights can be distributed over several roles. When the AdOrBAC mode is activated, the current policy designer must authenticate himself/herself and then the corresponding administration policy is applied.

This article is organized as follows: Section 2 motivates the need for a centralized specication and management tool. Section 2.2 briey introduces the OrBAC model and presents the main functionalities of MotOrBAC. Section 3 explains how the tool can be used to write a security policy. Section 4 presents the concrete policy simulation tool. Section 5 explains how the conict detection functionality can be used to solve conicts. Section 6 presents the AdOrBAC implementation. Section 7 gives more details on the MotOrBAC architecture and explains how the OrBAC API can be integrated into an application to enforce an OrBAC policy. Finally section 8 concludes this paper and presents some future evolutions.

2 The need for an administration tool

Context

Nowadays private and public organizations face several problems when they try to specify and enforce the security policy of their information systems. To illustrate some of those problems, let us take a look at an hypothetical organization. Let W orldCompany be a company having several subsidiary companies (F ranceCompany, EnglandCompany, etc...) and subcontractors (T aiwanSubContractor). Several administrators (John, Peter and Rayan) are in charge of the information systems. We suppose that all the subsidiary companies work on the same product and that their hierarchies and workmanship are similar.

W orldCompany would like to dene a consistent security policy which applies to all its subsidiary companies. However the task is complicated by the dierent countries' legislations, the policy must be adapted for each subsidiary company. As this adaptation is going on, W orldCompany realizes that one of its administrators, namely Peter, has designed weak security rules which result in a potential information leak. Since W orldCompany does not know if the not very good work done by P eter is due to a malicious behavior or a lack of information, decision is taken to limit his administrative privileges. Moreover subcontractors need access to the information system of W orldCompany and the associated privileges may be modied as time passes. Besides those aspects, the security policy of W orldCompany shall be modied as new people are hired, old employees retire or the law is changed (for example in France the weekly working time as been modied from 39 hours to 35 hours).

Those problems are not specic to our example and can be encountered in any company that wants to enforce a security policy. Some of those problems are related to a company infrastructure change, others are linked to errors in the policy specication, others may be related to the centralized information and some are related to administrative rights specication. As a matter of fact it is very dicult for a system administrator to have a global view of the security policy in order to manage it correctly. The use of a single software to manage the security policy would simplify a lot their task and solve many problems. However such a tool would be useless if it does not implement a model which allows to express the security problems and administrative needs of a company such as W orldCompany. Such a model should make the management of several entities having various administrative modes (multiple administrators, contextual, centralized, etc...) simple and should allow to verify the policy consistency.

After reviewing many policy models, we came to the conclusion that the OrBAC model ts the specications of the aforementioned tool.

The OrBAC model

OrBAC aims at modelling a security policy centered on the organization which denes it or manages it. Hence a company is an organization but security components such as rewall or the java virtual machine security manager can also be modelled as organizations. An OrBAC policy specication is done at the organizational level, also called the abstract level, and is implementation-independent. The enforced policy, called the concrete policy, is inferred from the abstract policy. This approach makes all the policies expressed in the OrBAC model reproducible and scalable. Actually once the concrete policy is inferred, no modication or tuning has to be done on the inferred policy since it would possibly introduce inconsistencies. Everything is done at the abstract policy specication level. The inferred concrete policy expresses security rules using subject, actions and objects. The abstract policy, specied at the organizational level, is specied using roles, activities and views.

The OrBAC model uses a rst order logic formalism with negation. However since rst order logic is generally undecidable, we have restricted our model in order to be compatible with a stratied Datalog program [START_REF] Jerey | Principles of database and knowledge-base systems[END_REF]. A Datalog program must not use any functional terms and must only include range restricted variables (i.e variables that are in the conclusion of a rule must also appear, not negated, in the rule premise). Negated literals can appear in a rule premise if the rule can be stratied. A stratied Datalog program has all its rules ranked: if some rules contain negative literals then the rules dening those literals are evaluated rst. A stratied Datalog program can be evaluated in polynomial time.

In the rest of this article all the security rules dening a security policy must correspond to a stratied Datalog program. We use a Prolog-like notation1 where terms beginning with an upper case are variables and terms beginning with a lower case are constants. The fact parent(john, jessica). says that john is a parent of jessica. A rule such as grandparent(X, Z) : -parent(X, Y ), parent(Y, Z). means that X is a grandparent of Z if Y exists such that X is a parent of Y and Y is a parent of Z.

Using this formalism, each organization species its own security rules. Some role may have the permission, prohibition or obligation to do some activity on some view given an associated context is true. The context concept [START_REF] Cuppens | Modelling contexts in the Or-BAC model[END_REF] has been introduced in OrBAC in order to express dynamic rules. Those security rules are represented using 5-ary predicates:

• permission(org, role, activity, view, context) means that in organization org, role role is authorized to perform activity activity on view view if context context is true.

• the prohibition and obligation predicates are similarly dened but express dierent security requirements.

• permission(hospital, nurse, consult, medical_record, urgency) means that nurses can access the patients medical records in the context of an emergency.

Security rules can be hierarchically structured so that they are inherited in the organization, role, activity and view hierarchies (see [START_REF] Cuppens | Inheritance hierarchies in the Or-BAC model and application in a network environment[END_REF]). Since a security policy can be inconsistent because of conicting security rules (for example a permission can be in conict with a prohibition), it is necessary to dene strategies to solve those conicts. Section 4 presents the way we solve this problem.

Once the security policy has been specied at the organizational level, it is possible to test it by assigning concrete entities to abstract entities. To do so, three ternary predicates have been dened to assign a subject to a role, an action to an activity and an object to a view:

• empower(Org, Subject, Role): species that in organization Org, subject Subject is empowered in role Role.

• consider(Org, Action, Activity): species that in organization Org, action Action implements activity Activity.

• use(Org, Object, V iew): species that in organization Org, object Object is used in view V iew.

For example, the fact empower(hospital, john, surgeon) states that john is empowered in the role surgeon in the hospital organization. Contexts are dened through logical rules which express the condition that must be true in order for the context to be active. In the OrBAC model such rules haveaected to the predicate hold in their conclusion:

• hold(Org, Subject, Action, Object, Context): species that in organization Org, subject Subject does action Action on object Object in context Context.

Using this model, concrete security rules applying to subject, actions and objects can be inferred. The rules and principles used to infer the concrete security policy are explained in section 5.

Motorbac

In order to allow administrators to use the OrBAC model, we have developed the MotOr-BAC prototype2 . This tool aims at making easy the use of the OrBAC model to express a security policy. Its architecture is presented on gure 1. The architecture and specication of the rst MotOrBAC implementation are presented in [START_REF] Cuppens | MotOrBAC : un outil d'administration et de simulation de politiques de sécurité[END_REF]. MotOrBAC uses the OrBAC application programming interface (API) to manage the policies displayed in the graphical user interface (GUI). The OrBAC API can be used to programmatically create OrBAC policies. More details about the OrBAC API are given in section 7. MotOrBAC can be used to do several tasks on OrBAC security policies:

• Edit policies: the administrator can create the abstract entities he/she needs (organizations, sub-organizations, roles, activities, views, contexts) and the abstract security policies (see section 3).

• Policy simulation: after having specied concrete entities (subjects, actions and objects), the concrete policy can be inferred. Subjects, actions and objects can have attributes (see section 4).

• Policy consistency verication: abstract conicts between abstract rules can be detected (see section 5).

• Once abstract conicts have been detected, MotOrBAC is able to suggest the administrator some solutions to solve them (see section 5).

• Administrative rights management: the administrative rights of a subject or a role can be specied in order to decentralize the policy administration (see section 6).

Security policy specication

Specifying an OrBAC security policy requires dening several abstract entities and their hierarchical relationships.

OrBAC organizational entities in MotOrBAC

When the administrator in charge for the policy specication wants to specify the organization hierarchy, he/she can either specify all the organizations then specify the hierarchical links between them, or he can specify the hierarchical links as he enters them. A hierarchical link between two organizations org 1 and org 2 is recorded into the policy by inserting the following fact: sub_organization(org1, org2)

The organization hierarchy is displayed as a tree control in MotOrBAC, clicking on an organization in this tree displays the policy specied for this organization (roles, activities and views, as well as their hierarchies, and the security rules). Clicking the root of this tree displays the entire security policy. Note that it is possible to specify that an organization inherits from several organizations.

After the organizations have been dened, the administrator can dene the roles, activities, views and contexts for each organization. For example if the role head_nurse is dened in organization hospital as a super-role of nurse, the following objects are inserted into specic views [CBCC07]:

• The role head_nurse is inserted into the role_view view of organization hospital, which is represented by the fact use(hospital, head_nurse, role_view)

• The role hierarchy object RH_hospital_nurse_head_nurse, instance of class role_hierarchy_class (see section 4 for more details on classes in MotOrBAC), is inserted into the view role_hierarchy of organization hospital: use(hospital, RH_hospital_nurse_head_nurse, role_hierarchy). This object has three attributes to dene the hierarchy: -RH_hospital_nurse_head_nurse.authority = hospital -RH_hospital_nurse_head_nurse.senior_role = head_nurse -RH_hospital_nurse_head_nurse.junior_role = nurse Note that since the role hierarchy object is inserted into the role_hierarchy view of an organization, the created role hierarchy is only dened in this organization. This way it is possible to create dierent hierarchies with the same roles in dierent organizations. Note that multiple inheritance can be specied as for organizations.

The activity_hierarchy and view_hierarchy views as well as the activity_hierarchy_class and view_hierarchy_class classes are similarly dened to create activities and views hierarchies.

As abstract entities are dened by the policy designer, he/she can introduce contraints that some entities must respect. If a modication which violates one or more constraints is attempted on the policy, the modication is discarded. In the OrBAC model, constraints are expressed by rules which infer the nullary error predicate. For example a role separation constraint, which states that a subject cannot be aected to two roles at the same time in two organizations, is dened as follows:

error : -separated_role(Org1, Role1, Org2, Role2), empower(Org1, Subject, Role1), empower(Org2, Subject, Role2). Similarly we dene activity, view and context separation constraints. Separation constraints dene symetric and anti-reexive relationships between abstract entities. They motorbac2 can be simply specied by the administrator in the interface without knowledge of its internal representation as inference rules. Section 5 explains how separation constraints can be used to solve policy inconsistences. MotOrBAC implements those separation constraints but does not allow the user to dene its own rules inferring the error predicate. More details about the inference engine used by MotOrBAC are given in section 7.

Once the organizations, roles, activities, views, contexts have been dened, the administrator can specify the abstract permissions, prohibitions and obligations in the corresponding parts of the GUI. When adding a rule, it is dened in the currently selected organization. For example the following rule states that the student role is permitted to access some teaching resources in the context of a economic class project: permission(hospital, student, consult, teaching_resource, eco_projetc_ctx)

Security rules are represented by objects inserted into a specic view called license. Three classes are dened and represent the three dierent security rule types: license_class for permissions, inhibition_class for prohibitions and commitment_class for obligations. When an object is inserted into this view, it is interpreted according to its type. Those classes are also used by the AdOrBAC implementation when specifying the administration policy.

Inheritance

The OrBAC model species the automatic inference of privileges given entities hierarchies. An entity inherits the security requirements expressed on its super entities. Several inheritance mechanisms exist in OrBAC:

• Abstract entities hierarchy inheritance: given an organization, if a security rule applies to an abstract entity e (role, activity or view), then the sub-entities of e inherits the security rule. For example the following rule expresses how permissions are inherited through role hierarchies: permission(Org, Sub_role, Activity, V iew, Context) : -senior_role(Org, Super_role, Sub_role), permission(Org, Super_role, Activity, V iew, Context).

Similar rules exist for activities and views hierarchies. The senior_role relationship is anti-symetric, reexive and transitive (the same applies for the senior_activity and senior_view relationships).

• Separation constraints inheritance: separation constraints are inherited the same way as security rules: separated_role(Org1, Sub_role, Org2, Role2) : -senior_role(Org, Super_role, Sub_role), separated_role(Org1, Super_role, Org2, Role2).

Separation constraints are symetric and anti-reexive relationships: separated_role(Org1, Role1, Org2, Role2) : -separated_role(Org2, Role2, Org1, Role1).

• Organization hierarchy inheritance: security rules are inherited through the organization hierarchy. The following rule denes how permissions are inherited, the same applying for prohibitions and obligations:

Simulation

MotOrBAC can infer a concrete policy given an OrBAC abstract policy P specication and the set of concrete entities assigned to the abstract entities of P . Concrete entities are represented as objects being instances of classes. Each instance has an identier and a list of attributes and values (see gure 3). Attributes are represented using binary predicates in the OrBAC model. For example the predicate diploma(s 1 , doctor) expresses the fact that s 1 has an attribute called diploma which value is doctor. The fact that some object o is an instance of some class c is represented by class(o, c). For instance class(peter, doctor_class) expresses that peter is an instance of the doctor_class class.

The MotOrBAC GUI includes a class editor (gure 2). The administrator can create classes and their attributes as well as class hierarchies. Class attributes are inherited in the class hierarchies. After concrete entities have been created the designer can easily modify their properties so that they are instances of some classes (it is possible to specify multiple class inheritance). When a concrete entity has been set as an instance of some classes, its inherited attributes values can be modied (gure 3). The administrator can then aect concrete entities to abstract entities. This can be done manually through a contextual menu or by specifying entity denitions. Entity denitions are conditions evaluated on a concrete entity attributes. Three dierent types of entity denitions exist: role denition, activity denition and view denition. In the OrBAC model, dening an entity denition implicitly creates the abstract entity associated to the entity denition. In MotOrBAC, abstract entities must be dened before creating any entity denition. Entity denitions can have several conditions, at maximum one per organization, which are inherited through the organization hierarchy the same way context denitions are inherited. A concrete entity can be aected to several abstract entity. For example to automatically assign some subjects to a role doctor in an organization hospital, the administrator can create a role denition. This denition would state that all subjects which have an attribute diploma set to doctor. Using the language used in MotOrBAC, the administrator would write diploma = doctor as the role denition for organization hospital. In section 3.1, we introduced the separation constraints. Those constraint are evaluated each time a concrete entity is aected to an abstract entity, either manually or through an entity denition.

Derivation of concrete security rules

Once concrete entities have been dened and assigned to abstract entities, the organizational policy can be applied to infer the concrete policy. The following rule is used to infer concrete permissions, similar rules are dened for prohibitions and obligations: is_permitted(Subject, Action, Object, P riority) :permission(Org, Role, Activity, V iew, Context, P riority), empower(Org, Subject, Role), consider(Org, Action, Activity), use(Org, Object, V iew), hold(Org, Subject, Action, Object, Context).

Note that we introduce a priority in the abstract permission. This priority is used to rank order abstract rules when conicts are detected. This rule states that if (1) a permission exists in an organization for a role, an activity and a view in some context, (2) a subject is empowered in the role, (3) an action implements the activity, (4) an object is used in the view and (5) the context is active in the organization for the triple {Subject, Action, Object}, then the subject is authorized to do the action on the object. Note that the concrete security rule has the same priority than the abstract rule.

MotOrBAC can infer the concrete policy and show it in a simulation window to help the administrator in his/her task. Figure 4 shows the simulation window. This window lists the concrete security rules in the upper table (a dierent color is used for each rule type) and the contexts states in the lower table. Light-colored entries in the concrete policy table shows concrete security rules for which the associated context is inactive. Light-colored entries in the context table represent inactive contexts.

The following context types are currently implemented in MotOrBAC (see [START_REF] Cuppens | Modelling contexts in the Or-BAC model[END_REF] for more details on the dierent types of contexts dened in OrBAC): temporal contexts (expressing temporal conditions), user dened contexts (contexts which denitions are set to true or f alse) and prerequisite contexts (expressing conditions on the concrete entities' attributes). MotOrBAC also implements context composition, allowing the administrator to express complex contexts. The upper part of the simulation window can be used to If the abstract security policy contains some incoherences, conicting concrete security rules specifying that some subject is at the same time permitted and prohibited from doing the same action on an object may be inferred. MotOrBAC can display the concrete conicts (gure 5) but does not allow the administrator to solve them at the concrete level. The next section explains how such conicts can be avoided at the abstract level so that no conict can exist at the concrete level.

Analysis

Managing conicts

The simulation function presented in the previous section can infer all the concrete conicts. This section presents how abstract conicts can be managed with MotOrBAC (see [START_REF] Cuppens | High-level conict management strategies in advanced access control models[END_REF] for a more in-depth view of abstract conict management). The following rule is used to infer conict at the organizational level:

conf lict :permission(Org1, Role1, Activity1, V iew1, Context1, P riority1), prohibition(Org2, Role2, Activity2, V iew2, Context2, P riority2), not(separated_roles(Org1, Role1, Org2, Role2)), not(separated_activities(Org1, Activity1, Org2, Activity2)), not(separated_views(Org1, V iew1, Org2, V iew2)), not(separated_contexts(Org1, Context1, Org2, Context2)), not(P riority1 < P riority2), not(P riority1 > P riority2). This rule states that if (1) a permission and a prohibition exist at the organizational level, (2) the roles Role1 and Role2 or activities Activity1 and Activity2 or views V iew1 and V iew2 or contexts Context1 and Context2 are not separated or (3) the rules priorities cannot be compared, then potentially concrete conicts can exist. Actually if the same concrete entities subject is empowered in Role1 and Role2, activity implements Activity1 and Activity2, object is used in V iew1 and V iew2, then two concrete conicting rules can be inferred.

If the conf lict predicate cannot be inferred, the policy is said to be consistent. If the policy is consistent, the administrator can assign concrete entities to abstract entities motorbac2 without worrying about concrete conicts since they cannot exist [START_REF] Cuppens | High-level conict management strategies in advanced access control models[END_REF].

Solving conicts with MotOrBAC

MotOrBAC can help the administrator solve the abstract conicts. The detected abstract conicts are listed in the GUI and separation constraints as well as rule priorities can easily be added through a contextual menu (gure 6). The contextual menu gives the administrator several choices:

• Add a separation constraint: depending on the two conicting rules parameters, the administrator can choose to separate at most the rules roles, activities, views and contexts. Figure 6 shows an example of conict where the administrator cannot separate the contexts since they are the same in the two conicting rules.

• Order rules: the administrator as always the choice to modify the priorities between rules when processing a conict. However some rules might become redundant or inapplicable. This article does not tackle the complex problem of detecting those anomalies, see [START_REF] Garcia-Alfaro | Towards ltering and alerting rule rewriting on single-component policies[END_REF] for an example of algorithm given for a network security policy.

The administrator has two other choices not listed in the contextual menu:

• Modify the conicting rules: the conict might be caused by an error in the rules specications.

• Ignore the conict: the administrator can deliberately ignore the conict but might introduce concrete conicts when assigning concrete entities to abstract entities. The OrBAC model also has its administration model, called AdOrBAC [START_REF] Cuppens | Administration model for Or-BAC[END_REF]. AdOrBAC has been designed to express an administration policy using the same concepts introduced in the OrBAC model. This makes the OrBAC model a self-administrated model. AdOrBAC has been designed to be more expressive than ARBAC. For instance AdOrBAC can be used to express that in some company global.com, each department leader has the permission to choose his/her team leader. Such administration rule is dicult to express in ARBAC since it would require to specify as many permissions as the number of teams. The base idea is to consider all administrative operations as insertions of objects into specic views (such as the role_hierarchy_view introduced in section 3) using the use predicate. Figure 7 shows the AdOrBAC administrative views. The following activities can be administrated using these views (see [START_REF] Cuppens-Boulahia | Multi-granular licences to decentralize security administration[END_REF] for more details):

• Permissions management (license view, in which instances of the license_class are used). The inhibition_class and commitment_class are used respectively to specify administrative prohibitions and obligations.

• Concrete entities assignment (role_assignment and activity_assignment views)

• Abstract entities hierarchy management (role_hierarchy, activity_hierarchy, view_hierarchy and context_hierarchy views) Fig. 7: The AdOrBAC views. The administrative policy species the operations permitted on those views

AdOrBAC in MotOrBAC

MotOrBAC includes an administration function implementing the AdOrBAC model [START_REF] Ben Ghorbel | Managing delegation in access control models[END_REF].

When the AdOrBAC function is activated in MotOrBAC, after the user has authenticated himself/herself, he/she can edit the OrBAC security policy accordingly to the AdOrBAC policy. If an unauthorized operation is attempted, the policy is not modied and the user is informed. In [START_REF] Cuppens-Boulahia | Multi-granular licences to decentralize security administration[END_REF] we have shown that AdOrBAC can be used to manage a decentralized administration policy with several administrators having restricted administrative privileges.

The delegation example given in section 6.1 can be specied in AdOrBAC as follows: rst a sub-view of the role view must be created, for example the role_leader sub-view.

Then we put a constraint on this view so that the role_assignment instances used in this view assign subjects to the team_leader role: use(global.com, RA, role_leader) :assignment(RA, role_leader), authority(RA, global.com). then we can give the departement_leader role the right to insert role assignment objects in this view: permission(global.com, departement_leader, insert, role_leader, def ault_context) where insert is an administrative operation consisting in inserting an object into a view. Hence this rule means that the role departement_leader can always (the default context is used in this rule) insert instances of the role_assignment class in the role_leader view.

Since the OrBAC model is self-administrated, a MotOrBAC policy le contains both the OrBAC policy and its associated AdOrBAC policy.

Integration

The concrete security policy inferred by MotOrBAC can be translated to congure a security component such as a rewall for example [START_REF] Cuppens | A formal approach to specify and deploy a network security policy[END_REF]. Another solution to enforce an OrBAC security policy is to use the OrBAC Java API, on top of which MotOrBAC is built. This API uses the Jena3 java library to represent an OrBAC policy as a RDF graph. It can be used to load MotOrBAC RDF policies and interpret them, i.e access control requests can be made on a loaded policy. Jena Features an inference engine which is used by the OrBAC API to infer the concrete policies and the conicts. When an OrBAC RDF policy is loaded by the API, the concrete policy can be inferred and stored in memory. An instance of the OrbacP olicy java class which encapsulates an OrBAC policy uses a cache of concrete security rules to enhance the performances when the policy is queried. Contexts are evaluated upon a query, this feature is actually used in the MotOrBAC simulation tool to show the contexts state. The contexts implementation can be easily extended in order to interface the API with other applications and add new types of contexts.

Integrating the OrBAC Java API4 into a Java application can be done without modifying the application source code. Aspect Oriented Programming (AOP) can be used to separate security concerns from other concerns relative to the application. We have developped an application which simulates a medical form where entries must be led by subjects having specic roles and rights. This little application does not include any security related code. Using AspectJ we weaved the security concerns with the OrBAC API.

The API can also be used to create OrBAC policies, it can be for instance integrated into a web server to communicate with a web browser which could run a web interface to create and/or administrate OrBAC policies.

Conclusion

In this article we showed that the expressivity of MotOrBAC can be easily used by system administrators to specify dynamic security policies and administrate them. The tool implements the OrBAC access control model and features (1) a security model based on organizational entities (organization, role, activity, view, context), (2) an explicit separation between the organizational level and the concrete level (subject, action, object), (3) the possibility to model permissions, prohibitions and obligations, (4) a simulation and analysis tool, (5) a policy conict detection tool along with resolution strategies, (6) a decentralized policy administration.

The administrator can directly specify a policy with MotOrBAC from its expression in the OrBAC model. The GUI is structured around the organization tree control to allow the administrator to easily specify the abstract policy. The concrete entities are specied using an object-oriented approach. The policy is internally represented as a RDF graph to which the administrator has no direct access, all the editing operation being done through the GUI. The underlying RDF graph can be saved as an XML le or as a N-Triple5 le so the policy can be easily read by other applications. The policy administration, which is known to be a very complicated task, is included in MotOrBAC. Using the OrBAC concept of view and object, administrative privileges are specied by inserting administrative objects into specic views. This model being self-administrated, specifying the administration policy is done using the same concepts involved in the specication of the security policy, which does not require the administrator to learn a separate administration model. Moreover several administrators can use MotOrBAC to manage the same security policy with more expressiveness than the ARBAC model. The privileges given to a subject assigned to an administrative role are activated once the subject has authenticated himself/herself using the GUI.

The security policy enforcement can be done by translating the concrete security policy to other languages used to congure security components. The work did in [START_REF] Cuppens | A formal approach to specify and deploy a network security policy[END_REF] to translate a concrete security policy to a rewall conguration le has been implemented in MotOrBAC.

The problem of delegation [START_REF] Ben Ghorbel | Managing delegation in access control models[END_REF] was not tackled in this article as it is currently under implementation in MotOrBAC.

Several extensions to the current MotOrBAC implementation are currently under development, namely other types of contexts [START_REF] Cuppens | Modelling contexts in the Or-BAC model[END_REF], additional policy translation modules to congures other kinds of security components than rewalls, an interoperability module, a management and inforcement of obligations module and a module implementing usage control.

Fig. 1 :

 1 Fig. 1: The MotOrBAC tool architecture which is based on the java OrBAC API

Fig. 2 :

 2 Fig. 2: The MotOrBAC class editor

Fig. 4 :

 4 Fig. 4: The MotOrBAC concrete policy simulation window

Fig. 6 :

 6 Fig. 6: Abstract conicts tab. Each couple of conicting rules is displayed. The contextual menu shows the choices the administrator has to solve the conict

  Context is a context in organization Sorg and (6) Role is permitted to do Activity on V iew when Context is valid in organization Org, then the permission is also true in organization Sorg.

	permission(Sorg, Role, Activity, V iew, Context) : -
	sub_organization(Sorg, Org),
	use(Sorg, Role, role_view),
	use(Sorg, Activity, activity_view),
	use(Sorg, V iew, view_view),
	use(Sorg, Context, context_view),
	permission(Org, Role, Activity, V iew, Context).
	This rule states that if a (1) Sorg is a sub-organization of Org, (2) Role is a role
	in organization Sorg, (3) Activity is an activity in organization Sorg, (4) V iew is
	a view in organization Sorg, (5)

• Context denition inheritance: Let org and subOrg be two organizations, subOrg being a sub-organization of org, ctx a context and ctx_def _org its denition in organization org. subOrg inherits the denition ctx_def _org if no denition exists for context ctx in subOrg.

Note that Motorbac users do not have to write such rules thanks to the GUI

http://motorbac.sourceforge.net

http://jena.sourceforge.net/

The full specication of the OrBAC API can be found on http://orbac.org

http://www.w3.org/TR/rdf-testcases/