dataesr/scientific-paragraphs-categorization huggingface dataset:
C. Performance of counter-measure selection In a last series of experiments, we wanted to quantify the assessment time required for selecting a given security function (or a set of security functions). In particular, we have looked at the frequency of the properties that are impacted by a given security function, and how it influences the assessment time to determine whether the new configuration of the migrated resource is vulnerable or not with regard to this security function. In that context, we have considered three different scenarios, corresponding to security functions that impact respectively the most frequent properties (high scenario), the less frequent properties (low scenario), and properties with an averaged frequency (medium scenario) in the considered vulnerability datasets, as illustrated on Figure  7  describing the assessment time for selecting a security function with the different vulnerability datasets.
These scenarios have been chosen to guarantee an homogeneous distribution of considered properties, amongst the less frequent, moderately frequent and most frequent categories. We expected that the security functions corresponding to the scenario with the highest frequencies provides the best assessment time for selecting security functions, which was indeed the case in our experiments performed with the different vulnerability datasets, by considering various cloud resource migrations. In addition, we can observe the influence of the dataset size. In particular, the differences amongst the three scenarios are the highest for the largest datasets with regard to the evaluation time. For instance, this difference is of less than 8% for the smallest vulnerability datasets, while it reaches around 15% for the largest vulnerability datasets.
They operate according to three main phases, namely the projection of the migrated resource, the assessment of the corresponding configuration based on vulnerability datasets, and the selection of adequate security functions when this configuration appears to be vulnerable. We have shown the framework applicability based on an illustrative example corresponding to a Struts micro-service, part of a cloud composite service, undergoing a migration amongst cloud service providers. This security automation has been formalized using SMT solving, and implemented into a proof-of-concept prototype written in Python on top of the CVC4 solver. Finally, we have performed large series of experiments based on existing vulnerability descriptions coming from the official OVAL repository, and corresponding to different operating systems.
Payload and Platform Requirements The baseline Theia Payload Module (PLM) uses the heritage knowledge of the consortium members for space mission concepts like Gaia, HST /FGS, SIM, NEAT/M3, Theia/M4+M5 and Euclid. Two different possible concepts can be adopted. A NEAT-like mission consisting of a single off-axis mirror sending the light onto a detector either in a formation flight configuration 1 or on a deployable boom, or a Euclid -like mission with a Korsch three-mirror anastigmatic (TMA) telescope, a single focal plane and instrument metrology subsystems 2. Both concepts consist in adopting a long focal length, diffraction limited, telescope and additional metrology control of the focal plane array. The baseline remains therefore the 0. 8-m on-axis TMA telescope operating at visible wavelengths described in the Theia/M5 proposal but with an update of the optical design where all optics are still coaxial but with a field of view whose center is shifted by 0.
Mission Profile Theia needs to point at all-sky directions. L2 is the selected option for the orbit, since it is very favorable for overall stability simplifying thermo-elastic design issues. The Theia spacecraft will be directly injected into a large Lissajous or Halo orbit at L2. To avoid parasitic light from the Sun onto the telescope and the detector, Theia spacecraft have baffles that protect them from Sun light at angle larger than ±45 • from the Sun direction. The baseline launcher is Ariane 6. 2. The launch strategy would consist in a unique burn of upper stage injecting Table  1. TRL evaluation and foreseen development plans for the Theia payload for the phase 1 proposal to the M7 call. directly the S/C onto a L2-transfer trajectory, avoiding coasting on a parking orbit. The observing time baseline to properly investigate the science program of Theia is 4 years including time devoted to orbit maintenance.
Preliminary spacecraft design The preliminary Theia M5 mission analyses allowed identification of a safe and robust mission architecture mostly relying on high TRL technologies. The proposed mission architecture adopts the 0. 8-m Korsch TMA telescope accommodated vertically on top of a platform including all support subsystems. At the inital stage, a high thermal stability of the telescope was thought to be necessary to ensure its performances. It was obtained through the use of a Sun Shield on which is accommodated the Solar Array and a vertical V-groove screen. The design of the satellite is based on the Euclid service module with a downscaled size to better suit to specific Theia needs. Similarly to the Euclid and Herschel satellites, the Theia Korsch telescope is placed on top of the service module in a vertical position.
Resources and Communications The baseline M7 Theia satellite had a dry and wet mass of ∼ 1000 kg and ∼ 1300 kg, respectively, and a payload mass of ∼ 400 kg. Power resources were estimated at ∼ 1400 W for the S/C and ∼ 400 W for the PLM. In terms of communication requirements, the amount of science data produced by the payload module was estimated to a total average of 95 Gbytes/day (135 Gbytes/day worst case), including a compression factor of 2. 5 with a download data rate of ∼75 Mbps with an ESA 35m ground station. Consequently, daily visibility periods of about 4 hours would be necessary, similar to Euclid. All the above requirements fit the constraints in the technical annex to the present Call. The foreseen simplified payload configuration will further relax these requirements.
All other countries contributing either to the science case, or to the payload development, or both, are led by a Co-I. We envision a relevant role for the Theia Science Team, that would advise ESA on all aspects of the mission potentially affecting its scientific performance, assisting the ESA Project Scientist in maximising the overall scientific return of the mission. The Theia mission is proposed to be a fully European mission, led by ESA. In a preliminary iteration, the Theia Consortium has converged on a scenario for the distribution of responsibilities for providing the following Payload Module (PLM) systems: camera + FGS, telescope (optics, structure, thermal stabilization control), focal plane array, all metrology subsystems, on-board control software, overall PLM assembly, integration and verification (AIV).
Eukaryotic genomes encode distant homologs of antiphage systems We hypothesized that components of some of the recently-discovered antiphage systems may be conserved in eukaryotes, and thus could be identified through protein homology search. We used DefenseFinder, a pipeline developed to map known antiphage systems in prokaryotic genomes  (2). This pipeline currently detects 132 types of antiphage systems, and relies on protein sequence homology to detect a system's individual components. Each component is searched using a protein profile allowing for low homology detection (hidden Markov model, HMM). Because most antiphage systems are organized in operons, DefenseFinder also takes into account genomic proximity on the chromosome (colocalization) of genes from a given system. Our analysis thus relies on two complementary criteria: 1) for single-gene systems, high sequence homology with a protein profile; 2) for multi-gene systems, a more relaxed sequence homology of each component coupled with the constraint of genes' colocalization.
These two criteria are expected to limit the potential detection of antiphage homologs in eukaryotes as 1) protein homology may be limited and 2) coregulation of eukaryotic gene expression does not canonically rely on genomic colocalization. Nonetheless, genes of eukaryotic homologs of antiphage systems can be genomically colocalized, as recently observed for viperin and its kinase partner in metazoans, including humans  (9, 13). DefenseFinder analysis of a database of 4,616 genomes spanning the kingdom of eukaryotes detected 14,217 hits, which were filtered to remove bacterial genomic hits (Table  S1  and Material and Methods). This approach was successful in detecting hits of eukaryotic immune proteins with known antiphage homologs, such as viperin (Fig. 1A , 1,164 homologs). Viperin's antiphage activity relies on the generation of modified nucleotides that act as chain terminators of viral replication.
This initial analysis identified distant homologs of antiphage systems in eukaryotes. It however relies on a criterion of genomic colocalization, which prevents the detection of homologous multi-gene systems in which all components exist in a eukaryotic genome, but would not be genomically colocalized. Among the full systems detected by DefenseFinder in eukaryotic genomes, we focused on Mokosh, Eleos and Lamassu, and scanned our database of genomes for their individual components (Fig. 1F ). The number of eukaryotic hits obtained with this analysis varied drastically between profiles, ranging from 1,080 for MkoB to 1,095,192 for MkoA (fig. S1-2  and Table  S2 ). Since protein domains can typically be shared between immune and non-immune proteins  (17) , we expect the resulting hits to be a mix of immune and non-immune proteins.
Database of eukaryotic and prokaryotic genomes Eukaryotic genomes were downloaded from genbank in January 2022. Isoforms were removed from the protein fasta files, when possible, by keeping the longest one. Pseudogenes were removed as well, when annotated as such. CDS were renamed to take into account the relative position to easily assess whether two proteins are co-localized in the genome. In total, 4,616 eukaryotic genomes representing 2407 species were screened. 22,920 prokaryotic complete genomes were downloaded from Refseq in July 2022. List of genomes are available at https://github. com/mdmparis/cury_mordret_et_al_supplementary_data.
Identification of homologous antiphage systems in eukaryotic genomes DefenseFinder v1. 0. 9 with models v1. 2. 2 was run with default parameters on the custom database of 4,616 eukaryotic genomes, generating 14,701 candidate systems composed of a total of 17,932 associated genes. The output hits of DefenseFinder was examined to remove potential bacterial genomic contaminations. Each candidate gene was searched against the UniProt90 (https://www. uniprot. org) database using Diamond (v2. 0. 9 -b 10 -c 1 --max-target-seqs 5 --outfmt 6) (31), retrieving the 5 best hits per query. We used the uniprot id-mapping API to fetch the common ncbi taxon id of each of the UniProt90 families. This step fetched a taxon id for 78% of the hits. For the remaining 22% of the hits whose protein's id did not match any UniProt90 family, we fetched their taxonomy by mapping the id to UniProtKB (12%) or to UniParc (10%).
Each candidate protein was deemed a contamination if at least one of the 5 best hits on the UniProt90/UniProtKB/UniParc database came from a prokaryote, and its associated systems were subsequently removed from the pipeline. This approach led us to remove a total of 746 (4. 2%) genes and 484 systems (3. 3%) from our list, leaving us with 14,217 eukaryotic system candidates composed of 17,186 genes.
Homology search of Mokosh, Eleos, Lamassu We looked for homologs in eukaryotic genomes starting for the following primary HMM profiles: LmuA_effector_Protease, LmuB_SMC_Hydrolase_protease, MkoA, MkoB, LeoA, LeoBC (available at https://github. com/mdmparis/defense-finder-models). For each profile, the pipeline for homology search was similar. First, we searched the primary profile against our custom database of eukaryotic and prokaryotic proteins using hmmsearch (version 3. 3. 2), at an e-value threshold of 1e-3  (32). Prokaryotic hits were then marked as "paired" if they were found in proximity to their defense system partner(s), according to the rules of DefenseFinder, and as "isolated" otherwise. We selected a subset of these sequences, containing approximately 200 paired and 300 isolated prokaryotic hits, to perform downstream phylogenetic analyses.
Clades were manually curated to include eukaryotic proteins distant from prokaryotic proteins with non-immune function (see fig. S1  and Table  S3 ,S4,S5). Their eukaryotic members were aligned using mafft. We performed a manual curation of the alignments by removing sequences that did not align well with the rest, recomputed the alignments, and manually truncated the N and C termini. These alignments were used to build secondary hmm profiles using hmmbuild (from hmmer version 3. 3. 2). All alignments and profiles are available at https://github. com/mdmparis/cury_mordret_et_al_supplementary_data. Each of these secondary profiles was then used to search against the eukaryotic protein database using hmmsearch. We visualized the distribution of scores, and manually determined a score threshold to keep or discard these secondary hits (fig.
Structural comparisons Structures were either downloaded from the alphafold. ebi. ac. uk database, or computed using the ColabFold notebook (Table  S7 )  (38) (39) (40). We created custom databases of structures and searched them using the easy-search command of foldseek version 3. 915ef7d (41) (Table  S7 , https://github. com/mdmparis/cury_mordret_et_al_supplementary_data. ) with default parameters. Structures were imported, realigned based on the Foldseek alignment, and visualized in the PyMol version 2. 5. 4 (42) (Schrödinger, LLC).
Acknowledgments We thank  Nicolas Manel  and  Xavier Lahaye  for the kind gift of herpes simplex virus. The bioinformatics analysis were performed on the Core Cluster of the  Institut Français de Bioinformatique (IFB)  ( ANR-11-INBS-0013 ). We are grateful to members of the MDM lab, U1284, U932 as well as mentors and friends for their useful comments on earlier version of the manuscript. Funding: J. C. , E. M. , F. T. , A. B are supported by the  CRI Research Fellowship  to  Aude Bernheim  from the  Bettencourt Schueller Foundation , the  ATIP-Avenir program  from.
INSERM (R21042KS/RSE22002KSA), the Emergence program from the University of Paris-Cité (RSFVJ21IDXB6_DANA) and ERC Starting Grant (PECAN 101040529). E. Z. P and V. H. T are supported by an Amorçage Grant 2021 from the Fondation pour la Recherche Médicale (AJE202110014409), a grant from Paris Sciences et Lettres University (Amorçage Jeunes Équipes) and funding from Institut Curie. G. O. is supported by an EMBO Long-Term Fellowship 5 (ALTF 851-2021). Author contributions: All the authors designed experiments and analyzed data. J. C. , E. M. and F. T. performed data curation and formal analysis. V. H. T performed experiments. J. C. , E. M. , G. O. , E. Z. P. and A. B. wrote the manuscript. A. B. and E. Z. P. acquired funding. Competing interests: The authors declare no competing interests. Data and materials availability: All the data, including phylogenetic trees, HMM profiles and protein structures 10 generated with AlphaFold, are available at https://github.
For different reasons, Linux capabilities have not been widely used. The first problem comes from the use of extended attributes to store the capabilities of executable files (problem 1). Secondly, Linux administrators do not have a tool that allows them to distribute capabilities to Linux users in a fine-grained manner (problem 2). Finegrained privilege distribution should give an administrator the ability to decide: (1) which capabilities to give to which users or groups,  (2)  with which programs, and (3) on which resources users can use the granted privileges. Finally, Linux does not provide a tool that permits Linux users to know the  1. In 2006, GNU rm added the option -no-preserve-root to prevent this problem 2. The capability term here should not be confused with the capability term used in access control literature which refers to a token given by the kernel to a process to access an object (e.
g. file descriptor) capabilities that a program needs in order to run successfully (problem 3). In 2015, the kernel of Linux was modified in order to address the technical problems related to the storing of capabilities in the extended attributes of executable files (i. e. problem 1). This new feature added to the kernel makes it possible to extend the capability module by adding on top of it a policy management tool that can be configured by the administrators of Linux systems  [31]. The objective of this paper is to allow administrators to restrict the use of Linux capabilities in their systems by resolving problems 2 and 3. Concretely, we are providing a module called RootAsRole that gives system administrators the possibility of finely controlling the distribution of administrative privileges to Linux users.
e. problem 3). We have used eBPF which allows us to intercept the syscalls of the Linux capability module and return the requested capability. 5) Adding a set of tools that allow an administrator to add/update/delete roles without needing to edit the configuration file manually. This can reduce the configuration errors that can be accidentally made by administrators. 6) Providing a detailed analysis of the inefficiency of LSM in managing the Linux administrative privileges, 7) Discussing the complexity overhead added by our tools when they are compared with the sudo command. The paper is organised as follows. Section 2 describes Linux capabilities, showing how they are calculated by the Linux kernel and what limited tools are available to distribute them to Linux programs. In section 3, we review related work, whilst section 4 introduces the RootAsRole module and shows its advantages by presenting two motivating scenarios.
For example, to restrict the Server web developed in Python using AppArmor, we have to add more than 100 rules for traditional permissions (added by a set of include statements or directly in the policy (see Listing 3) in order to add only one Linux capability in the AppArmor profile. RootAsRole proposes a complementary approach to LSM as it allows the management of administrative privileges exclusively. So when an administrator defines the needed privileges in RootAsRole's configuration file, only the needed capabilities will be injected into the memory of the process, and the function apparmor capable() will continue to work because cap capable() function will return 0 (i. e. , success) as the needed capabilities are present in the memory of the process. Our module allows then Linux users to restrict the usage of administrative privileges without needing to define access rules for traditional permissions.
AppArmor also provides the users with two methods of profiling: Stand-alone profiling and Systemic profiling. While standalone profiling using aa-genprof com- mand is suitable for small applications. Systemic profiling is suitable for creating profiles for many programs that make up an application or for applications that continue running on the computer for a long time. Systemic profiling requires the user to follow the steps shown in Figure  7  [26]. Systemic profiling method requires more efforts from users to define a complete profile for an application. However, the standalone profiling method is not perfect as it suffers from some important issues. To illustrate these issues, we decided to define a profile for a simple Python script that allows us to run a web server. This server requires cap net bind service capability.
The second issue that we have noticed is related to the difficulty to know the processes that are privileged for a system that is using AppArmor. On one hand, the profiles created by AppArmor using the learning mode are not always mentioning explicitly the capabilities used by one program. For example, the Python script for the simple web server requires the use of the cap net bind service capability, but the generated profile does not explicitly show that the capability has been added. On the other hand, the user cannot also trust the information given by the Permitted & Effective sets of the process that is running the Python script, as it shows that it has the full list of Linux capabilities, when in fact the script has only the cap net bind service capability. More seriously, AppArmor does not allow to apply the least privilege principle strictly as it adds many rules that are not really needed by the Python script.
The other users (user tomas and members of groups adm and office ) are not constrained and can be assigned this role with any program; they get a privileged shell inside which they can run any program (that only needs the user's assigned capabilities). The configuration file of RootAsRole limits the use of xattrs. It is read into a central database that allows administrators to keep track of the assigned roles and the programs that users can use with these roles. When the administrator lists a program under a user, the user can only run this program with the capabilities. In some cases, a conflict may exist between the programs defined at the user level and those defined at the group level. For example, administrators may restrict a user to execute only one program, but at the same time, they authorise the user's group to execute any program.
Implementing the sr command The implementation of the sr command depends on the Ambient capability set that has been added to the Linux kernel since Linux 4. 3  [12]. The objective of the sr command is to allow users to assign roles to themselves and to list all the roles available to them, along with the capabilities assigned to each role. The command has the following parameters: • -r, --role=<the role to use> • -c, --command=<the program to launch with the role> • -n, --no-root = <execute the bash or the command without any special treatment of the root user (uid 0). This option allows the user to deactivate the emulation mode of the Linux kernel> • -u, --user=<substitute user reserved for administrators for service management> • -i, --info =<print the roles and their capabilities available to the user, or when used with the -r parameter the commands the user is able to process with this role> • -v, --version = <print the version of RootAsRole> • -h, --help =<print this help> Implementing this command must not necessitate any modifications to the kernel.
In this case, the sr process will have the full set of Linux capabilities and can inject the capabilities of the user's role into the extended attributes of the user's program and then run it. But this defeats the objective of our research, which is to provide an alternative to the sudo/su commands that give programs more privileges than they need. In addition, we do not want to modify the extended attributes of the user's program because another user may use this program at the same time. Instead, we give the sr program file the minimum necessary capabilities at installation time, as described below. On invocation, the sr process then creates a temporary binary file called sr aux and injects the user's requested capabilities into the Inheritable and Permitted sets of this. After that, the sr process executes sr aux to produce an auxiliary process that has the user's capabilities in its Permitted and Inheritable sets.