CN116341012B - File system security reinforcement method based on read-only mechanism - Google Patents
File system security reinforcement method based on read-only mechanism Download PDFInfo
- Publication number
- CN116341012B CN116341012B CN202310573526.8A CN202310573526A CN116341012B CN 116341012 B CN116341012 B CN 116341012B CN 202310573526 A CN202310573526 A CN 202310573526A CN 116341012 B CN116341012 B CN 116341012B
- Authority
- CN
- China
- Prior art keywords
- file system
- read
- file
- version
- var
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
- G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/30—Information retrieval; Database structures therefor; File system structures therefor of unstructured textual data
- G06F16/31—Indexing; Data structures therefor; Storage structures
- G06F16/316—Indexing structures
- G06F16/322—Trees
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
- G06F21/52—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow
- G06F21/53—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow by executing in a restricted environment, e.g. sandbox or secure virtual machine
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
- G06F2009/45587—Isolation or security of virtual machine instances
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Software Systems (AREA)
- Computer Security & Cryptography (AREA)
- General Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Computer Hardware Design (AREA)
- General Health & Medical Sciences (AREA)
- Bioethics (AREA)
- Health & Medical Sciences (AREA)
- Databases & Information Systems (AREA)
- Data Mining & Analysis (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
The file system security reinforcement method based on the read-only mechanism comprises the following steps: preparing a file system needing to be reinforced for safety; constructing an object warehouse based on a read-only mechanism, wherein the object warehouse is used for storing and managing metadata and file objects of a file system, tracking the corresponding file system through a branching function, and executing a switching branching operation to switch to the managed file system; importing the prepared file system into an object warehouse, and creating a new branch for the file system; and packaging the imported file system, writing the packaged file system into an object warehouse, and designating the branch and version number to which the file system belongs. The invention provides safety protection for the use of the container through the invariable infrastructure on the file system level, and the use safety of the reinforced container is realized through read-only file system, system atomization upgrading and upgrading safety early warning.
Description
Technical Field
The invention relates to the technical field of security reinforcement of operating systems, in particular to a security reinforcement method of a file system based on a read-only mechanism.
Background
Containerization, microservice, cloud protogenesis are the current trend of evolution in the computer industry, and most enterprises currently either use containers or consider using containers.
Currently, the most common container solution in the market is Docker, and although container technology is hot and rapidly developed, many of the current demands can be solved, but many challenges still remain. In the environment of the container, since the container only encapsulates the application and the dependence, the container must use the kernel of the host machine to operate, and the mode of sharing the kernel with the host machine can realize light weight, and meanwhile, the range of attack of the container is larger. As long as the rights of the container are obtained, the access to the kernel can be realized, and as long as the application in the container causes the kernel to crash, the whole host system also crashes. In addition, the container is also faced with the following security threats:
(1) Network attack: the containers default to bridge networks that create a virtual bridge, and containers connected between the same bridge can access each other. When a container is hacked, an attacker can access other containers in the host. Meanwhile, an attacker can attack the service of the container to exhaust the resources of the host by DDos and other modes, thereby causing the breakdown of the whole host.
(2) Privilege container: if the privileged mode (- -priviled) is used when the container is enabled, the container will be allowed access to all devices on the host and access rights to a large number of device files can be obtained.
(3) File mounting: when a user configures a container, if the root directory of the host is mapped into the container, the container can theoretically make any modification to the file system of the host, which poses a great security risk.
Thus, preventing an attacker from accessing the host's kernel and file system through the container is an important way to reduce the security risk of the container. The existing scheme mainly adopts a 'safe container', such as Kata and gVisor, wherein Kata is essentially a lightweight virtual machine, gVisor realizes a 'kernel process' Sentry outside the kernel of the host machine, and both adopt a mode of preventing the container from sharing the kernel with the host machine, so that no practical method for ensuring the use safety of the container from the file system level exists at present.
Disclosure of Invention
In order to solve the defects existing in the prior art, the invention provides a file system security reinforcement method based on a read-only mechanism, which comprises the following steps:
step S1: preparing a file system needing to be reinforced for safety;
step S2: constructing an object warehouse based on a read-only mechanism;
step S3: importing the file system prepared in the step S1 into an object warehouse constructed in the step S2, and creating a new branch for the file system;
step S4: packaging the imported file system, writing the file system into an object warehouse, and designating branches and version numbers to which the file system belongs;
the object warehouse constructed in step S3 is used for storing and managing metadata and file objects of the file systems, tracking corresponding file systems through a branching function, and executing a switching branching operation to switch to the managed file systems.
In step S1, the prepared file system includes a read-only portion and a writable portion, the writable portion is stored in the/etc and/var directories, the read-only portion is recorded in the memory, the writable portion is mounted on the read-only portion, and the read-only mechanism uses a draut tool to create a read-only binding mount in the/usr directory, so as to ensure that the/usr directory is permanently in a read-only state.
In step S1, a file system is prepared by:
step S11: creating an empty/sysroot directory in the file system, and ensuring that a read-only mechanism mounts the color bond to a physical root directory;
step S12: when the operating system is started, the following targets are dynamically created for the file system:
/home → /var/home
/opt → /var/opt
/srv → /var/srv
/root → /var/roothome
/usr/local → /var/usr/local
/mnt → /var/mnt
/tmp → /sysroot/tmp。
when the system is updated for the file system, the method comprises the following steps: when the software package is installed or updated through the package manager, the object warehouse generates a new system version and commit information of the commit corresponding to the new system version, triggers one-time atomization upgrading of the system, compares the difference between the commit corresponding to the new system version and the commit corresponding to the system version before updating in an incremental updating mode, acquires the incremental difference and generates a compression patch containing the difference, completes updating according to the incremental difference, and updates the commit information of the current system version according to the commit information of the new system version.
Wherein, when updating the system for the file system, the method for completing the updating according to the increment difference involves: comparing the differences between the new system version and the pre-update system version to obtain all the files which have been modified, generating a new directory containing copies of the files for each file which has been modified, and updating the pre-modification file version to the modified file version by applying the compression patch generated before.
According to the file system security reinforcement method based on the read-only mechanism, security protection is provided for container use through the immutable infrastructure on the file system level, and the use security of the reinforced container is realized through read-only file system, system atomization upgrading and upgrading security early warning.
Drawings
FIG. 1 is a logical diagram of the mechanism of an object repository involved in the read-only mechanism of the present invention.
Fig. 2 is a flow chart of a security early warning when a key file of a system is manually modified based on a read-only mechanism provided by the invention.
FIG. 3 is a schematic diagram of an atomization upgrade implemented according to an incremental update mechanism based on a read-only mechanism provided by the present invention.
FIG. 4 is a diagram illustrating updating of file versions involved in an atomization upgrade according to an embodiment of the present invention.
FIG. 5 is a flow chart of an operating system atomization upgrade based on the read-only mechanism provided by the present invention.
Fig. 6 is a flowchart of security early warning based on the read-only mechanism provided by the invention for illegally updating the key files of the system in a software package mode.
Detailed Description
In order to further understand the technical scheme and beneficial effects of the present invention, the technical scheme and beneficial effects thereof will be described in detail with reference to the accompanying drawings.
According to the file system security reinforcement method based on the read-only mechanism, the read-only mechanism is designed and used, security protection is provided for container use through an invariable infrastructure at the file system level, and meanwhile, the use security of the container is reinforced through file system read-only, system atomization upgrading and upgrading security early warning at the file system level on the basis of a security characteristic module of a kernel and a Selinux security access control system.
Wherein the immutable infrastructure is a read-only mechanism based infrastructure management mode in which the operating system is immutable and can only be updated by replacing the entire operating system. This mode may increase the security and reliability of the system because such non-variability may avoid introducing unexpected changes and vulnerabilities in the system. The read-only mechanism works by managing the entire system as a single immutable object, rather than managing files and directories as in conventional systems. This approach makes system updates safer and more reliable and allows administrators to easily roll back updates to avoid unpredictable problems. Thus, the immutable infrastructure and the read-only mechanism are interrelated, and the read-only mechanism can help achieve the goals of the immutable infrastructure, improving the reliability and security of the system.
By means of a read-only mechanism, the present invention builds a new file system that divides the underlying file system into two parts: a read-only portion and a writable portion.
The read-only part comprises the basic components of the operating system and comprises a plurality of necessary system resources and files, such as a kernel, a file system, a shared library and the like, so that the consistency and the non-variability of the file system are ensured, and the safety and the reliability of the system are improved.
The writable part can be modified and updated as required, such as adding, deleting or modifying files, and mainly comprises user data and configuration files, and is stored in the/etc and/var directory. ( Etc is a configuration file directory that mainly stores configuration files and subdirectories required for system management, such as system version information, local time configuration, etc.; and/var is a variable file directory and mainly stores files with continuously changing contents in the normal operation process of the system, such as logs, offline files, temporary email files and the like. )
When the system is started, the read-only part is loaded into the memory and used as a read-only file system. The writable portion is then mounted onto the read-only portion for use as a writable file system. In order to avoid the need for more binding mounts, the read-only mechanism adopts a UsrMove mechanism, that is, in a default situation, the read-only mechanism uses a draut tool to create a read-only binding mount in a/usr directory (the directory is a main storage location of an operating system binary file and a library file), and the directory contains codes for creating the read-only binding mount of the system, so that the/usr directory is ensured to be in a read-only state permanently by the process, so as to prevent accidental damage of key files of the system in the directory. For operating systems using read-only mechanisms, one/var writable directory will be shared between each version, and the core code of the read-only mechanism will not be related to the contents of the directory; meanwhile, any instance of infrastructure, including various software and hardware such as a server and a container, becomes a read-only state once the deployment is established, and cannot be changed at all, so that the stability and the safety of the system can be ensured.
In other words, the read-only mechanism mounts one read-only file system to another by means of read-only binding mounts, and limits the read-write rights of the mount point therein. The advantage of read-only binding mounting is that some important system directories (such as/usr,/bin, etc.) and executable programs can be limited to read-only access, so that the security and stability of the system can be better protected. When the read-only binding mounting is completed, the files and directories in the mounting point become read-only files, so that any modification operation to the read-only binding is refused. Such a read-only state may ensure the security and stability of the system and may avoid unexpected data corruption or loss. Since read-only binding mounting is done at the file system level, its read-only state is permanent and does not change its state even if the system is restarted.
The dragout tool is a set of tools for automating the Linux boot process, and is mainly used for creating a Linux boot image, i.e., initrimfs. It will replicate the tools and files from the installed system and combine the dragout framework, which is typically located in/usr/lib/dragout/modules.d, to generate the boot image.
The read-only mechanism is used as a tool and a framework for managing the files of the operating system, and is used for upgrading and version control of the management operating system in the actual use process.
1. Preparing a file system
First, a file system containing the basic metadata and file contents of all the systems needs to be prepared. The file system may be extracted from an existing operating system image or may be created manually. Furthermore, to ensure the integrity, stability and availability of the file system, the following changes to the file directory are required:
1. an empty/sysroot directory should be included. When started, the read-only mechanism will mount the color binding on the physical root directory so that the read-only mechanism can consistently find system data when running, whether it is running on the physical root directory or within the deployment.
2. Since the read-only mechanism will change the/usr directory to read-only and manage it as part of the system version, and the read-only mechanism will share a/var writable directory between each version of the operating system involved in the read-only mechanism, the operating system will only keep/var during the upgrade, and the color directory deployed by each operating system will eventually be reclaimed by garbage, so some directories need to be changed to/var directory, which will not remain after the system update, so other top-level writable directories need to be modified, and since by default/var is empty, the operating system needs to dynamically create these targets at startup:
/home → /var/home
/opt → /var/opt
/srv → /var/srv
/root → /var/roothome
/usr/local → /var/usr/local
/mnt → /var/mnt
/tmp → /sysroot/tmp
2. creating an object repository
After the file system is prepared, a repository of objects with content addressing is created, which stores metadata and file content in the file system.
FIG. 1 is a logical diagram of the mechanism of an object repository: the object warehouse is the core of a read-only mechanism, which only supports recording and deploying a complete and bootable file system tree, and can track a meaningful file system tree in the object warehouse through a branching function and execute a switching branching operation, which needs to be described additionally at some point. An object repository is a local or remote repository containing multiple system versions and is organized and managed by a particular repository format.
In FIG. 1, "commit" refers to the operation of saving modifications to the relevant operating system under the current working directory as a new version, "branch" refers to the branch of the relevant operating system version, "pull & deploy" refers to the branch of the relevant operating system version pulled and deployed, hard linking (Hard link) is a way to create multiple file names in the file system that point to the same inode node. The hard link is created without allocating new disk space, but rather creating a new file name in the file system and associating it with the existing file. Because multiple filenames point to the same inode node, the files represented by these filenames are in fact the same file.
The data types of the read-only file system stored in the object repository include:
1. metadata
Metadata of each system version is stored in the object warehouse, and the metadata comprises information such as version numbers, construction dates, construction hosts, father versions and the like. Metadata is organized in a specific format, typically JSON or Cbor format. The metadata also includes branching information, signature information, and other version control related information related to the version.
2. File object
The object store also stores a file object for each system version. The file objects are a file or directory, each having a unique ID that can be used to check whether the object is present in a particular version. The file objects are organized in a specific format, typically in tar format or binary format like tar format.
The read-only mechanism realizes the object warehouse in a flexible way, can select local storage or remote storage, and can use a file system or an HTTP server for storage and transmission.
1. Local file system storage
The object store may be stored in a local file system, typically in a specific directory, e.g./repo. The object store uses a Git-style version control mechanism, with each version organized in a specific directory structure, including version metadata, file objects, and other related files.
2. Remote HTTP server storage
The object repository may also be stored on a remote HTTP server, typically using the HTTP protocol for transmission. By the method, a plurality of clients can share the same object warehouse, and team cooperation and distributed deployment are facilitated. The object repository is organized using a specific format, such as an HTTP-based static file server or an S3-based cloud storage service, etc.
3. Importation of a file system
Importing the metadata and the file content in the file system of the first step into the object warehouse of the second step, and creating a new branch.
4. Building a file system
And packaging the imported file system, writing the file system into an object warehouse, and designating the branch and version number to which the file system belongs.
Thus, each file system corresponds to a branch and version number, so multiple versions of multiple independent operating systems can be deployed and installed in parallel by using a read-only mechanism based on an object repository, and each operating system depends on a new top-level directory.
The read-only mechanism may also supplement the package manager of the system, and when installing or updating the software package, it will not change the currently running operating system, but rather assemble a new file system tree corresponding to a new system version, put the new software package (the software package is an important component of the operating system) on top, and record it in the local object repository, guiding the configuration of the new system version for the next deployment.
When the software package is installed or updated by the package manager, this operation generates a new system version and triggers an atomic upgrade of the system, each corresponding to an update of the system version, and due to the read-only mechanism, incremental updates (described in more detail below) are used. If a certain file is modified in a new version of the system, a compressed patch containing the file differences is received during updating, and the patch contains a signature of the new file for verifying whether the system updating is successful.
The object store organizes system versions using a special tree structure, each version having a unique version number and each version having one or more parent versions. The version management mode forms a Directed Acyclic Graph (DAG) between versions, and can easily realize operations such as version rollback, version switching and the like.
Fig. 2 is a flow chart of a security early warning when a key file of a system is manually modified based on a read-only mechanism provided by the invention: as shown in fig. 2, when the root directory is mounted in the container, the immutable infrastructure monitoring can determine the root directory as dangerous operation, and monitor the content in the root directory in real time, if an attacker tries to manually modify the key file of the system, the attacker can find that the file is read-only permission and cannot modify the key file, and the read-only mechanism can send out early warning information at the moment to remind the developer of illegal operation. Therefore, under the action of a read-only mechanism, even if the host machine directory is mounted in the container, malicious codes cannot easily change important files or directories of the host machine, so that the risk of escaping the container is reduced.
In the invention, the root directory is an important directory in the Linux system, is the starting point and the root node of the whole file system, and all other directories and files are relative to the root directory
Finally, the object warehouse manages the file system through branches and version numbers, so that various compression algorithms and incremental updating mechanisms can be supported, the data volume of storage and network transmission is effectively reduced, the updating cost of the operating system is reduced, and the safety and stability of the operating system are improved.
Specifically, referring to fig. 3, (in fig. 3, a "remote repository" is an object repository corresponding to be stored at a remote location) is a schematic diagram of an atomization upgrade implemented according to an incremental update mechanism based on a read-only mechanism provided by the present invention: when the software package is installed or updated by the package manager, the operation generates a new system version and triggers an atomized upgrade of the system, each upgrade corresponds to an update of the system version, and due to the read-only mechanism, an incremental update mode is adopted. If a certain file is modified in a new version of the system, a compressed patch containing the file differences is received during updating, and the patch contains a signature of the new file for verifying whether the system updating is successful.
When the system version is manufactured, each version forms a commit message and is stored in the object warehouse, and the system stores the commit message related to the version. When the system is updated, the increment difference of the version of the new and old systems is obtained through the commit information corresponding to the new and old systems, the increment difference is obtained, the downloading and updating are completed, and the commit information of the system is updated. As shown in FIG. 3, the object repository stores commit information for each version, and the current old version is based on commit n, and upon performing an atomising update, the current old version is updated incrementally by comparing the differences between commit n and the updated version, i.e., the newer version of commit n+1, while the commit information is updated. If errors occur in the updating process, the system rolls back to the old version corresponding to the limit n, and if errors do not occur, the system is updated to the updated version corresponding to the limit n+1.
Taking fig. 4 as an example, a schematic diagram of updating a file version involved in an atomization upgrade according to an embodiment of the present invention is shown: between version 1 and version 2, files A and C have been modified. When the developer extracts version 2, a signature compression patch containing A1 and C1 is received, including the differences between A and A1 and the differences between C and C1. The read-only mechanism would then generate a new directory containing a copy of file a and apply the previously generated compression patch to update the version of file a to A1. The same is done for C, with its version updated to C1 using the compression patch. File B is not altered and can be directly multiplexed. Similarly, between version 2 and version 3, the differences between C1 and C2 are applied to upgrade file C1 to C2; version 4 upgrades file A1 to A2 and file B to B1 based on version 3; version 5 upgrades B1 to B2 and C2 to C3 based on version 4.
The above steps are performed under the supervision of the immutable infrastructure and then checked by the secure trusted management platform if the updated signature matches the signature received in the compressed patch. If the two signatures do not match, the read-only mechanism will give up updating and roll back to the state of file A and file C; if the two signatures match, the read-only mechanism marks the update as successful and is used when the device is restarted. The read-only mechanism ensures that the operating system boots using file a or A1 and file C or C1 in the event of a power failure by using both the copy and update steps.
In the atomization upgrading process, the unchangeable infrastructure can monitor the state of the key files of the system in real time, if illegal updating is found, early warning is carried out in time, and updating is prevented, and the method is described by the following two cases:
case 1, as shown in fig. 5, when a developer installs or updates a software package normally, an upgrade log is generated this time after an atomization upgrade is triggered, and then a read-only mechanism (i.e., "immutable infrastructure monitoring" in fig. 5) generates a new file system tree corresponding to a new system version, and a version number and a version check code are submitted to the read-only mechanism for subsequent checking (corresponding to "new version information submission" in fig. 5). The immutable infrastructure monitors this process and compares, via the secure trusted management platform, whether the version number meets certain requirements (i.e., whether the version number is legal in fig. 5), whether the version check code matches the new version, and whether the files or directories involved in the upgrade log meet trusted requirements. After the trusted operation is judged, the system version is normally atomically updated and upgraded; if the version number is detected to be inconsistent with the requirement or the version check code is not matched with the new system version or the upgrade log is detected to be inconsistent with the requirement, the system reminds the abnormality and timely gives an early warning to the developer and stops updating.
Case 2, as shown in fig. 6: when the key files of the system are related, if an attacker wants to modify the key files of the host computer system by installing/updating software packages, the immutable infrastructure monitoring based on a read-only mechanism records the operation details of the key files in an upgrade log, including which software packages are installed and which files or directories are modified, after the log is submitted (corresponding to 'new version information submission' in fig. 6) to a safe trusted management platform, the key files of the system are detected to be modified, firstly, whether the version numbers are legal, check codes are matched or not, whether the upgrade log meets the requirements or not is automatically judged, and then early warning information is sent to inform a developer that the key files of the system are to be modified, if the key files of the system are not known by the developer, the update of the system is prevented, and the system version is atomisation updated only under the condition that the developer knows and reported after the update state is completed, so that the effect of using the safety protection and early warning of the reinforced container are achieved.
According to the file system security reinforcement method based on the read-only mechanism, security protection is provided for container use through the immutable infrastructure on the file system level, and the use security of the reinforced container is realized through read-only file system, system atomization upgrading and upgrading security early warning.
Although the present invention has been described with reference to the above preferred embodiments, it should be understood that the present invention is not limited to the above embodiments, and that various changes and modifications can be made herein without departing from the spirit and scope of the invention as defined by the appended claims.
Claims (3)
1. The file system security reinforcement method based on the read-only mechanism is characterized by comprising the following steps of:
step S1: preparing a file system needing to be reinforced for safety;
step S2: constructing an object warehouse based on a read-only mechanism;
step S3: importing the file system prepared in the step S1 into an object warehouse constructed in the step S2, and creating a new branch for the file system;
step S4: packaging the imported file system, writing the file system into an object warehouse, and designating branches and version numbers to which the file system belongs;
the object warehouse constructed in the step S3 is used for storing and managing metadata and file objects of the file systems, tracking the corresponding file systems through a branching function, and executing a switching branching operation to switch to the managed file systems;
in step S1, the prepared file system includes a read-only part and a writable part, the writable part is stored under the/etc and/var directories, the read-only part is recorded in the memory, the writable part is mounted on the read-only part, and the read-only mechanism uses a draut tool to create a read-only binding mount in the/usr directory, so as to ensure that the/usr directory is permanently in a read-only state;
in the step S1, a file system is prepared by:
step S11: creating an empty/sysroot directory in the file system, and ensuring that a read-only mechanism mounts the color bond to a physical root directory;
step S12: when the operating system is started, the following targets are dynamically created for the file system:
/home → /var/home
/opt → /var/opt
/srv → /var/srv
/root → /var/roothome
/usr/local → /var/usr/local
/mnt → /var/mnt
/tmp → /sysroot/tmp。
2. the method for reinforcing the security of a file system based on a read-only mechanism according to claim 1, wherein when a system update is performed for the file system, the method comprises the steps of: when the software package is installed or updated through the package manager, the object warehouse generates a new system version and commit information of the commit corresponding to the new system version, triggers one-time atomization upgrading of the system, compares the difference between the commit corresponding to the new system version and the commit corresponding to the system version before updating in an incremental updating mode, acquires the incremental difference and generates a compression patch containing the difference, completes updating according to the incremental difference, and updates the commit information of the current system version according to the commit information of the new system version.
3. The method for securing a file system based on a read-only mechanism according to claim 2, wherein the method for performing an update based on the delta difference when performing a system update for the file system involves: comparing the differences between the new system version and the pre-update system version to obtain all the files which have been modified, generating a new directory containing copies of the files for each file which has been modified, and updating the pre-modification file version to the modified file version by applying the compression patch generated before.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310573526.8A CN116341012B (en) | 2023-05-22 | 2023-05-22 | File system security reinforcement method based on read-only mechanism |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310573526.8A CN116341012B (en) | 2023-05-22 | 2023-05-22 | File system security reinforcement method based on read-only mechanism |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN116341012A CN116341012A (en) | 2023-06-27 |
| CN116341012B true CN116341012B (en) | 2023-08-22 |
Family
ID=86882616
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202310573526.8A Active CN116341012B (en) | 2023-05-22 | 2023-05-22 | File system security reinforcement method based on read-only mechanism |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN116341012B (en) |
Citations (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH11327981A (en) * | 1998-04-14 | 1999-11-30 | Hewlett Packard Co <Hp> | Increment file system |
| CN102033766A (en) * | 2010-12-01 | 2011-04-27 | 北京同有飞骥科技股份有限公司 | Method for updating memory operating system |
| CN102262568A (en) * | 2010-05-25 | 2011-11-30 | 上海中标软件有限公司 | Power-down prevention Linux system startup method |
| CN103309706A (en) * | 2013-05-24 | 2013-09-18 | 中标软件有限公司 | Memory file system preparation method and unit based on Linux operation system |
| CN106598576A (en) * | 2016-11-30 | 2017-04-26 | 深圳市泛海三江科技发展有限公司 | Equipment parameter updating method and device based on squashfs read-only file |
| CN106598651A (en) * | 2016-11-25 | 2017-04-26 | 上海斐讯数据通信技术有限公司 | Embedded system and upgrade method thereof |
| WO2017196974A1 (en) * | 2016-05-10 | 2017-11-16 | Nasuni Corporation | Network accessible file server |
| CN110018994A (en) * | 2017-11-02 | 2019-07-16 | 华为终端有限公司 | Method, the network equipment and the computer readable storage medium of more new file system |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US10346150B2 (en) * | 2015-10-21 | 2019-07-09 | Oracle International Corporation | Computerized system and method for patching an application by separating executables and working data using different images |
-
2023
- 2023-05-22 CN CN202310573526.8A patent/CN116341012B/en active Active
Patent Citations (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH11327981A (en) * | 1998-04-14 | 1999-11-30 | Hewlett Packard Co <Hp> | Increment file system |
| CN102262568A (en) * | 2010-05-25 | 2011-11-30 | 上海中标软件有限公司 | Power-down prevention Linux system startup method |
| CN102033766A (en) * | 2010-12-01 | 2011-04-27 | 北京同有飞骥科技股份有限公司 | Method for updating memory operating system |
| CN103309706A (en) * | 2013-05-24 | 2013-09-18 | 中标软件有限公司 | Memory file system preparation method and unit based on Linux operation system |
| WO2017196974A1 (en) * | 2016-05-10 | 2017-11-16 | Nasuni Corporation | Network accessible file server |
| CN106598651A (en) * | 2016-11-25 | 2017-04-26 | 上海斐讯数据通信技术有限公司 | Embedded system and upgrade method thereof |
| CN106598576A (en) * | 2016-11-30 | 2017-04-26 | 深圳市泛海三江科技发展有限公司 | Equipment parameter updating method and device based on squashfs read-only file |
| CN110018994A (en) * | 2017-11-02 | 2019-07-16 | 华为终端有限公司 | Method, the network equipment and the computer readable storage medium of more new file system |
Also Published As
| Publication number | Publication date |
|---|---|
| CN116341012A (en) | 2023-06-27 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN106991035B (en) | Host monitoring system based on micro-service architecture | |
| AU2005201434B2 (en) | Efficient patching | |
| US8806479B2 (en) | Creating an application virtual machine image by isolating installation artifacts in shadow area | |
| EP1598740B1 (en) | Efficient software patching | |
| US7805409B2 (en) | Dynamic composition of an execution environment from multiple immutable file system images | |
| US9244674B2 (en) | Computer system supporting remotely managed IT services | |
| US8863114B2 (en) | Managing software packages using a version control system | |
| US6971018B1 (en) | File protection service for a computer system | |
| CN106325951A (en) | Automatic deployment method for application system supporting multiple databases and multiple middleware types | |
| US20110061045A1 (en) | Operating Systems in a Layerd Virtual Workspace | |
| CN107577475A (en) | A kind of software package management method and system of data center's group system | |
| US8490078B2 (en) | System and method for application management | |
| CN110188574B (en) | Webpage tamper-proofing system and method for Docker container | |
| US20060085860A1 (en) | Versioning component for applications | |
| US7571448B1 (en) | Lightweight hooking mechanism for kernel level operations | |
| Hall | A policy-driven class loader to support deployment in extensible frameworks | |
| US11467917B2 (en) | Updating a virtual machine backup | |
| CN116341012B (en) | File system security reinforcement method based on read-only mechanism | |
| Schwarzkopf et al. | Checking running and dormant virtual machines for the necessity of security updates in cloud environments | |
| Dykstra | Apptainer Without Setuid | |
| US9389851B1 (en) | System and method for providing consistency between software library repositories | |
| Cisco | Installing and Setting Up CiscoView | |
| US20240061667A1 (en) | Incremental Image Import Process for Supporting Multiple Upstream Image Repositories | |
| Brady et al. | Dynamic Repair of Mission-Critical Applications with Runtime Snap-Ins | |
| CN115795485A (en) | Method, system, equipment and storage medium for safely delivering software in trusted cloud environment |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |