Patent ID: 12210612

DETAILED DESCRIPTION

Representative applications of methods and apparatus according to the present application are described in this section. These examples are being provided solely to add context and aid in the understanding of the described embodiments. It will thus be apparent to one skilled in the art that the described embodiments may be practiced without some or all of these specific details. In other instances, well known process steps have not been described in detail in order to avoid unnecessarily obscuring the described embodiments. Other applications are possible, such that the following examples should not be taken as limiting.

In the following detailed description, references are made to the accompanying drawings, which form a part of the description and in which are shown, by way of illustration, specific embodiments in accordance with the described embodiments. Although these embodiments are described in sufficient detail to enable one skilled in the art to practice the described embodiments, it is understood that these examples are not limiting; such that other embodiments may be used, and changes may be made without departing from the spirit and scope of the described embodiments.

One embodiment sets forth a technique for enabling secure/ongoing execution of applications that are distributed in the form of application archive files. An application archive file for a given software application can include a file system data structure that describes (1) file system content (e.g., various files of which the software application is comprised), and (2) file system security information (e.g., cryptographic information that corresponds to the file system content and/or the file system data structure). The relationships and dependencies between the foregoing entities of the application archive file render the application archive file largely immutable in that each entity cannot be modified without invalidating another. To facilitate a secure execution of a given software application, an operating system (OS) first makes the application archive file for the software application accessible. To achieve this end, the OS incorporates the application archive file into an overarching file system that is mounted to encompass various application archive files for applications that are executing by way of the OS. More specifically, incorporating the application archive file into the overarching file system involves retrieving the file system data structure of the application archive file and associating it with a respective file system data structure of the overarching file system. The foregoing incorporation/association is collectively referred to herein as a “graft.” Through this graft, the application archive file (and its contents) becomes accessible by way of overarching file system and eliminates the need to establish individual mount points for application archive files for respective software applications as they are launched and utilized, which otherwise would be time and resource intensive. Moreover, this approach enables the OS to efficiently validate the file system data structure/file system content against the file system security information in relation to the execution of the application, which provides considerable enhancements to the overall level of security that can be provided.

Another embodiment sets forth a technique for updating software applications despite their corresponding application archive files being immutable. In particular, to update a given software application, the file system data structure (of the application archive file of the software application) is removed from the respective file system data structure of the overarching file system if/when the software application is executing when the update is to be performed. Subsequently, the file system data structure, the file system content, and the file system security information of the application archive file are updated in accordance with a software update directed to the software application. In turn, an updated application archive file is generated for the updated file system data structure, the updated file system content, and the updated file system security information. Subsequently, the grafting techniques described herein can be carried out to enable the updated software application to execute in a secure manner using the updated application archive file in accordance with the other security-focused techniques described herein.

Yet another embodiment sets forth a technique for enabling clean uninstallations of software applications on a computing device. This technique involves limiting the boundaries under which a given software application can operate such that the software application—at least by default—is only permitted to access its own file system content included in the corresponding application archive file of the software application. However, during execution, the software application can be permitted to issue requests to the OS to access locations outside of its corresponding application archive file. If the OS deems that a given request to access a given outside location is permissible, then the OS associates the outside location with the file system data structure of the application archive file using the grafting techniques described herein. In turn, the completed grafting techniques permit the software application to interact with the outside location without modifying the content of the application archive file of the software application. Accordingly, the software application can be permitted to interact with outside locations while being limited in its ability to write data to such outside locations. In this manner, a given software application can be cleanly uninstalled simply by deleting the corresponding application archive file, considering that the software application was never permitted to establish files in other locations outside of the application archive file.

FIG.1illustrates an overview100of a computing device101that can be configured to perform the various techniques described herein, according to some embodiments. The computing device101can represent a smartphone, tablet, laptop, desktop, display, watch, media player, or any other suitable computing device. As shown inFIG.1, the computing device101can include a storage device102, which can represent a hard disk drive, a solid-state drive, a combination of drives, and the like. As also shown inFIG.1, the computing device101can include a memory150into which an operating system (OS)152/application archive files154can be loaded and executed by at least one processor (not illustrated inFIG.1) to perform the various techniques described herein.

According to some embodiments, the storage device102can be configured to include a partition table104that is used to define the manner in which one or more partitions106are established within the storage device102. Notably, although the drawings and the accompanying descriptions indicate multiple partitions, the embodiments described herein are not so limited. Instead, the storage device102can be configured to include a single/global partition that spans all of the physical storage blocks (i.e., contiguous sequences of bytes/bits) in the storage device102without departing from the scope of this disclosure.

As shown inFIG.1, each partition106can be configured to include a container108, which can be configured to include a manager122, a file system volume table124, and one or more file system volumes126. According to some embodiments, the manager122represents a combination of logic (e.g., an Application Programming Interface (API)) as well as information for managing various aspects of the operation of the container108in which the manager122is included. For example, the manager122can be utilized (e.g., by the operating system152—or other entity executing at the computing device101/connected to the computing device101) to create, modify, and delete file system volumes126within the container108. Moreover, the manager122can be utilized to service input/output (I/O) requests issued by different file system volumes126for storage space management, e.g., storage space allocation requests, storage space deletion requests, and the like. Moreover, the manager122can be configured to maintain crash protection information as a unified checkpoint log in accordance with the aforementioned I/O requests that the manager122is configured to handle. Additionally, the manager122can be configured to implement the file system volume table124as a way to manage the file system volumes126within the container108. For example, the manager122can reference the file system volume table124when servicing requests to add, modify, or delete file system volumes126within the container108to identify how/whether the requests should be properly handled.

Accordingly, the partitions106/containers108can be utilized to implement various file system volumes126within the storage device102of the computing device101. According to some embodiments, and as shown inFIG.1, the operating system152can exist within an operating system file system volume151that is mounted at the computing device101, where the operating system file system volume151represents an instantiation of a file system volume126. Additionally, and according to some embodiments, one or more application archive files154can exist within an application file system volume153that is also mounted at the computing device101, where the application file system volume153represents an instantiation of another file system volume126. According to some embodiments, the operating system file system volume151and the application file system volume153are separately mounted in order to establish separate sandboxed environments in which the operating system152and the application archive files154, respectively, can exist and provide functionality to the computing device101. This approach coincides with the general goal of making the operating system152and the application archive files154immutable in nature. However, it should be noted that the embodiments set forth herein do not rely on or require separately mounted file system volumes126. On the contrary, a single file system volume126can be mounted to incorporate the operating system152and the application archive files154without departing from the scope of this disclosure.

According to some embodiments, and as shown inFIG.1, each application archive file154can include a file system data structure162, file system content164, and file system security information166. According to some embodiments, the file system data structure162can store information about (1) the file system content164, and (2) file system security information166. For example, the file system data structure162can include various data structures (e.g., tables, trees, lists, etc.) that define a manner in which the file system content164—e.g., various files, directories, etc.—are related to one another and hierarchically organized. The file system data structure162can also include information pertaining to the storage locations of the various files, directories, etc., within the storage device102, e.g., physical storage block addresses, offsets, and the like. Additionally, and as described in greater detail herein, the file system security information166can define security-related information—e.g., a hash tree, a hash list, a hash chain, etc.—that corresponds to the file system data structure162and/or the file system content164. In particular and, as described in greater detail below in conjunction withFIGS.2A-2F—the file system security information166can include cryptographic information that coincides with the (1) hierarchical structures of the file system data structure162and/or file system content164, as well as (2) the data stored therein. In this manner, the contents of the file system data structure162and/or file system content164can be independently analyzed and validated against the file system security information166to detect changes, if any, that have been made relative to the original state of the application archive file154. As a result, an increased level of security can be provided by taking defensive measures any time unauthorized changes are detected within a given application archive file154.

FIGS.2A-2Fillustrate conceptual diagrams of an example scenario for detecting changes to file system content164of an application archive file154, according to some embodiments. As shown inFIG.2A, an initial step (0) illustrates example data stored within the application archive file154. In particular, the file system content164consists of four separate and distinct files (File1, File2, File3, and File4). Additionally, the file system data structure162stores hierarchical information that defines the manner in which the four separate and distinct files (File1, File2, File3, and File4) are hierarchically organized within directories. As shown inFIG.2A, the hierarchical information stems from a root node that functions as an entry point/root directory and indicates that File1and File2are stored within a first directory, Directory1, while File2and File3are stored within a second directory, Directory2. It is noted that the file system content164/file system data structure162illustrated inFIG.2Ais merely exemplary and not meant to be limiting, and that any number of files/directories, under any hierarchical organization, can be managed without departing from the scope of this disclosure.

Additionally, and as shown inFIG.2A, the file system security information166—which complements the file system content164—includes data that defines (1) individual hash values (e.g., computed using SHA-2 or other hash functions) that correspond to the files within the file system content164, as well as (2) organizational information that defines how the individual hash values are hierarchically organized and related to one another.

As a brief aside, it is noted that the file system security information166can be generated by a distribution entity that distributes the application archive file154to the computing device101and that presumably can be trusted by the computing device101. For example, the distribution entity can receive, from an application developer, an application archive file154that includes only the file system data structure162and the file system content164. In turn, the distribution entity can generate the system security information166that corresponds to the file system data structure162and/or file system content164and then incorporate the file system security information166into the application archive file154. Subsequently, the application archive file154can be distributed to the computing device101. At that juncture, the computing device101—which views the distribution entity as a trusted source—can rely on the file system security information166to effectively detect (using the techniques described below) unauthorized changes that are made to the file system data structure162and/or file system content164. It is noted that entities other than distribution entities—e.g., trusted software developers—can generate the file system security information166without departing from the scope of this disclosure.

Turning back now toFIG.2A, the file system security information166takes the form of a hash tree, where the leaf nodes—such as Hash0-0, Hash0-1, Hash1-0, and Hash1-1—represents hashes of data of which File1, File2, File3, and File4, respectively, are comprised. Nodes further up in the tree—such as Hash0, Hash1, and Top Hash—are combined hashes of their respective children. For example, in the file system security information166illustrated inFIG.2A, Hash0is the result of hashing the concatenation of Hash0-0and Hash0-1, Hash1is the result of hashing the concatenation of Hash1-0and Hash1-1, and Top Hash is the result of hashing the concatenation of Hash0and Hash1. It is noted that although most hash tree implementations are binary—i.e., two child nodes under each node, as depicted inFIG.2A—they can just as well use any number of child nodes under each node without departing from the scope of this disclosure.

Turning now toFIG.2B, a first step (1) involves receiving a read request for File3of the file system content164. As shown inFIG.2B, and as previously described herein, Hash1-0within the file system security information166corresponds to File3of the file system content164. Accordingly, to effectively determine whether File3has been modified—e.g., relative to original state of the application archive file154as it was received by the computing device101— the computing device101is tasked with procuring a hash of File3. However, because Hash1-0corresponds to the file that is being validated (i.e., File3), Hash1-0is not obtained from the file system security information166itself, but rather is independently generated by the computing device101using the same hash function that was used (e.g., by the distribution entity) to generate the nodes within the file system security information166. In turn, the computing device101utilizes the independently generated Hash1-0to perform sequential/upward validations of the other nodes within the file system security information166to effectively determine whether File3has been modified. An example of such validations are described below in conjunction withFIGS.2C-2F.

As shown inFIG.2C, a second step (2) involves the computing device101independently generating Hash1-0based on File3. In turn, Hash1-1is obtained from the file system security information166, as it will be needed (along with Hash1-0) to independently generate Hash1. As shown inFIG.2D, a third step (3) involves the computing device101independently generating Hash1using Hash1-0(independently generated by the computing device101) and Hash1-1(obtained from the file system security information166itself). Additionally, the computing device101obtains Hash0from the file system security information166, as it will be needed (along with Hash1) by the computing device101to independently generate the Top Hash. A fourth step (4) illustrated inFIG.2Einvolves the computing device101independently generating the Top hash based on Hash0(obtained from the file system security information166) and Hash1(independently generated by the computing device101). In turn, a fifth step (5) illustrated inFIG.2Finvolves the computing device101verifying that the independently generated Top Hash is equal to the Top Hash included in the file system security information166.

Accordingly, if an equivalency is found, then the computing device101can conclude that File3has not been modified, so long as it can be assumed that the file system security information166itself has not been correspondingly manipulated. If an equivalency is not found, then the computing device101can conclude that File3has been modified and take remedial steps to mitigate the situation. This can include, for example, refusing to provide File3in response to the read request, issuing a request to a kernel of the computing device101to immediately kill the execution of the software application that corresponds to the application archive file154, issuing a warning to a user of the computing device101(or any other person/entity), issuing a warning to a developer of the software application, and so on. It is noted that the foregoing examples are not meant to be limiting, and that any remedial steps can be implemented without departing from the scope of this disclosure.

Accordingly,FIGS.2A-2Fillustrate conceptual diagrams of an example scenario for detecting changes to file system content164of an application archive file154, according to some embodiments. It is noted that although these conceptual diagrams focus on validating file system content164using file system security information166, the application archive file154can also include content that enables the file system data structure162to be validated. For example, the file system security information166can include additional cryptographic content that corresponds to the file system data structure162(e.g., as illustrated inFIG.1), or such additional cryptographic content can be included in additional file system security information within the application archive file154, without departing from the scope of this disclosure. In this manner, the computing device101can be capable of detecting any unauthorized changes that are made to the file system data structure162and/or the file system content164.

FIGS.3A-3Fillustrate conceptual diagrams of an example scenario for securely executing a software application, according to some embodiments. As shown inFIG.3A, an initial step (0) illustrates an initial state of the computing device101, where the operating system152has been loaded but no software applications are executing. As previously described above in conjunction withFIG.1, the operating system152can exist within the operating system file system volume151mounted at the computing device101. Additionally, and as shown inFIG.3A, the operating system FS volume151can include an operating system FS data structure302that stores hierarchical information that defines the manner in which files and directories of which the operating system152are organized. As previously described herein, the hierarchical information stems from a root node (illustrated inFIG.3Aas the OS FS Root) that functions as an entry point/root directory and indicates that Files1-Y are stored within a first directory (Directory1) while Files1-Z are stored within a second directory (Directory2). It is noted that the operating system FS data structure302illustrated inFIG.3Ais merely exemplary and not meant to be limiting, and that any number of files/directories, under any hierarchical organization, can be managed without departing from the scope of this disclosure.

Turning now toFIG.3B, a first step (1) involves the operating system152receiving a request to launch a software application (illustrated inFIG.3Bas Application_1). In one example, the request is generated during a startup procedure of the operating system152when loading software applications that are native to the operating system152. In another example, the request is generated in response to an input to launch Application_1, e.g., stemming from a user selecting an icon, one or more conditions being satisfied, and so on. It is noted that the foregoing examples of how requests can be generated are not meant to be limiting, and that any technique for generating requests can be utilized without departing from the scope of this disclosure.

As shown inFIG.3B, the operating system152can access the storage device102to obtain the application archive file154that corresponds to Application_1, which is illustrated inFIG.3Bas Application_1Archive. As described herein, the application archive file154can include a file system data structure162, file system content164, and file system security information166. Again, these components collectively enable the operating system152to validate the file system data structure162and/or the file system content164both prior to and during the execution of the software application in an effort to thwart malicious activity.

Turning now toFIG.3C, a second step (2) involves the operating system152mounting the application file system volume153. As described above in conjunction withFIG.1, the operating system file system volume151and the application file system volume153can be separately mounted in order to establish separate sandboxed environments in which the operating system152and the application archive files154, respectively, can exist and provide functionality to the computing device101. This approach coincides with the general goal of making the operating system152and the application archive files154immutable in nature. However, it should be noted that the embodiments set forth herein do not rely on or require separately mounted file system volumes126. On the contrary, a single file system volume126can be mounted to incorporate the operating system152and the application archive files154without departing from the scope of this disclosure.

As shown inFIG.3C, the application file system volume153can include an application FS data structure312. As previously described herein, the FS data structures of volumes/application archive files typically store hierarchical information that defines the manner in which files and directories of the software entities that correspond to the volumes/application archive files are organized. However, under the approach illustrated inFIGS.3A-3F, the application file system volume153is not mounted/utilized for a single software entity—e.g., the operating system152, a particular application archive file154, etc.—but rather for multiple application archive files154to be accessible under a single mount point. In this regard, the application file system volume153, when initially mounted, includes only a root node (illustrated inFIG.3Aas the Application FS Root), not a collection of files and directories. In this regard, the root node functions as an entry point/root directory through which application archive files154of software applications can be accessed as they are initialized and incorporated into the application file system volume153/application FS data structure312, the details of which are described below in conjunction withFIGS.3D-3F.

Turning now toFIG.3D, a third step (3) involves making the application file system volume153/application FS data structure312accessible to the operating system152. This can involve, for example, updating the OS FS Root to include a reference to the application file system volume153/application FS data structure312, updating permissions managed by the operating system152, and so on. It is noted that the foregoing steps are merely exemplary and not meant to represent an exhaustive list, and that any approach for permitting the operating system152to access the separate and distinct mount point associated with the application file system volume153can be implemented without departing from the scope of this disclosure.

Turning now toFIG.3E, a fourth step (4) involves the operating system152incorporating the application archive file154(Application_1Archive) into the application file system volume153to make the application archive file154accessible to the operating system152. According to some embodiments, the incorporation can be achieved by linking the file system data structure162of the application archive file154(Application_1Archive) to the Application FS Root within the application FS data structure312. Such linkage can be established using any approach, including by associating the Application FS Root with a pointer to the file system data structure162of the application archive file154(Application_1Archive), updating a configuration of the application FS data structure312, and the like. This incorporation/association constitutes the grafting technique previously described herein. Through this graft, the application archive file154(Application_1Archive) and its contents become accessible by way of the application file system volume153/application FS data structure312. This eliminates the need to establish an individual mount point for the application archive file154(Application_1Archive) (as well other mount points for other software applications to be executed on the computing device101), which is otherwise time and resource intensive.

At the conclusion of the fourth step (4) illustrated inFIG.3E, the application archive file154(Application_1Archive) has effectively been grafted into the application FS data structure312, thereby making the application archive file154(Application_1Archive) (and its contents) accessible by way of the mount point associated with the application file system volume153. In this regard—and, in accordance with making the application file system volume153accessible to the operating system152in the third step (3) ofFIG.3D—the operating system152now is able to access the application archive file154(Application_1Archive) and its contents. This notion is illustrated inFIG.3Fat a fifth step (5).

At the conclusion of the fifth step (5) ofFIG.3F, the operating system152can take the necessary steps to launch Application_1, which includes loading into memory all files (by way of the file system data structure162and file system content164) that are required to effectively execute the application. Notably, the file system security information166of the application archive file154(Application_1Archive) is also accessible to the operating system152and can be utilized at any level of granularity to validate the file system data structure162and/or file system content164as the files are loaded into memory. In this manner, the operating system152can efficiently identify when files have been manipulated (e.g., using the techniques described above in conjunction withFIGS.2A-2F) and take appropriate remedial action.

FIGS.4A-4Billustrate a method400for securely executing an application, according to some embodiments. As shown inFIG.4A, the method400begins at step 402, where the operating system152receives a request to launch an application (e.g., as described above in conjunction withFIG.3B). According to some embodiments, the request includes a reference to an archive file that includes a second data structure that: (1) defines an organization of a plurality of files associated with the application, and (2) includes cryptographic information for verifying the plurality of files and the second data structure (e.g., as described above in conjunction withFIG.3B). At step 404, the operating system152—in response to receiving the request— determines whether the second data structure, the plurality of files, or both, are valid using the cryptographic information (e.g., as described above in conjunction withFIGS.2B-2F). At step 406, the operating system152—in response to determining that the second data structure, the plurality of files, or both, are valid—associates the second data structure with the first data structure (e.g., as described above in conjunction withFIGS.3C-3F).

Additionally, as show in4B at steps 410-414 illustrate a continuation of method400, and set forth a technique for processing an update for the application, according to some embodiments. In particular, at step 410, the operating system152receives an update for the application to produce an updated application. At step 412, the operating system152updates the second data structure based on the update to produce a modified second data structure that: (1) defines an organization of an updated plurality of files associated with the application, and (2) includes second cryptographic information for verifying the updated plurality of files and the modified second data structure. In turn, at step 414, the operating system152associates the modified second data structure with the first data structure to enable the updated application to securely execute by way of the filesystem volume.

FIG.5illustrates a method500for managing application executions to facilitate comprehensive uninstallations, according to some embodiments. As shown inFIG.5, the method500begins at step 502, where the operating system152executes an application, where (1) the application is associated with (i) a plurality of files of which the application is comprised, and (ii) a data structure that defines an organization of the plurality of files, and (2) the application executes in a secure mode such that the application is only permitted to access the plurality of files by way of the data structure. At step 504, the operating system152receives, from the application, a request to interact with at least one resource external to the data structure, at step 506, the operating system152—in response to validating the request—associates the at least one resource with the data structure.

FIG.6is a block diagram of a computing device600that can represent the components of the computing device101(ofFIG.1) or any other suitable device or component for realizing any of the methods, systems, apparatus, and embodiments described herein. It will be appreciated that the components, devices, or elements illustrated in and described with respect toFIG.6may not be mandatory and thus some may be omitted in certain embodiments. As shown inFIG.6, the computing device600can include a processor602that represents a microprocessor, a coprocessor, circuitry and/or a controller for controlling the overall operation of computing device600. Although illustrated as a single processor, it can be appreciated that the processor602can include a plurality of processors. The plurality of processors can be in operative communication with each other and can be collectively configured to perform one or more functionalities of the computing device600as described herein. In some embodiments, the processor602can be configured to execute instructions that can be stored at the computing device600and/or that can be otherwise accessible to the processor602. As such, whether configured by hardware or by a combination of hardware and software, the processor602can be capable of performing operations and actions in accordance with embodiments described herein.

The computing device600can also include user input device604that allows a user of the computing device600to interact with the computing device600. For example, user input device604can take a variety of forms, such as a button, keypad, dial, touch screen, audio input interface, visual/image capture input interface, input in the form of sensor data, etc. Still further, the computing device600can include an output608that can be controlled by processor602. The output608can include a display device, audio device, haptic feedback device, or any other output device suitable for providing output to a user of a device. Controller610can be used to interface with and control different equipment through equipment control bus612. The computing device600can also include a network/bus interface614that couples to data link616. Data link616can allow the computing device600to couple to a host computer or to accessory devices. The data link616can be provided over a wired connection or a wireless connection. In the case of a wireless connection, network/bus interface614can include a wireless transceiver.

The computing device600can also include a storage device618, which can have a single disk or a plurality of disks (e.g., hard drives) and a storage management module that manages one or more partitions within the storage device618. In some embodiments, the storage device618can include flash memory, semiconductor (solid state) memory or the like. Still further, the computing device600can include Read-Only Memory (ROM)620and Random-Access Memory (RAM)622. The ROM620can store programs, code, instructions, utilities, or processes to be executed in a non-volatile manner. The RAM622can provide volatile data storage, and store instructions related to components of the storage management module that are configured to carry out the various techniques described herein. The computing device600can further include data bus624. Data bus624can facilitate data and signal transfer between at least processor602, controller610, network/bus interface614, storage device618, ROM620, and RAM622.

The various aspects, embodiments, implementations or features of the described embodiments can be used separately or in any combination. Various aspects of the described embodiments can be implemented by software, hardware or a combination of hardware and software. The described embodiments can also be embodied as computer readable code on a computer readable storage medium. The computer readable storage medium can be any data storage device that can store data, which can thereafter be read by a computer system. Examples of the computer readable storage medium include read-only memory, random-access memory, CD-ROMs, HDDs, DVDs, magnetic tape, and optical data storage devices. The computer readable storage medium can also be distributed over network-coupled computer systems so that the computer readable code is stored and executed in a distributed fashion. In some embodiments, the computer readable storage medium can be non-transitory.

The foregoing description, for purposes of explanation, used specific nomenclature to provide a thorough understanding of the described embodiments. However, it will be apparent to one skilled in the art that the specific details are not required in order to practice the described embodiments. Thus, the foregoing descriptions of specific embodiments are presented for purposes of illustration and description. They are not intended to be exhaustive or to limit the described embodiments to the precise forms disclosed. It will be apparent to one of ordinary skill in the art that many modifications and variations are possible in view of the above teachings.