More Like this

1. Detecting Database File Tampering through Page Carving

   Wagner, James ; Rasin, Alexander ; Malik, Tanu ; Heart, Karen ; Furst, Jacob D. ; Grier, Jonathan ( March 2018 , 21st International Conference on Extending Database Technology)

   Database Management Systems (DBMSes) secure data against regular users through defensive mechanisms such as access control, and against privileged users with detection mechanisms such as audit logging. Interestingly, these security mechanisms are built into the DBMS and are thus only useful for monitoring or stopping operations that are executed through the DBMS API. Any access that involves directly modifying database files (at file system level) would, by definition, bypass any and all security layers built into the DBMS itself. In this paper, we propose and evaluate an approach that detects direct modifications to database files that have already bypassed the DBMS and its internal security mechanisms. Our approach applies forensic analysis to first validate database indexes and then compares index state with data in the DBMS tables. We show that indexes are much more difficult to modify and can be further fortified with hashing. Our approach supports most relational DBMSes by leveraging index structures that are already built into the system to detect database storage tampering that would currently remain undetectable.
2. Detecting Database File Tampering through Page Carving

   Wagner, James ; Rasin, Alexander ; Heart, Karen ; Malik, Tanu ; Furst, Jacob ; Grier, Jonathan ( March 2018 , 21st International Conference on Extending Database Technology)

   Database Management Systems (DBMSes) secure data against regular users through defensive mechanisms such as access control, and against privileged users with detection mechanisms such as audit logging. Interestingly, these security mechanisms are built into the DBMS and are thus only useful for monitoring or stopping operations that are executed through the DBMS API. Any access that involves directly modifying database files (at file system level) would, by definition, bypass any and all security layers built into the DBMS itself. In this paper,we propose and evaluate an approach that detects direct modifications to database files that have already bypassed the DBMS and its internal security mechanisms. Our approach applies forensic analysis to first validate database indexes and then compares index state with data in the DBMS tables. We show that indexes are much more difficult to modify and can be further fortified with hashing. Our approach supports most relational DBMSes by leveraging index structures that are already built into the system to detect database storage tampering that would currently remain undetectable.
3. Software Environments in Binder Containers

   https://doi.org/10.5281/zenodo.4891790  

   Shaffer, Tim ; Chard, Kyle ; Thain, Douglas ( January 2021 )

   Abstract

   <p>Binder is a publicly accessible online service for executing interactive notebooks based on Git repositories. Binder dynamically builds and deploys containers following a recipe stored in the repository, then gives the user a browser-based notebook interface. The Binder group periodically releases a log of container launches from the public Binder service. Archives of launch records are available here. These records do not include identifiable information like IP addresses, but do give the source repo being launched along with some other metadata. The main content of this dataset is in the <code>binder.sqlite</code> file. This SQLite database includes launch records from 2018-11-03 to 2021-06-06 in the <code>events</code> table, which has the following schema.</p> <code>CREATE TABLE events( version INTEGER, timestamp TEXT, provider TEXT, spec TEXT, origin TEXT, ref TEXT, guessed_ref TEXT ); CREATE INDEX idx_timestamp ON events(timestamp); </code> <ul><li><code>version</code> indicates the version of the record as assigned by Binder. The <code>origin</code> field became available with version 3, and the <code>ref</code> field with version 4. Older records where this information was not recorded will have the corresponding fields set to null.</li><li><code>timestamp</code> is the ISO timestamp of the launch</li><li><code>provider</code> gives the type of source repo being launched (&#34;GitHub&#34; is by far the most common). The rest of the explanations assume GitHub, other providers may differ.</li><li><code>spec</code> gives the particular branch/release/commit being built. It consists of <code>&lt;github-id&gt;/&lt;repo&gt;/&lt;branch&gt;</code>.</li><li><code>origin</code> indicates which backend was used. Each has its own storage, compute, etc. so this info might be important for evaluating caching and performance. Note that only recent records include this field. May be null.</li><li><code>ref</code> specifies the git commit that was actually used, rather than the named branch referenced by <code>spec</code>. Note that this was not recorded from the beginning, so only the more recent entries include it. May be null.</li><li>For records where <code>ref</code> is not available, we attempted to clone the named reference given by <code>spec</code> rather than the specific commit (see below). The <code>guessed_ref</code> field records the commit found at the time of cloning. If the branch was updated since the container was launched, this will not be the exact version that was used, and instead will refer to whatever was available at the time (early 2021). Depending on the application, this might still be useful information. Selecting only records with version 4 (or non-null <code>ref</code>) will exclude these guessed commits. May be null.</li></ul> <p>The Binder launch dataset identifies the source repos that were used, but doesn&#39;t give any indication of their contents. We crawled GitHub to get the actual specification files in the repos which were fed into repo2docker when preparing the notebook environments, as well as filesystem metadata of the repos. Some repos were deleted/made private at some point, and were thus skipped. This is indicated by the absence of any row for the given commit (or absence of both <code>ref</code> and <code>guessed_ref</code> in the <code>events</code> table). The schema is as follows.</p> <code>CREATE TABLE spec_files ( ref TEXT NOT NULL PRIMARY KEY, ls TEXT, runtime BLOB, apt BLOB, conda BLOB, pip BLOB, pipfile BLOB, julia BLOB, r BLOB, nix BLOB, docker BLOB, setup BLOB, postbuild BLOB, start BLOB );</code> <p>Here <code>ref</code> corresponds to <code>ref</code> and/or <code>guessed_ref</code> from the <code>events</code> table. For each repo, we collected spec files into the following fields (see the repo2docker docs for details on what these are). The records in the database are simply the verbatim file contents, with no parsing or further processing performed.</p> <ul><li><code>runtime</code>: <code>runtime.txt</code></li><li><code>apt</code>: <code>apt.txt</code></li><li><code>conda</code>: <code>environment.yml</code></li><li><code>pip</code>: <code>requirements.txt</code></li><li><code>pipfile</code>: <code>Pipfile.lock</code> or <code>Pipfile</code></li><li><code>julia</code>: <code>Project.toml</code> or <code>REQUIRE</code></li><li><code>r</code>: <code>install.R</code></li><li><code>nix</code>: <code>default.nix</code></li><li><code>docker</code>: <code>Dockerfile</code></li><li><code>setup</code>: <code>setup.py</code></li><li><code>postbuild</code>: <code>postBuild</code></li><li><code>start</code>: <code>start</code></li></ul> <p>The <code>ls</code> field gives a metadata listing of the repo contents (excluding the <code>.git</code> directory). This field is JSON encoded with the following structure based on JSON types:</p> <ul><li>Object: filesystem directory. Keys are file names within it. Values are the contents, which can be regular files, symlinks, or subdirectories.</li><li>String: symlink. The string value gives the link target.</li><li>Number: regular file. The number value gives the file size in bytes.</li></ul> <code>CREATE TABLE clean_specs ( ref TEXT NOT NULL PRIMARY KEY, conda_channels TEXT, conda_packages TEXT, pip_packages TEXT, apt_packages TEXT );</code> <p>The <code>clean_specs</code> table provides parsed and validated specifications for some of the specification files (currently Pip, Conda, and APT packages). Each column gives either a JSON encoded list of package requirements, or null. APT packages have been validated using a regex adapted from the repo2docker source. Pip packages have been parsed and normalized using the Requirement class from the pkg_resources package of setuptools. Conda packages have been parsed and normalized using the <code>conda.models.match_spec.MatchSpec</code> class included with the library form of Conda (distinct from the command line tool). Users might want to use these parsers when working with the package data, as the specifications can become fairly complex.</p> <p>The <code>missing</code> table gives the repos that were not accessible, and <code>event_logs</code> records which log files have already been added. These tables are used for updating the dataset and should not be of interest to users.</p>
   More>>
4. Prevalence of SARS-CoV-2 genes in water reclamation facilities: From influent to anaerobic digester

   https://doi.org/doi.org/10.1016/j.scitotenv.2021.148905  

   Bishav Bhattarai ; Sierra Quinn Sahulka ; Aditi Podder ; Soklida Hong ; Hanyan Li ; Eddie Gilcrease ; Alex Beams ; Rebecca Steed ; and Ramesh Goel* ( July 2021 , Science of the total environment)

   Not Known (Ed.)

   Several treatment plants were sampled for raw influent, primary clarifier sludge, return activated sludge (RAS), and anaerobically digested sludge throughout nine weeks during the summer of the COVID-19 pandemic. Primary clarifier sludge had a significantly higher number of SARS-CoV-2 gene copy number per liter (GC/L) than other sludge samples, within a range from 1.0x105 to 1.0x106 GC/L. Gene copy numbers in raw influent significantly correlated with gene copy numbers in RAS in Silver Creek (p-value = 0.007, R2 = 0.681) and East Canyon (p-value = 0.009, R2 = 0.775) WRFs; both of which lack primary clarifiers or industrial pretreatment processes. This data indicates that SARS-CoV-2 gene copies tend to partition into primary clarifier sludges, at which point a significant portion of them are removed through sedimentation. Furthermore, it was found that East Canyon WRF gene copy numbers in influent were a significant predictor of daily cases (p-value = 0.0322, R2 = 0.561), and gene copy numbers in RAS were a significant predictor of weekly cases (p-value = 0.0597, R2 = 0.449). However, gene copy numbers found in primary sludge samples from other plants significantly predicted the number of COVID-19 cases for the following week (t = 2.279) and the weekmore »after that (t = 2.122). These data indicate that SARS-CoV-2 extracted from WRF biosolids may better suit epidemiological monitoring that exhibits a time lag. It also supports the observation that primary sludge removes a significant portion of SARS-CoV-2 marker genes. In its absence, RAS can also be used to predict the number of COVID-19 cases due to direct flow through from influent. This research represents the first of its kind to thoroughly examine SARS-CoV-2 gene copy numbers in biosolids throughout the wastewater treatment process and the relationship between primary, return activated, and anaerobically digested sludge and reported positive COVID-19 cases.« less
5. Copy-on-Abundant-Write for Nimble File System Clones

   https://doi.org/10.1145/3423495  

   Zhan, Yang ; Conway, Alex ; Jiao, Yizheng ; Mukherjee, Nirjhar ; Groombridge, Ian ; Bender, Michael A. ; Farach-Colton, Martin ; Jannen, William ; Johnson, Rob ; Porter, Donald E. ; et al ( February 2021 , ACM Transactions on Storage)

   Making logical copies, or clones, of files and directories is critical to many real-world applications and workflows, including backups, virtual machines, and containers. An ideal clone implementation meets the following performance goals: (1) creating the clone has low latency; (2) reads are fast in all versions (i.e., spatial locality is always maintained, even after modifications); (3) writes are fast in all versions; (4) the overall system is space efficient. Implementing a clone operation that realizes all four properties, which we call a nimble clone , is a long-standing open problem. This article describes nimble clones in B-ϵ-tree File System (BetrFS), an open-source, full-path-indexed, and write-optimized file system. The key observation behind our work is that standard copy-on-write heuristics can be too coarse to be space efficient, or too fine-grained to preserve locality. On the other hand, a write-optimized key-value store, such as a Bε-tree or an log-structured merge-tree (LSM)-tree, can decouple the logical application of updates from the granularity at which data is physically copied. In our write-optimized clone implementation, data sharing among clones is only broken when a clone has changed enough to warrant making a copy, a policy we call copy-on-abundant-write . We demonstrate that the algorithmic workmore »needed to batch and amortize the cost of BetrFS clone operations does not erode the performance advantages of baseline BetrFS; BetrFS performance even improves in a few cases. BetrFS cloning is efficient; for example, when using the clone operation for container creation, BetrFS outperforms a simple recursive copy by up to two orders-of-magnitude and outperforms file systems that have specialized Linux Containers (LXC) backends by 3--4×.« less