# X-rays from a Central “Exhaust Vent” of the Galactic Center Chimney

Scott C. Mackey Department of Physics & Kavli Institute for Cosmological
Physics, University of Chicago, Chicago, IL 60637, USA  Department of Physics
and Astronomy, University of California, Los Angeles, CA 90095, USA  Mark R.
Morris Department of Physics and Astronomy, University of California, Los
Angeles, CA 90095, USA  Gabriele Ponti  INAF Osservatorio Astronomico di
Brera, Via Bianchi 46, I-23807 Merate (LC), Italy  Max-Planck-Institut für
extraterrestrische Physik, D-85748 Garching, Germany  Konstantina
Anastasopoulou  INAF Osservatorio Astronomico di Palermo, Piazza del
Parlamento 1, I-90134 Palermo, Italy  Samaresh Mondal  INAF Osservatorio
Astronomico di Brera, Via Bianchi 46, I-23807 Merate (LC), Italy

(Received 2023 September 29)

###### Abstract

Using deep archival observations from the Chandra X-ray Observatory, we
present an analysis of linear X-ray-emitting features located within the
southern portion of the Galactic center chimney, and oriented orthogonal to
the Galactic plane, centered at coordinates
$l=0.08^{\circ},~{}b=-1.42^{\circ}$. The surface brightness and hardness ratio
patterns are suggestive of a cylindrical morphology which may have been
produced by a plasma outflow channel extending from the Galactic center. Our
fits of the feature’s spectra favor a complex two-component model consisting
of thermal and recombining plasma components, possibly a sign of shock
compression or heating of the interstellar medium by outflowing material.
Assuming a recombining plasma scenario, we further estimate the cooling
timescale of this plasma to be on the order of a few hundred to thousands of
years, leading us to speculate that a sequence of accretion events onto the
Galactic Black Hole may be a plausible quasi-continuous energy source to
sustain the observed morphology.

††journal: ApJ

##  1 Introduction

Recent large-scale surveys of the Galactic center have revealed that the X-ray
and radio emission on scales of several hundred parsecs assumes a bipolar
morphology centered on the Galactic center, with the well-defined emitting
lobes oriented perpendicular to the Galactic plane (Ponti et al., 2019, 2021;
Heywood et al., 2019). These findings had been presaged by a considerable
amount of earlier work over several decades on the “Galactic Center Lobe” seen
at northern galactic latitudes at radio wavelengths (Sofue & Handa, 1984;
Sofue, 1985; Law, 2010) and by X-ray observations of features extending to
latitudes well out of the Galactic plane (Nakashima et al., 2013; Ponti et
al., 2015). The interpretation of the morphology by Ponti et al. (2021) is
that the lobes are bubbles of hot plasma surrounded by a radio-emitting shell
of denser ionized gas. Ponti et al. (2019) hypothesized that these bubbles are
essentially “chimneys” along which hot plasma is moving vertically out of the
Galactic center where the plasma was produced, and into the region of the
galaxy-scale Fermi gamma-ray bubbles (Su et al., 2010; Yang et al., 2018,
2022) and the even larger X-ray bubbles detected by the eRosita X-ray
observatory (Predehl et al., 2020). The chimneys could thereby be the channels
by which sources in the Galactic center have provided the energy and particles
to feed the Fermi and eRosita bubbles. However, evidence for actual motion of
plasma along the chimneys has not yet been reported, and it remains unclear
whether the galaxy-scale bubbles are fed primarily by relativistic particles,
i.e., cosmic rays, diffusing up from the region of massive star formation near
the Galactic plane, or by a hot, outflowing plasma driven either by extreme
episodes of accretion onto the Galactic Black Hole or by the collective
deposition of energy by many supernovae over time (Zubovas et al., 2011;
Zubovas & Nayakshin, 2012; Crocker & Aharonian, 2011; Crocker et al., 2015;
Zhang et al., 2021).

Whatever the mechanisms for producing the large-scale bubbles might be, the
energy generated in the central few hundred parsecs of the Galaxy by accretion
onto the central supermassive black hole and by supernovae and stellar winds
associated with recent star formation has clearly created a Galactic wind
(Crocker et al., 2010; Carretti et al., 2013; McClure-Griffiths et al., 2013;
Fox et al., 2015; Ashley et al., 2020; Lockman et al., 2020). The driving
mechanism for the wind from the Galactic center is likely tied to the
mechanisms producing the Fermi and eRosita Bubbles. The wind launches material
into the active circumgalactic medium, the arena of the Galactic fountain
(Tumlinson et al., 2017).

This paper presents an investigation of diffuse, extended X-ray emission from
a single archival Chandra field that contains structures that appear
morphologically to constitute the central vent in the southern Galactic center
chimney, as shown in Figure 1. Observations and characteristics of this
particularly deep field are described in section 2, while the resulting
morphology of the emitting structures and a spectroscopic investigation of
those structures are presented in section 3. Finally, our interpretation of
the observational results is given and discussed in section 4.

Figure 1: 1.5-2.6 keV Chandra map of the Galactic center in Galactic
coordinates, showing the chimneys. A 0.5-2.0 keV image of the Inner Bulge Deep
Field is overlaid in the right panel and highlighted with blue dashed lines.
The black dot in the left panel denotes the location of Sgr A*.

##  2 Observations and Data Preparation

For this study, we focus on a $\sim 17\times 17$ arcmin field located at
$l=0.08^{\circ},~{}b=-1.42^{\circ}$, which we refer to as the Inner Bulge Deep
Field (IBDF) (Figure 2). A total of 13 archival Chandra observations cover the
field with a combined integration time of nearly 1 Ms (Table 1). The majority
of the observations were conducted by Revnivtsev et al. (2009) in 2008 to
characterize the discrete point sources that are part of the Galactic ridge
X-ray emission (GRXE), a continuous unresolved hard X-ray emission feature
extending along the Galactic plane to longitudes of $\pm\sim 40^{\circ}$
(Worrall et al., 1982; Warwick et al., 1985). In addition, three of the
observations were made in 2005 as part of the ChaMPlane Galactic bulge survey
(van den Berg et al., 2009). All data were taken with the imaging array of the
Advanced CCD Imaging Spectrometer (ACIS-I) onboard the Chandra X-ray
Observatory. Data were downloaded from the Chandra Data Archive and
reprocessed using the standard procedure for the Chandra Interactive Analysis
of Observations (CIAO)111https://cxc.harvard.edu/ciao/ software package
(version 4.13, CALDB 4.9.5), starting with the chandra_repro script.

Interpreting diffuse X-ray emission requires a thorough treatment of the non-
X-ray instrumental background. We used the ACIS-I stowed background data set
and re-scaled it by assuming that nearly all of the 9-12 keV flux is due to
particle background, using a method based on the one prescribed by Hickox &
Markevitch (2006). Our method differs slightly from the background subtraction
techniques previously used in similar analyses and is detailed in Appendix A.
After subtracting this background from each observation, we combined and
exposure-corrected all observations to produce a mosaic image. Since the roll
angles vary among the various observations, the images do not always align
well, which results in a few regions where there is little or no overlap with
the bulk of the observations and therefore drastically lower exposure times.
We addressed this by simply masking such regions out of the image. To remove
point sources, we identified them using CIAO’s wavdetect routine with a
sensitivity threshold (i.e. tolerance of falsely identifying a pixel as
belonging to a source) of $1\times 10^{-6}$ and then excised and interpolated
across the source regions using dmfilth. Finally, the image was smoothed using
a constant Gaussian kernel with a radius of 6 pixels (3 arcsec).

Spectra were produced using specextract and then fit using the XSPEC
222https://heasarc.gsfc.nasa.gov/xanadu/xspec/ software package (Arnaud,
1996). Because the X-ray features studied here are dominated by emission below
2 keV and the diffuse cosmic X-ray background is best accounted for up to
about 4 keV (Hickox & Markevitch, 2006, 2007), we limit all of our spectral
analyses to energies below 3 keV. Instrumental background was subtracted from
the spectra before fitting, and spectra were rescaled based on area. We find
that the fits show little dependence on elemental abundances, so we fix this
to solar abundance. The abundance table provided by Anders & Grevesse (1989)
was assumed. We represent a thermal plasma with the apec (Astrophysical Plasma
Emission Code; hereafter ‘APEC’) model and a non-equilibrium recombining
plasma with the rnei (hereafter ‘RP’) model. Both models are default models
within the XSPEC software package.

Table 1: Observations ObsID | Date | Exposure
---|---|---
| (yyyy-mm-dd) | (ks)
5934 | 2005-08-22 | 40.49
6362 | 2005-08-19 | 37.70
6365 | 2005-10-25 | 20.69
9500 | 2008-07-20 | 162.56
9501 | 2008-07-23 | 131.01
9502 | 2008-07-17 | 164.12
9503 | 2008-07-28 | 102.31
9504 | 2008-08-02 | 125.42
9505 | 2008-05-07 | 10.73
9854 | 2008-07-27 | 22.77
9855 | 2008-05-08 | 55.94
9892 | 2008-07-31 | 65.79
9893 | 2008-08-01 | 42.16
Figure 2: 0.5-2 keV Chandra map of the IBDF. Galactic coordinates are shown in
degrees.

##  3 Results

###  3.1 Morphology

The features of interest within the IBDF are bright, linear ridges of X-ray
emission oriented roughly perpendicular to the Galactic plane. They are
characterized by relatively soft X-rays and do not appear outside of the
0.5-2.0 keV band. We visually define seven regions across the IBDF field
denoted by Greek letters $\alpha$ through $\eta$ going from positive to
negative Galactic longitudes (Figure 3).

Figure 3: IBDF regions used for analysis. Galactic coordinates shown.

Feature $\beta$ is a narrow, bright ridge that runs parallel to lines of
constant Galactic longitude and points toward the Sagittarius A complex at the
Galactic center. Features $\gamma$, $\delta$, and $\epsilon$ are parallel to
$\beta$, and while they are noticeably dimmer than $\beta$, they are regularly
spaced in longitude and alternate in surface brightness, proceeding from
$\beta$ to $\zeta$, so that feature $\delta$, situated at the center of the
seven regions, appears brighter than the regions on either side of it. Regions
$\zeta$ and $\eta$ combine into a distinct feature of notable complexity, as
can best be seen in Figure 3. Its orientation is tilted with respect to that
of the other parallel features by a small angle ($\sim 15^{\circ}$) and it
features a brighter component ($\zeta$) on its eastern side bordering
$\epsilon$ and a dimmer component ($\eta$) on its western side.

The IBDF X-ray features are located within the southern Galactic chimney,
which itself is nestled within the southern radio lobe (Ponti et al., 2019,
2021; Heywood et al., 2019), as shown in Figure 4. As was noted by Ponti et
al. (2021), the radio emission arises from the periphery of the southern X-ray
chimney, which evokes a structure in which the X-rays arise from a confined
hot plasma, while the radio emission arises in a thick, higher-density
surrounding shell where the hot plasma interacts with the ambient interstellar
medium and the predominantly vertical magnetic field of the Galactic center.

Figure 4: Multi-wavelength image of the southern radio lobe and chimney. The
IBDF X-ray features are shown in green (creating yellow in the left panel when
mixed with red; 0.5-2.0 keV), the chimney diffuse X-ray emission is shown in
red (1.5-2.6 keV), and the 1.284 GHz MeerKAT radio map is shown in blue.
Emission from the chimney is omitted from the right panel to show the
distribution of radio emission within the IBDF X-ray features. Figure 5:
Hardness ratio of 1.2-2.0 keV to 0.5-1.2 keV emission.

###  3.2 Hardness Ratios

The hardness ratio comparing the 1.2-2.0 keV band to the 0.5-1.2 keV band
across the field is shown in Figure 5. We define the hardness ratio as

$\mathrm{Hardness\
Ratio}=\frac{C_{\mathrm{high}}-C_{\mathrm{low}}}{C_{\mathrm{high}}+C_{\mathrm{low}}}$
(1)

where $C_{\mathrm{high}}$ and $C_{\mathrm{low}}$ are the counts in the higher
and lower energy bands, respectively, and a higher hardness ratio indicates
harder emission. The error bars for latitude and longitude represent the
uniform 0.01 degree-wide segments over which the counts were summed, while the
hardness ratio error comes from the statistical error of the observed counts
in these segments. Progressing across the field in Galactic longitude, the
brighter linear features $\beta$, $\delta$, and $\zeta$ each roughly
correspond to lower hardness ratios, while the overall minimum hardness ratio
occurs in region $\alpha$. In the progression with Galactic latitudes, the
hardness ratio shows a broad minimum at the bright centers of the IBDF, with a
small peak at $b=-1.448\pm 0.005$ degrees and a broad minimum at $b=-1.469\pm
0.005$ degrees. Panel C in Figure 5 demonstrates differences in X-ray hardness
within the $\zeta$/$\eta$ feature, with the softer eastern edge corresponding
to the bright ridge seen in Figure 2, and relatively hard emission trailing
off to the west.

###  3.3 Spectra

The spectra from the five regions were fit simultaneously to determine the
most likely physical model and set of parameters for each region (Table 2).
When fitting the data, we find that there is little variation in the
recombination timescale $\tau$ and the initial recombining plasma temperature
across the seven regions, and we therefore link the regions together for these
parameters. We also fix the metal abundance to 1.0 in Solar units. We evaluate
the goodness-of-fit using the reduced chi-squared value (i.e.,
$\chi^{2}/\mathrm{degrees\ of\ freedom}$), where a lower value of
$\chi^{2}/\mathrm{d.o.f.}$ indicates a better fit. For each region, the model
with the lowest $\chi^{2}/\mathrm{d.o.f.}$ consists of a combination of RP and
APEC components, each convolved with a Tuebingen-Boulder ISM grain absorption
model (‘TBabs’; Wilms et al. 2000), i.e. tbabs*(rnei+apec). This model yields
a $\chi^{2}/\mathrm{d.o.f.}$ value of 1160/1062 = 1.092, which is
significantly better than the other attempted models, such as a double APEC
model (1921/1064 = 1.805). A comparison of the spectra for features $\beta$,
$\delta$, and $\zeta$ fit using the RP+APEC model is shown in Figure 6.

Table 2: Simultaneous Fit  Parameter | $\alpha$ | $\beta$ | $\gamma$ | $\delta$ | $\epsilon$ | $\zeta$ | $\eta$
---|---|---|---|---|---|---|---
nH ($10^{22}\ \mathrm{cm}^{-2}$) | 0.79 ±0.04 | 0.86 ±0.04 | 0.92 ±0.07 | 0.75 ±0.07 | 0.95 ±0.04 | 0.92 ±0.03 | 0.93 ±0.03
RP kTinit (keV) |  $0.35\pm 0.01$ $\mathrm{(linked)}$
RP kT (keV) | 0.183 ±0.009 | 0.18 ±0.01 | 0.20 ±0.02 | 0.19 ±0.01 | 0.24 ±0.02 | 0.148 ±0.009 | 0.15 ±0.01
RP $\boldsymbol{\tau}$ ($10^{10}$ s $\mathrm{cm}^{-3}$) |  $9\pm 3$ $\mathrm{(linked)}$
APEC kT (keV) | 2.4 ±0.4 | 2.8 ±0.8 | 1.8 ±0.4 | 2.8 ±0.8 | 1.05 ±0.06 | 1.22 ±0.09 | 1.49 ±0.08
APEC EM ($10^{52}\ \mathrm{cm}^{-3}$) | 0.31 ±0.02 | 0.36 ±0.03 | 0.27 ±0.04 | 0.31 ±0.03 | 0.42 ±0.05 | 0.60 ±0.06 | 0.94 ±0.05
RP EM ($10^{52}\ \mathrm{cm}^{-3}$) | 8.9 ±0.8 | 12 ±1 | 7 ±1 | 6 ±1 | 3.9 ±0.9 | 35 ±3 | 25 ±2
Figure 6: Spectral data from relatively bright ridges $\zeta$ (top), $\beta$
(middle), and $\delta$ (bottom) rescaled to account for differences in area.

##  4 Interpretations and Discussion

###  4.1 Hypothesis: a Cylindrical Tunnel

The IBDF feature contains two prominent bright ridges, regions $\beta$ and
$\zeta$, which border a column of relatively low X-ray surface brightness
(regions $\gamma$, $\delta$, and $\epsilon$). The linear morphology of these
quasi-parallel ridges, coupled with the fact that ridge $\beta$ has a sharp
western edge, but falls off less abruptly toward the east into region
$\alpha$, leads us to hypothesize that the IBDF feature is a cylindrical,
edge-brightened tunnel lying along the central axis of the southern chimney.
In keeping with the notion that the chimneys represent collimated plasma
outflows from the Galactic center (Ponti et al., 2019), we regard this tunnel
as the channel, or vent, along which the outflowing plasma is moving. While no
measurement yet exists of the outflowing plasma velocity within the putative
tunnel, we argue that it must be at least as large as the velocity of the wind
emanating from the overall Galactic center region, $\gtrsim 1000$ km s-1
(Carretti et al., 2013; Fox et al., 2015; Fujita, 2023). We assume that the
outflow velocity of the plasma is highest along the central axis of the tunnel
because the flow along the edges would be somewhat slowed by turbulent
interactions with the adjacent ambient medium. The relatively low X-ray
brightness of the interior of the tunnel can then be attributed to a lower
plasma density there via the continuity equation, coupled with the density-
squared dependence of the X-ray emissivity of the plasma.

The relatively high emissivity of the tunnel walls, manifested as the ridges
$\beta$ and $\zeta$, can be attributed to shocks that occur where the
outflowing plasma impacts and compresses the surrounding ambient gas. The
particularly high brightness of ridge $\zeta$ is readily attributable to its
orientation; it is slightly askew relative to the axis of the tunnel, so the
outflowing plasma strikes this portion of the tunnel wall at a more direct
angle, and therefore with more force, than it does elsewhere where the
velocity vector of the outflowing plasma is presumably almost parallel to the
walls of the tunnel.

We note that the detailed morphology of the tunnel appears to be somewhat more
complex than a perfectly uniform cylinder, given the presence of a fainter
ridge, $\delta$, projected near the center of the tunnel.

###  4.2 Hardness Ratio and Plasma Temperature Distribution

The brightest regions in the IBDF coincide with the smallest hardness ratios
when comparing 1.2-2.0 keV and 0.5-1.2 keV emission. If the IBDF feature is
indeed attributable to shocks propagating into the ambient medium, then this
shock compression of the “tunnel walls” (i.e. $\beta$ and $\zeta$) would
naturally lead to higher densities. This high density would in turn give rise
to greater emissivity and therefore more rapid cooling, ultimately producing
the bright but soft X-ray emission that we observe. A plausible candidate for
energy injection into this region is the series of “hundred-year events” that
have been inferred from moving X-ray echoes observed primarily in the
fluorescent 6.4 keV iron line (Ponti et al., 2010; Clavel et al., 2013; Ponti
et al., 2013; Churazov et al., 2017; Chuard et al., 2018; Marin et al., 2023).
If the cooling time of the IBDF plasma is greater than a few hundred years,
then this sequence of hundred-year events, presuming that they occur with some
regularity on few-hundred-year timescales, may effectively act as a continuous
flow that continually replenishes the region.

Using the fit parameters for density and temperature from Table 2, we can
estimate the cooling timescale of the shocked plasma for comparison to this
few-hundred-year timescale. The characteristic cooling timescale of the plasma
can be calculated using the thermal energy and emitted power of the plasma via
the relation

$\tau_{\mathrm{cool}}=\frac{\frac{3}{2}\left(1+\frac{n_{\mathrm{i}}}{n_{\mathrm{e}}}\right)kT}{\Lambda(t)n_{\mathrm{H}}}.$
(2)

Here $\Lambda(t)$ is the cooling function, which in this case essentially
amounts to bolometric power normalized by emission measure. Using cooling
curves provided by Sutherland & Dopita (1993), we estimate $\Lambda(t)\sim
5\times 10^{-30}\ \mathrm{W\ cm}^{3}$ based on temperature and approximate
metal abundance. Then assuming $n_{\mathrm{e}}=n_{\mathrm{i}}=n_{\mathrm{H}}$,
we can estimate the cooling timescale for various possible geometries. To get
a lower limit, we first assume that emission is confined to a volume whose
depth is equal to its angular width so that the dimensions of region $\beta$
are $0.1^{\circ}\times 0.01^{\circ}\times 0.01^{\circ}$, giving us an
estimated cooling timescale in this region of $\gtrsim 200$ yr. This estimate
assumes a filamentary feature in the simplest possible case. If, however, we
are looking at a cylindrical tunnel with a diameter of about $0.1^{\circ}$,
then the depth of region $\beta$ is represented by a chord on that cylinder
lying approximately $0.025^{\circ}$ from the center. Thus, the depth is $\sim
0.087^{\circ}$, and we calculate an estimated cooling timescale of $\gtrsim
2000$ yr.

To maintain the observed structure, the non-equilibrium plasma of the IBDF
must be continually replenished or heated on a timescale shorter than this
cooling time, and the Sgr A∗ hundred-year events therefore provide a plausible
mechanism for sustaining the heating and outflow of the IBDF plasma and
counteracting this relatively short cooling timescale.

###  4.3 Recombining Plasma

Nakashima et al. (2013) report Suzaku results indicating the presence of a
recombining plasma south of the Galactic plane in a larger region that
contains the IBDF. Our spectral analysis of the IBDF is indeed consistent with
this result as a model containing a recombining plasma and a thermal APEC
component produced acceptable fits with the lowest $\chi^{2}$ values. We find
that no single-plasma model alone is able to sufficiently fit the data, which
leads us to introduce the additional APEC component in our RP+APEC and
APEC+APEC models. The improvement to the fit afforded by the additional APEC
component to the RP model suggests that there may be an associated thermalized
plasma mixed in with or adjacent to the bulk recombining plasma, or that the
plasma may have a more-or-less continuous distribution of temperatures.
Comparing the temperatures in Table 2, we see that the APEC component is at a
higher temperature than the RP component for all 7 of the sub-regions in the
fit. This may be an indication that the plasma responsible for the observed
bright features is distinct from another plasma component sitting within or
moving through the tunnel, or that the plasma of the IBDF has a highly
variable temperature distribution. Further spectral analysis of the IBDF will
be required to provide a more accurate picture. Follow-up high-resolution
spectroscopy with XRISM may be especially helpful in this effort.

The presence of a recombining plasma in the IBDF is also consistent with the
Galactic outflow hypothesis. The morphology of the IBDF features, along with
the trends in hardness ratio, suggest the existence of shocks in the region.
Strong shocks stemming from the outflow would propagate into the ambient
interstellar medium at high velocity, compacting the gas and sustaining the
recombining plasma environment.

###  4.4 Relationship to Smaller- and Larger-Scale Features

A number of features observed on different scales merit consideration as
possibly being related to the X-ray features in the IBDF. As mentioned above,
the X-ray chimneys, in which the IBDF is embedded, have been invoked as the
channel through which plasma and cosmic rays generated in the vicinity of the
Galactic center transit out to the Galactic halo, potentially provoking the
$\gamma$\- and X-ray emission arising in the large-scale Fermi and eRosita
Bubbles (Ponti et al., 2019, 2021).

We also note that on the scale of a few parsecs, a linear X-ray feature close
to the Galactic black hole has been identified and interpreted as a jet from
the black hole (Baganoff et al., 2003; Muno et al., 2008; Li et al., 2013; Zhu
et al., 2019). That putative jet is oriented in the same direction as the
southern chimney and the linear features in the IBDF, but it has not been
detected at distances exceeding a few parsecs from the black hole, apparently
because its nonthermally-emitting particles have lost sufficient energy beyond
that point to continue emitting a detectable flux of X-rays (Zhu et al.,
2019). However, at very low radio frequencies, Yusef-Zadeh et al. (1986) (see
also Kassim et al., 1986) reported the presence of a ridge of radio continuum
emission extending from the Galactic center out to a distance of about 25 pc
normal to the Galactic plane, that is, in the same direction as the
hypothetical X-ray jet, but far short of the 220 pc distance of the IBDF from
the Galactic black hole. Continued energy loss by the electrons in the
hypothetical jet could lead to a fossil jet of low-energy particles
responsible for the observed low-frequency synchrotron emission. Eventually,
if those particles are moving through the plasma in the chimney, they will
thermalize with the plasma, and thus have no observable excess manifestation
of their presence at the distance of the IBDF.

While the placement and morphology of all the features mentioned here are very
suggestive, further investigation is clearly needed to establish and elucidate
the physical links between them.

##  5 Summary

The 1 Ms Chandra field centered at $l=0.08^{\circ},~{}b=-1.42^{\circ}$
contains a bright X-ray structure having a striated linear morphology and
hardness ratio trends suggestive of a cylindrical tunnel. The linear strands
of X-ray emission are approximately perpendicular to the Galactic plane and
sit neatly within the diffuse emission of the southern Galactic Center
chimney, which is itself situated inside a wider shell of radio emission.
Because the roughly cylindrical chimney is centered on the Galactic black
hole, the natural hypothesis for the overall structure is that an X-ray
emitting plasma generated at or in a broad region within $\sim$100 pc of the
black hole is flowing out of central region through the chimney, and we
hypothesize that the apparent tunnel that we report here is the central
conduit for that plasma. While our spectral analysis of the linear X-ray
features does not conclusively constrain the metallicity or show an obvious
trend in temperature, it does point toward the presence of a two-temperature
plasma. Such a plasma consisting of a thermal and a recombining component
could be sustained from shocks due to the continuous outflow proposed in the
chimney hypothesis. The inferred tunnel-like morphology is best supported by
the X-ray hardness ratios, which demonstrate a clear difference between the
brighter “walls” of the tunnel and the dimmer region in-between. The bright
outer regions coincide with the lowest hardness ratios, a possible indicator
of higher density and more rapid cooling as a result of shock compression from
outflowing plasma.

The presumably outflowing plasma in the tunnel is a strong candidate for the
source of the Galactic wind, and perhaps for providing the particles and
energy that are responsible for the gamma-rays emanating from the Fermi
Bubbles and the X-rays arising in the eRosita Bubbles. The biggest remaining
open question is whether those galaxy-scale structures were created
predominantly in a past major black-hole accretion event or whether they are
the result of a sequence of frequent episodic energy releases within the
Galaxy’s central region. In the latter case, the observed plasma structures –
chimneys and tunnel – are enduring features that carry the intermittent spurts
of energy out to the large-scale bubbles.

One very useful future investigation would be to determine the plasma velocity
(and gradient) within the chimneys, either by carrying out long-term X-ray
proper motion studies or by measuring the Doppler shifts of X-ray lines with a
high-resolution X-ray spectrometer. The challenge with the former measurement
is the limited resolution of X-ray imagers (with Chandra resolution, it would
take about a decade to make a proper motion measurement of an unresolved
feature moving at 1000 km s-1 at the Galactic center, and the features
reported here are partially resolved), while the challenge with the latter
measurement is that the predominant direction of the plasma flow is likely to
be perpendicular to our line of sight.

Acknowledgements: The work carried out for this project by UCLA participants
was supported by NASA/SAO grant GO1-22138X. GP acknowledges financial support
from the European Research Council (ERC) under the European Union’s Horizon
2020 research and innovation program “HotMilk” (grant agreement No. 865637)
and support from Bando per il Finanziamento della Ricerca Fondamentale 2022
dell’Istituto Nazionale di Astrofisica (INAF): GO Large program.

## References

  * Anders & Grevesse (1989) Anders, E., & Grevesse, N. 1989, Geochim. Cosmochim. Acta, 53, 197, doi: 10.1016/0016-7037(89)90286-X
  * Arnaud (1996) Arnaud, K. A. 1996, in Astronomical Society of the Pacific Conference Series, Vol. 101, Astronomical Data Analysis Software and Systems V, ed. G. H. Jacoby & J. Barnes, 17
  * Ashley et al. (2020) Ashley, T., Fox, A. J., Jenkins, E. B., et al. 2020, ApJ, 898, 128, doi: 10.3847/1538-4357/ab9ff8
  * Baganoff et al. (2003) Baganoff, F. K., Maeda, Y., Morris, M., et al. 2003, ApJ, 591, 891
  * Carretti et al. (2013) Carretti, E., Crocker, R. M., Staveley-Smith, L., et al. 2013, Nature, 493, 66
  * Chuard et al. (2018) Chuard, D., Terrier, R., Goldwurm, A., et al. 2018, A&A, 610, A34
  * Churazov et al. (2017) Churazov, E., Khabibullin, I., Sunyaev, R., & Ponti, G. 2017, MNRAS, 465, 45
  * Clavel et al. (2013) Clavel, M., Terrier, R., Goldwurm, A., et al. 2013, A&A, 558, A32
  * Crocker & Aharonian (2011) Crocker, R. M., & Aharonian, F. 2011, Physical Review Letters, 106, 101102
  * Crocker et al. (2015) Crocker, R. M., Bicknell, G. V., Taylor, A. M., & Carretti, E. 2015, ApJ, 808, 107
  * Crocker et al. (2010) Crocker, R. M., Jones, D. I., Aharonian, F., et al. 2010, ArXiv e-prints
  * Fox et al. (2015) Fox, A. J., Bordoloi, R., Savage, B. D., et al. 2015, ApJ, 799, L7, doi: 10.1088/2041-8205/799/1/L7
  * Fujita (2023) Fujita, Y. 2023, MNRAS, 518, 4551
  * Heywood et al. (2019) Heywood, I., Camilo, F., Cotton, W. D., et al. 2019, Nature, 573, 235
  * Hickox & Markevitch (2006) Hickox, R. C., & Markevitch, M. 2006, ApJ, 645, 95
  * Hickox & Markevitch (2007) —. 2007, ApJ, 661, L117, doi: 10.1086/519003
  * Kassim et al. (1986) Kassim, N. E., Larosa, T. N., & Erickson, W. C. 1986, Nature, 322, 522
  * Law (2010) Law, C. J. 2010, ApJ, 708, 474
  * Li et al. (2013) Li, Z., Morris, M. R., & Baganoff, F. K. 2013, ApJ, 779, 154
  * Lockman et al. (2020) Lockman, F. J., Di Teodoro, E. M., & McClure-Griffiths, N. M. 2020, ApJ, 888, 51
  * Marin et al. (2023) Marin, F., Churazov, E., Khabibullin, I., et al. 2023, Nature, 619, 41, doi: 10.1038/s41586-023-06064-x
  * McClure-Griffiths et al. (2013) McClure-Griffiths, N. M., Green, J. A., Hill, A. S., et al. 2013, ApJ, 770, L4
  * Muno et al. (2008) Muno, M. P., Baganoff, F. K., Brandt, W. N., Morris, M. R., & Starck, J.-L. 2008, ApJ, 673, 251
  * Nakashima et al. (2013) Nakashima, S., Nobukawa, M., Uchida, H., et al. 2013, ApJ, 773, 20
  * Ponti et al. (2021) Ponti, G., Morris, M. R., Churazov, E., Heywood, I., & Fender, R. P. 2021, A&A, 646, A66
  * Ponti et al. (2013) Ponti, G., Morris, M. R., Terrier, R., & Goldwurm, A. 2013, in Astrophysics and Space Science Proceedings, Vol. 34, Cosmic Rays in Star-Forming Environments, ed. D. F. Torres & O. Reimer, 331, doi: 10.1007/978-3-642-35410-6_26
  * Ponti et al. (2010) Ponti, G., Terrier, R., Goldwurm, A., Belanger, G., & Trap, G. 2010, ApJ, 714, 732
  * Ponti et al. (2015) Ponti, G., Morris, M. R., Terrier, R., et al. 2015, MNRAS, 453, 172
  * Ponti et al. (2019) Ponti, G., Hofmann, F., Churazov, E., et al. 2019, Nature, 567, 347
  * Predehl et al. (2020) Predehl, P., Sunyaev, R. A., Becker, W., et al. 2020, Nature, 588, 227
  * Revnivtsev et al. (2009) Revnivtsev, M., Sazonov, S., Churazov, E., et al. 2009, Nature, 458, 1142
  * Sofue (1985) Sofue, Y. 1985, PASJ, 37, 697
  * Sofue & Handa (1984) Sofue, Y., & Handa, T. 1984, Nature, 310, 568
  * Su et al. (2010) Su, M., Slatyer, T. R., & Finkbeiner, D. P. 2010, ApJ, 724, 1044
  * Sutherland & Dopita (1993) Sutherland, R. S., & Dopita, M. A. 1993, ApJS, 88, 253, doi: 10.1086/191823
  * Tumlinson et al. (2017) Tumlinson, J., Peeples, M. S., & Werk, J. K. 2017, ARA&A, 55, 389, doi: 10.1146/annurev-astro-091916-055240
  * van den Berg et al. (2009) van den Berg, M., Hong, J. S., & Grindlay, J. E. 2009, ApJ, 700, 1702
  * Warwick et al. (1985) Warwick, R. S., Turner, M. J. L., Watson, M. G., & Willingale, R. 1985, Nature, 317, 218
  * Wilms et al. (2000) Wilms, J., Allen, A., & McCray, R. 2000, ApJ, 542, 914, doi: 10.1086/317016
  * Worrall et al. (1982) Worrall, D. M., Marshall, F. E., Boldt, E. A., & Swank, J. H. 1982, ApJ, 255, 111
  * Yang et al. (2018) Yang, H. Y., Ruszkowski, M., & Zweibel, E. 2018, Galaxies, 6, 29
  * Yang et al. (2022) Yang, H. Y. K., Ruszkowski, M., & Zweibel, E. G. 2022, Nature Astronomy, 6, 584
  * Yusef-Zadeh et al. (1986) Yusef-Zadeh, F., Morris, M., Slee, O. B., & Nelson, G. J. 1986, ApJ, 300, L47
  * Zhang et al. (2021) Zhang, M., Li, Z., & Morris, M. R. 2021, ApJ, 913, 68
  * Zhu et al. (2019) Zhu, Z., Li, Z., Morris, M. R., Zhang, S., & Liu, S. 2019, ApJ, 875, 44
  * Zubovas et al. (2011) Zubovas, K., King, A. R., & Nayakshin, S. 2011, MNRAS, 415, L21
  * Zubovas & Nayakshin (2012) Zubovas, K., & Nayakshin, S. 2012, MNRAS, 424, 666

##  Appendix A Background

In order to study diffuse X-ray emission, the non-X-ray background from the
Chandra instruments must be removed from the data. This background is
primarily caused by cosmic ray impacts on the ACIS CCDs and nearby components,
and therefore is not affected by the optical elements of the telescope (Hickox
& Markevitch, 2006). To measure this background, several Chandra observations
have been made with ACIS in the stowed position to block out external X-rays
and ensure that any measured flux originates from within the telescope. We
downloaded these datasets from the Chandra
website333https://cxc.harvard.edu/contrib/maxim/acisbg/ and reprocessed them
according to the standard procedure used for the science data.

Because the effective area of ACIS for energies of 9-12 keV is nearly
negligible, we begin with the assumption that essentially all of the flux in
this band consists only of instrumental background. We therefore first
proceeded by assuming that the count rate in this band should be the same in
the background data as it is in the science data. Re-scaling the background
count rate to account for exposure time, we would then subtract the background
data from the science data. However, in doing this, we found that the count
rate becomes negative above 4 keV, which is indicative of an apparent over-
subtraction. Thus, we implemented a corrective re-scaling procedure. We began
by reducing the amplitude of the background data by a factor of 1.37. This
factor was determined by assuming that prominent 7.5 keV Ni K$\alpha$ and 9.7
keV Au L$\alpha$ lines in the spectra were entirely due to internal
instrumental emission, and then scaling the background such that these lines
vanish. Then, to ensure we had the optimal re-scaling factor, we chose a small
uniform region on the edge of the IBDF to fit with a simple thermal model and
then re-fit the region as we varied the background re-scaling factor. This
indicated that a factor of 1.31 from the original instrumental background data
was the scaling that provided the best fit, as determined using the same
criterion as in Section 3.3. We subsequently adopted this re-scaling factor
throughout the rest of our analysis.


# Towards a Security Stress-Test for Cloud Configurations ††thanks: This work
has received funding from the European Union under the H2020 grant 952647
(AssureMOSS).

1st Francesco Minna  Vrije Universiteit Amsterdam (NL)
<EMAIL_ADDRESS>2nd Fabio Massacci  University of Trento (IT)
Vrije Universiteit Amsterdam (NL)
<EMAIL_ADDRESS>3rd Katja Tuma  Vrije Universiteit Amsterdam (NL)
<EMAIL_ADDRESS>
###### Abstract

Securing cloud configurations is an elusive task, which is left up to system
administrators who have to base their decisions on “trial and error”
experimentations or by observing good practices (e.g., CIS Benchmarks). We
propose a knowledge, AND/OR, graphs approach to model cloud deployment
security objects and vulnerabilities. In this way, we can capture
relationships between configurations, permissions (e.g., CAP_SYS_ADMIN), and
security profiles (e.g., AppArmor and SecComp), as first-class citizens. Such
an approach allows us to suggest alternative and safer configurations, support
administrators in the study of what-if scenarios, and scale the analysis to
large scale deployments. We present an initial validation and illustrate the
approach with three real vulnerabilities from known sources.

###### Index Terms:

knowledge graph, AND/OR graphs, containers, security, microservices, cloud

##  I Introduction

Container engines and orchestration tools, such as Docker and Kubernetes,
abstract the complexity of the underlying technologies (e.g. Linux namespaces
and Control Groups). This power of abstraction reduces companies’ time to
market, by making it easier to deploy and share applications. Yet, it also
rises new security challenges. Indeed, it is hard to understand such hidden
complexity in a highly dynamic environment (44% of containers are executed for
less than five minutes [1]). Misconfiguration is the most prevalent
vulnerability in the cloud [2], 76% containers are running as root, and 75% of
containers are running with critical vulnerabilities [1] (§II).

Several tools exist for analyzing container deployments and for vulnerability
scanning. Yet, as we illustrate in the related section (§III), most
‘vulnerability scanners’ are actually simply checkers of bills of (software
materials). When actual configurations are checked (e.g. the Checkov tool)
they are checked against best practices (i.e. CIS Benchmarks). Such analysis
reports rules that are not met but cannot do a more sophisticated what-if
analysis of what can be changed while maintaining a satisfying secure
configuration.

To fill this gap, we propose to _use a knowledge graphs where objects,
permissions, capabilities and other security features (e.g. AppArmor for
Docker) are first class citizens_ of the model. To this end, we build such
knowledge graphs and contribute with search algorithms implemented in Python
and Neo4J (§IV) to identify vulnerabilities and their fixes (§V). Fig. 1 shows
the workflow steps of the stress-test on Docker containers, namely, (i)
building the knowledge graph from configuration files, (ii) enriching the
graph with known vulnerabilities, and (iii), testing and fixing the system by
interacting with the user.

Figure 1: The workflow of the stress-test methodology on Docker containers.

The idea is to construct with this methodology the equivalent of a stress-
test111“the stress test for banks is used to assess their resilience to
adverse economic and market developments and contributes to the assessment of
systemic risk” [3]. for cloud configuration. The methodology will allow
administrators to explore what-if scenarios whenever a new vulnerability is
discovered and better understand the trade-offs made between relaxing security
requirements and functionality loss.

We present an initial validation by illustrating the proposed approach in §VI
and discuss the results and future work in §VII. We present the concluding
remarks in§VIII.

##  II Simple Attack Scenarios

To illustrate the problem faced by administrators in charge of cloud
deployment, we describe two recent attack scenarios and their implications for
containers. In 2019, a researcher from Google posted on Twitter a proof of
concept (PoC) to escape from privileged Docker containers, by exploiting the
release_agent of control groups (cgroups) [4]. Listing 1 shows a possible
vulnerable configuration. This configuration adds system administrator
capabilities to the default root user of Docker and tells the system to avoid
a specific AppArmor Linux profile, a solution typically used to make sure
applications can more easily communicate across network sockets.

Listing 1: Vulnerable execution of the container taken from [4]

⬇

1 # On the host

2 docker run –rm -it –cap-add=SYS_ADMIN –security-opt apparmor=unconfined
ubuntu bash

By creating a new cgroup, enabling cgroups notifications on release, and
specifying the release_agent script to be executed (once all processes within
the same cgroup are killed) an attacker can execute code on the container’s
host.

There is no syntactic connection between the attack commands and the Docker
configuration in Listing 1 so that a _semantic signature_ of the Docker
configuration is needed.

To exploit this technique, a container must either run as privileged or with a
root user (by default on Docker), with CAP_SYS_ADMIN capability granted and
mount syscall allowed. By foiling any (or all) preconditions the attack will
fail. For example, one could just drop all capabilities (i.e. \--cap-drop
ALL). Yet this is hardly a side-effect free solution. By dropping the
unconfined AppArmor profile users will find themselves trapped with a lengthy
debugging of possible calls to network sockets of applications that don’t work
and each of which must be individually configured, debugged, and
profiled222https://ubuntu.com/server/docs/security-apparmor. Similarly, in
March 2022, a vulnerability affecting the Linux kernel leading to privilege
escalation was discovered, namely, CVE-2022-0492 [5]. Again, this
vulnerability exploits a vulnerable implementation of the release_agent binary
executed once all processes belonging to a cgroup are killed. For this
vulnerability to be exploitable, one must run a container as a root user (or
with the CAP_DAC_OVERRIDE capability), with mount and unshare syscalls
allowed; obviously, containers with more permissions (e.g. privileged or with
the CAP_SYS_ADMIN capability) are also affected. The key observation is that
if the configuration is changed the vulnerable binary can stay as it is
because the attack is no longer possible.

##  III Related Work

Access control and network security policies for cloud deployment are well
studied by providing either access control solutions [6, 7, 8, 9] or by
supporting the automated policy generation from given specifications [10, 6,
11]. Recent works also provide mechanisms for formal verification of
microservice deployments [12], or continuous assessment methodologies [13].
Yet, the automatic or even computer-aided exploration and validation of
configuration policies _as available in practical deployments_ (e.g.
combinations of Docker commands) and their subsequent testing, still remain
largely unexplored in the academic literature.

Microservice Attack Generation Ibrahim et al. [14] investigated (theoretical)
attacks on microservices by using vulnerabilities identified in a deployment
to build an attack graph of all possible attacks. Whether these attacks are
actually possible has not been tested. Also this analysis cannot be readily
translated to changes into a practical configuration (e.g. drop the
CAP_SYS_ADMIN option).

Security industrial tools offering different kinds of ‘vulnerability scans’
and ‘static analysis’ for cloud environments are also available on the market.
Yet, while they all ‘formally’ meet NIST definition of vulnerability scanning
(‘a technique used to identify hosts attributes and associated
vulnerabilities’ [15]) their actual operation is not what a security expert
would intuitively expect even from the classical nmap network scanner [16] and
even less of what one would expect from a static analyzer for software
security [17].

Configuration analyzers (e.g. snyk 333https://snyk.io/product/container-
vulnerability-management/ and Docker Bench
444https://github.com/docker/docker-bench-security) analyze configuration
files and settings and check them against common or custom security best
practices and policies (e.g. compliance with the CIS Benchmarks), some of
these tools only provide compliance tests.555E.g. terrascan by Accurics, built
on top of OPA, and Bridgecrew, which are open source, along with CIS-CAT Pro,
and Lacework which are commercial.

Vulnerability Scanners (e.g. Clair 666https://github.com/quay/clair and Trivy
777https://github.com/aquasecurity/trivy) typically retrieves a software bill
of material (SBOM) gathering all software packages used in an image or in
configuration files and compares them against vulnerabilities repositories
(e.g. NVD888https://nvd.nist.gov/ or Debian Security Bug
Tracker999https://security-tracker.debian.org/tracker/) to check if the
current version of a package in use is _reported to be_ vulnerable.

Such tools often generate false alerts as they are based on the same
overcautious vulnerability reporting that is well known in secure software
engineering for the analysis of vulnerabilities in open source libraries [18,
19].

Automatically suggesting a “fix” for a particular (cloud) misconfiguration is,
to this day, an open problem. All previous tools do not suggest or provide any
fix for detected vulnerabilities, leaving up to the end user the mitigation
process to eliminate the alerts. To this extent, we will use the Analytic
Hierarchy Process (AHP) [20], which has been used for decades by nearly all
decision making disciplines, including graph theory and requirements
engineering.

Knowledge graphs for cybersecurity. The use of graphs to investigate the
security properties of cloud environments have already been investigated in
the past. Yet, most existing approaches use knowledge graphs for security
awareness, and intelligence sharing [21, 22], rather then security analysis of
configurations. A comprehensive review can be found in [23].

The closest work is by Banse et al. [24] who build a Cloud Property Graph
(CloudPG) using both static code analysis and an ontology; similarly to our
idea, they propose an analysis framework to query the graph for security
issues but focuses on bridging the gap between static code analysis of the
application and its runtime environment. While the outcome is a sophisticated
analysis of data flow leaks, this approach requires full access to the
application code. Our approach complement this work by going in the opposite
direction towards the analysis of deployment information to suggest
alternative, safer, configurations.

##  IV Building the Graphs

The methodology for capturing and analyzing cloud containers configuration by
a knowledge graph where undirected edges and nodes are labeled to represent
the container system objects and their relationships.

Build the knowledge graph. We parse the configuration files to represent the
infrastructure on which the container engine is running (e.g. Ubuntu VM), the
container engine being used (e.g. Docker), the container image (e.g.
Dockerfile), and finally, the docker run options that will be used to run the
container (e.g. privileged, volume, and user) along with the security profiles
(e.g. AppArmor and Seccomp files). We then map these objects to node and their
logical relations to edges in the graph (e.g., $Container$ (node) has
capability (edge) $SYS\\_ADMIN$ (node) or $Docker\\_Engine$ (node) is using
(edge) $Kernel$ (node) of version (edge) $4.9$ (node)).

In addition, we do not only model the current configuration (as parsed) but
also possible configuration alternatives. For instance, we add nodes
representing alternative versions of the Linux kernel or Docker engine.

We choose the Neo4J graph database to represent the knowledge graph and
vulnerabilities dataset (AND/OR graphs) and the Python language to parse
configuration files and automatically update the graph using Neo4J APIs.

In order to build the knowledge graph, we first parse the container
configurations files. In particular, Fig. 2 shows the different files that we
parse (e.g., we also consider security profiles and docker run options), and
the information extracted from each, to build the knowledge graph.

Figure 2: The parsed configuration files to build the knowledge graph.

State of the art tools do not parse the given permissions (e.g. Linux
capabilities and system calls) and the docker run options for possible
misconfigurations. For example, Dockerfile instructions can be overwritten by
docker run options, thus it is important to parse all configurations
available.

Build vulnerabilities graphs We enrich the graph with a dataset of known
vulnerabilities and misconfigurations [25].

We use a two-dimensional taxonomy to classify container vulnerabilities and
misconfigurations, slightly based on the attack taxonomy proposed in [26].
Within the first dimension we classify the vulnerabilities in three categories
based on the affected component, namely, Container, Kernel, and Engine. Within
the second dimension, we classify the vulnerabilities based on the MITRE
ATT&CK tactics and techniques (e.g. privilege escalation and network service
scanning) [25].

We represent each vulnerability in the graph as an AND/OR graph, where the
root is the final goal of the attack, the rest of the nodes represent the
attack assumptions that must hold for an exploit. For example, we use an OR
node to represent a set of vulnerable versions (e.g. Linux kernel versions
between $5.1$ and $5.9$) of a component that can be exploited. Based on the
running configuration (infrastructure, container engine, etc.), represented in
the knowledge graph, we then link the latter to AND/OR graphs assumptions
being currently used (e.g., $Container$ (node) has capability (edge)
$SYS\\_ADMIN$ (node) assumption of $CVE-xxx-xxx$ (node)).

The vulnerabilities dataset is represented using a JSON file; in particular,
Listing 2 shows the JSON representation of the first container escape
described in §II.

Listing 2: An example of a Linux kernel vulnerability representation.

⬇

1”CVE-2022-0492”: [{

2 ”CVSS_v3”: ”7.8”,

3 ”mitre_tactic”: ”priviledge_escalation”,

4 ”mitre_technique”: ”escape_to_host”,

5 ”pre_conditions”: [

6 {

7 ”max_kernel_version”: ”5.17␣rc3”,

8 ”capability”: ”CAP_DAC_OVERRIDE”,

9 ”syscall”: ”mount,␣unshare”

10 }

11 ],

12 ”post_conditions”: [

13 {

14 ”impact”: ”priviledge_escalation”

15 }

16 ]

17}]

##  V Searching for a Fix

Analytic Hierarchy Process (AHP). The AHP is a multiple criteria decision-
making methodology. In AHP, a hierarchy of solution alternatives is created,
then the user is asked to provide weights to each solution alternative, and
finally, pair-wise alternatives are compared until the optimal solution is
obtained [27]. Before evaluating the presence of vulnerabilities within the
graph, we interact with the end-user to rank the list of possible fixes that
can mitigate the attacks. For instance, we may ask a user to assign a
preference (with $1$ least favorite and $9$ most favorite) to run a container
as not root or assign a preference to remove specific capabilities of the
container. In practice this means ordering the following list of possible
fixes: (version_upgrade, not_privileged, not_root, not_capability,
not_syscall, read_only_fs, no_new_priv). Similar dimensions can then be used
on different types of fixes. This ranking will help us in suggesting the most
effective fix that, at the same time, the user is also most willing to accept
and implement.

Test & Fix for vulnerabilities. Finally, we test (by querying the graph) and
fix (by suggesting and eventually implementing security fixes) the system. To
this aim, we rely on the user to accept the best alternative configurations
(based on the provided weights). An attack is mitigated by implementing a fix
(invalidating one attacks’ assumption) which is reflected in the graph by
removing or adding an edge.

Algorithm 1 shows the procedure to stress-test a cloud system by unveiling the
presence of one vulnerability. The steps of the algorithm are (1) parsing the
configuration files and building the knowledge graph, (2) adding and link the
vulnerability AND/OR graph, (3) fetching user preferences, and finally (4)
suggesting the best fix. To this aim, the algorithm iteratively suggests
security fixes to mitigate the vulnerability assumptions, following the user
preferences. Eventually, the algorithm can automatically accept the most
preferred fix.

Algorithm 1 Stress-test a cloud system for one vulnerability.

1:Configuration files

2:Vulnerability

3:Safe configuration

4:Build Knowledge graph;

5:Enrich the graph with the vulnerability;

6:Get list of user preferred fixes;

7:get_preferred_fix($vuln\\_query$)

8:function get_preferred_fix($vul\\_query$)

9: while $vuln\\_query==true$ do

10: Collect vulnerability assumptions;

11: Order assumptions by AHP;

12: repeat

13: Suggest assumption to remove;

14: if $user\\_accepts\\_fix$ then

15: remove edge;

16: until $user\\_not\\_happy$

The configuration of more realistic cloud deployments may contain several
vulnerabilities. In this case, the problem requires finding a globally optimal
solution. Therefore, local fixes must be additionally weighted in combination
with other misconfiguration fixes. Currently, our algorithm relies on user
input to determine such weights based on AHP. Our implementation could be
extended in the future to find a set of globally optimal fixes.

In some cases, the user can also decide to intentionally keep a few low-risk
vulnerabilities to avoid trading off the performance of the system. In such
cases, although the vulnerability query will still be satisfied, this approach
may help move towards a ”safer” configuration state (e.g. by running a
container with all and only needed capabilities and system calls, instead of
privileged).

We provide Neo4J queries examples in the Preliminary Validation paragraph of
§VI.

##  VI Preliminary Evaluation

We investigated the cost of storing the representation of container
configurations (incl. configuration alternatives) and the memory requirements
for storing vulnerabilities in the knowledge graph. In addition, we illustrate
the feasibility of the proposed approach on three vulnerabilities.

The cost of storing containers. Tab. I shows the cost, in terms of number of
nodes and edges, of storing a container image and several containers (using
the Docker default security profile, with a subset of capabilities and system
calls allowed). Specifically, we use one node to represent the host virtual
machine, $50$ nodes to represent the versions of Linux kernel (from version
$3.9$, released after March 20 2013, when Docker was released), one node to
represent the Docker engine, $132$ nodes to represent the versions of Docker,
$83$ nodes to represent the versions of containerd, and $18$ nodes to
represent the versions of runc. In addition, we use $41$ nodes to represent
Linux capabilities and $364$ nodes to represent Linux system calls.

This amounts to $691$ nodes and $6$ relationships (first row in Tab. I).
Additional nodes are used to represent container permissions, security
profiles, and Docker run options; for example, custom security profiles (e.g.,
user-defined AppArmor profiles), may require additional nodes and
relationships corresponding to the granted capabilities and system calls, as
well as relevant Docker run options (e.g., –user and –volume).

TABLE I: The cost of storing container images and (default) configurations into the knowledge graph. Object/s | #_Nodes | #_Edges
---|---|---
Initialization | $691$ | $6$
$1$ Image | $693$ | $8$
$1$ Container (default) | $702$ | $349$
$100$ Container (default) | $999$ | $1.339$
$1.000$ Container (default) | $3.699$ | $10.339$

In the previous table, we considered all containers to be instantiated from
different images, thus with two additional nodes and relationships. Overall,
the number of nodes and edges in the knowledge graph does not grow
exponentially. This is promising as it would allow us defining efficient
algorithms to suggest the best security fixes.

Tab. II shows different Docker run options with the corresponding number of
edges; the number of nodes in the graph remains the same.

TABLE II: List of possible Docker run options with the corresponding number of edges. Docker run options | #_Edges
---|---
\--cap-drop ALL --cap-add NET_BIND_SERVICE | $335$
\--cap-add NET_ADMIN --security-opt apparmor=unconfined | $348$
\--privileged | $420$

Additional configurations exist, as a combination of adding and removing
capabilities, granting or denying system calls (within AppArmor or SecComp),
not using the root user or a read-only filesystem.
The cost storing vulnerabilities. Tab. III presents the dataset of
vulnerabilities we collected from different sources, along with the number of
nodes and edges needed to represent them. The number of nodes and edges in the
table corresponds to the AND/OR graph representing each vulnerability; for
example, in the graph there is a node presenting each Linux kernel version,
and for a kernel vulnerability, there will be an edge between the
vulnerability and each vulnerable version. We classify vulnerabilities in
three categories, namely, container profile misconfigurations, Linux kernel
bugs, and container engine vulnerabilities, as suggested in [28]. Within each
category, we have a subcategory representing the impact of each vulnerability
or attack based on the MITRE ATT&CK tactic and techniques for containers [25].
For the validation of our stress-test approach, we retrieved a set of
vulnerabilities belonging to each category. In particular, for container
profile misconfigurations we retrieved $6$ escaping attacks, for Linux kernel
bugs we retrieved $24$ CVEs (only 10 shown in Tab. III), mostly from [26] and,
finally, for container engine vulnerabilities, considering only Docker (or
Docker subcomponents, such as runc and containerd), we retrieved $6$ CVEs from
[28]. In total, our dataset contains $36$ vulnerabilities.

TABLE III: Information about the vulnerabilities dataset, divided by categories, together with the number of nodes and edges. Categ. | Sub-cat. | CVE | #_Nodes | #_Edges
---|---|---|---|---
Container misc. | Escape to host | Cgroup escape | $8$ | $12$
Cap. SYS_MODULE | $6$ | $7$
Kernel fs /sys | $2$ | $2$
Host devices | $7$ | $11$
Host /root | $4$ | $6$
Docker socket | $4$ | $6$
Kernel bugs |  | CVE-2022-0847 | $11$ | $19$
| CVE-2022-0492 | $58$ | $62$
| CVE-2022-0185 | $22$ | $25$
| CVE-2020-14386 | $44$ | $44$
| CVE-2017-7308 | $47$ | $47$
Exploitation | CVE-2017-5123 | $10$ | $10$
| CVE-2016-8655 | $37$ | $40$
| CVE-2016-4997 | $20$ | $20$
| CVE-2017-6074 | $23$ | $23$
| CVE-2017-1000112 | $27$ | $27$
Docker vuln. | Code injection | CVE-2019-14271 | $9$ | $14$
Exploitation | CVE-2020-15257 | $106$ | $109$
Escape to Host | CVE-2016-9962 | $27$ | $29$
CVE-2018-15664 | $66$ | $66$
CVE-2019-5736 | $299$ | $300$
DoS | CVE-2020-13401 | $221$ | $224$

Vulnerabilities Queries. To illustrate the feasibility of our approach, we
performed an initial evaluation on three vulnerabilities, namely, Cgroup
escape, CVE-2022-0492, and CVE-2020-13401 (green rows in Tab. III). To the
best of our knowledge, an existing algorithm to traverse AND/OR graph in Neo4j
does not yet exist. Therefore, for our initial validation, we manually check
whether a vulnerability is exploitable or not. In future work, we plan to
implement such an algorithm to automatically check the presence of
vulnerabilities. Listing 3 shows a Neo4J query to check whether a certain
property (e.g., permission, capability, or system call) belongs to a container
or not.

Listing 3: Neo4J query to check a container relationship

⬇

1MATCH (c:Container {name: ”Nginx”})

2MATCH (p:Permissions {name: ”Privileged”})

3RETURN EXISTS( (c)-[:HAS]-(p)

Based on the current implementation, as future work, we plan to test this
approach on all $36$ vulnerabilities with different configurations (different
security profiles, docker run options, etc.) and possibly, on different
container engines. By doing so, we can evaluate more extensively the results
of stress-tests and explore the support of what-if scenarios; for example, we
can claim the most effective mitigation against most attacks but also evaluate
the most dangerous configurations. Finally, at the end of each run, the number
of removed edges (attacks assumptions) could be used as an indicator of the
resilience to the stress test and can be used as a measure of quality in the
context of a more comprehensive validation.

##  VII Discussion

This approach might also be suitable to build attack paths in more complex
environments (e.g. Kubernetes clusters).

Efficient graph algorithms could be used to cast and then address a number of
security issues: reachability (e.g. given the current configuration, whether
the attacker can reach a new state), minimum weight traversal (e.g. the
easiest exploitation path), and vertex cuts (e.g. suggesting a policy or
configuration change that invalidates an attack).

To have a dynamic picture, one could run the stress-test at a given time
interval and evaluate the output at each time; for example, we could evaluate
the number of changes in the graph (new nodes or edges) as a risk analysis of
the the current configuration, or the number of changes needed to get to a
”safe” state.

We plan to extend our implementation and support more container engines (e.g.
Podman and CRI-O) as well as infrastructure-as-code tools (e.g. Vagrant and
Terraform) integrate the implementation into a container orchestration tool
(e.g. in Kubernetes as an admission controller).

##  VIII Conclusion

In this paper, we proposed a stress-test approach for cloud configurations, by
using a knowledge graph to represent deployments and permissions, and AND/OR
graphs to represent vulnerabilities. We described our solution along with
algorithms to unveil vulnerabilities and semi-automatically suggest security
fixes to mitigate them; we also described a first implementation and
evaluation on Docker containers. We believe this is the first step forward
towards a dynamic and continuous evaluation mechanism for risk analysis in
cloud environments while suggesting security fixes. In the future, more
validation on scalability and query performance is needed, especially with
hundreds or thousands of containers.

## Acknowledgments

This work has been partially supported by the European Union under the H2020
grant 952647 (AssureMOSS).

## References

  * [1] Sysdig, “Sysdig 2022 cloud-native security and usage report,” (Accessed on: 28/03/2022). [Online]. Available: https://sysdig.com/2022-cloud-native-security-and-usage-report/
  * [2] N. S. A. (NSA), “Mitigating cloud vulnerabilities,” (Accessed on: 09/03/2022). [Online]. Available: https://media.defense.gov/2020/Jan/22/2002237484/-1/-1/0/CSI-MITIGATING-CLOUD-VULNERABILITIES_20200121.PDF
  * [3] E. E. B. Authority), “Eba will run its next eu-wide stress test in 2023,” (Accessed on: 22/03/2022). [Online]. Available: https://www.eba.europa.eu/eba-will-run-its-next-eu-wide-stress-test-2023
  * [4] T. of Bits, “Understanding docker container escapes,” (Accessed on: 23/03/2022). [Online]. Available: https://blog.trailofbits.com/2019/07/19/understanding-docker-container-escapes/
  * [5] P. A. U. 42, “New linux vulnerability cve-2022-0492 affecting cgroups: Can containers escape?” (Accessed on: 23/03/2022). [Online]. Available: https://unit42.paloaltonetworks.com/cve-2022-0492-cgroups/
  * [6] X. Li, Y. Chen, and Z. Lin, “Towards automated inter-service authorization for microservice applications.” New York, NY, USA: Association for Computing Machinery, 2019, p. 3–5.
  * [7] D. Preuveneers and W. Joosen, “Access control with delegated authorization policy evaluation for data-driven microservice workflows,” _Future Internet_ , vol. 9, no. 4, pp. 1–21, 2017.
  * [8] A. Ranjbar, M. Komu, P. Salmela, and T. Aura, “Synaptic: Secure and persistent connectivity for containers.” Madrid, Spain: IEEE, 2017, pp. 262–267.
  * [9] Y. Sun, S. Nanda, and T. Jaeger, “Security-as-a-service for microservices-based cloud applications.” Vancouver, BC, Canada: IEEE, 2016, pp. 50–57.
  * [10] A. B. Fadhel, D. Bianculli, and L. C. Briand, “Model-driven run-time enforcement of complex role-based access control policies,” 2018, pp. 248–258.
  * [11] H. Zhu and C. Gehrmann, “Apparmor profile generator as a cloud service.” in _CLOSER_ , 2021, pp. 45–55.
  * [12] C. Gerking and D. Schubert, “Component-based refinement and verification of information-flow security policies for cyber-physical microservice architectures.” Hamburg, Germany: IEEE, 2019, pp. 61–70.
  * [13] K. A. Torkura, M. I. Sukmana, and C. Meinel, “Integrating continuous security assessments in microservices and cloud native applications.” New York, NY, USA: Association for Computing Machinery, 2017, p. 171–180.
  * [14] A. Ibrahim, S. Bozhinoski, and A. Pretschner, “Attack graph generation for microservice architecture,” ser. SAC ’19. New York, NY, USA: Association for Computing Machinery, 2019, p. 1235–1242.
  * [15] NIST, “Vulnerability scanning,” 2021, (accessed: 08/02/2021). [Online]. Available: https://csrc.nist.gov/glossary/term/Vulnerability_Scanning
  * [16] G. F. Lyon, _Nmap network scanning: The official Nmap project guide to network discovery and security scanning_. US: Insecure. Com LLC (US), 2008.
  * [17] B. Chess and G. McGraw, “Static analysis for security,” vol. 2, no. 6, pp. 76–79, 2004.
  * [18] I. Pashchenko, H. Plate, S. Ponta, A. Sabetta, and F. Massacci, “Vuln4real: A methodology for counting actually vulnerable dependencies,” vol. SE-13, no. 01, pp. 1–1, sep 5555.
  * [19] S. Dashevskyi, A. D. Brucker, and F. Massacci, “A screening test for disclosed vulnerabilities in FOSS components,” vol. 45, no. 10, pp. 945–966, 2018.
  * [20] O. S. Vaidya and S. Kumar, “Analytic hierarchy process: An overview of applications,” _European Journal of operational research_ , vol. 169, no. 1, pp. 1–29, 2006.
  * [21] S. Noel, E. Harley, K. H. Tam, M. Limiero, and M. Share, “Cygraph: graph-based analytics and visualization for cybersecurity,” in _Handbook of Statistics_. Elsevier, 2016, vol. 35, pp. 117–167.
  * [22] Y. Jia, Y. Qi, H. Shang, R. Jiang, and A. Li, “A practical approach to constructing a knowledge graph for cybersecurity,” _Engineering_ , vol. 4, no. 1, pp. 53–60, 2018.
  * [23] K. Zhang and J. Liu, “Review on the application of knowledge graph in cyber security assessment,” in _IOP Conference Series: Materials Science and Engineering_ , vol. 768, no. 5. IOP Publishing, 2020, p. 052103.
  * [24] C. Banse, I. Kunz, A. Schneider, and K. Weiss, “Cloud property graph: Connecting cloud security assessments with static code analysis,” in _2021 IEEE 14th International Conference on Cloud Computing (CLOUD)_. IEEE, 2021, pp. 13–19.
  * [25] T. M. Corporation, “Containers matrix,” (Accessed on: 22/03/2022). [Online]. Available: https://attack.mitre.org/matrices/enterprise/containers/
  * [26] X. Lin, L. Lei, Y. Wang, J. Jing, K. Sun, and Q. Zhou, “A measurement study on linux container security: Attacks and countermeasures,” in _Proceedings of the 34th Annual Computer Security Applications Conference_ , ser. ACSAC ’18. New York, NY, USA: Association for Computing Machinery, 2018, p. 418–429.
  * [27] O. S. Vaidya and S. Kumar, “Analytic hierarchy process: An overview of applications,” _European Journal of Operational Research_ , vol. 169, no. 1, pp. 1–29, 2006.
  * [28] M. Reeves, D. J. Tian, A. Bianchi, and Z. B. Celik, “Towards improving container security by preventing runtime escapes,” in _2021 IEEE Secure Development Conference (SecDev)_ , 2021, pp. 38–46.