System and method for protecting files on a computer from access by unauthorized applications

[0001] Priority is claimed to provisional application No. 60/535,213 filed on Jan. 9, 2004, entitled System and Method for Protecting Files on a Computer From Being Accessed by Unauthorized Applications, which is incorporated herein by reference.

[0002] The present invention relates to systems and methods for protecting computer files and/or data from being accessed by unauthorized applications, devices, or entities.

[0003] Personal computers and business computers are continually attacked by trojans, viruses, backdoors, exploits, and other harmful or unwanted programs. These programs can alter a user's computer files by adding or deleting data. And in other instances, these programs can read the data stored in a computer file and report it to a remote system. For example, a trojan could read a list of contacts stored in a file corresponding to MICROSOFT OUTLOOK and report those contacts to a spammer. Similarly, a trojan could read personal financial data from a MICROSOFT EXCEL file and report it to a remote computer.

[0004] Software and techniques, including antivirus products, anti-spyware and anti-malware products, exist to screen for malicious programs. Antivirus and anti-malware products generally create a definition library that includes definitions for known malicious programs. Unfortunately, antivirus and anti-malware products that rely on definition libraries are often vulnerable to new viruses, trojans, exploits, and malware products. Moreover, users that do not update their definition libraries frequently are vulnerable to known viruses, trojans, exploits, spyware and malware products.

[0005] With the increase in attacks on personal computers, cell phones, personal digital assistants, and the like, additional protection is needed to monitor the behavior of applications running or attempting to run on a computer system.

[0006] A method for limiting access to a data file is disclosed. One embodiment of the method receives a request from an application to access the data file; identifies the application that generated the request; identifies the extension associated with the data file; and based on the identified extension associated with the data file, determines that the application is not permitted to access the data file.

[0007] Various objects and advantages and a more complete understanding of the present invention are apparent and more readily appreciated by reference to the following Detailed Description and to the appended claims when taken in conjunction with the accompanying Drawings wherein:

[0008] FIG. 1 is a block diagram of one embodiment of the present invention;

[0009] FIG. 2 is a block diagram of the data access module shown in FIG. 1;

[0010] FIG. 3 is a block diagram of the access deny module shown in FIG. 2;

[0011] FIG. 4 is a flow chart of one method for blocking file access; and

[0012] FIG. 5 is a flow chart of another method for blocking file access.

[0013] Referring now to FIG. 1, it illustrates a high-level block diagram of one embodiment 100 of the invention. This diagram includes three basic components: an application 105, a data access module 110, and data files 115. These three components can reside on a single computer system or can be distributed across multiple computer devices. For example, a typical system could include a personal computer with a WINDOWS, LINUX or other operating system. The application 105, which could include a consumer program such as MICROSOFT WORD, can resides on the personal computer. Similarly, the data access module 116 could also be located on the personal computer. And finally, the data files 115 could reside on the personal computer's hard drive or in memory. Notably, other embodiments of this system include distributed memory systems for storing the data files 115 and/or electronic systems such as personal digital assistants and/or cell phones instead of personal computers.

[0014] Regardless of the particular hardware used, the basic operation of this embodiment of the present invention allows the data access module 110 to deny the application 105 access to certain data files. The data access module 110 decides which files the application 105 can access based, for example, on the extension of the requested file and a list of permissions for the application or file type. For example, a MICROSOFT WORD application would have permission to access files with the extension “.doc.” The data access module 110, however, could prevent other applications from accessing files with the “.doc” extension without authorization from the user. Thus, the data access module 110 creates a “file wall” that prevents certain application 105 from accessing certain files or certain file types.

[0015] By creating the “file wall,” the data access module 110 serves as an extra level of protection beyond typical definition-based protection software. The data access module 110 provides protection against new viruses, trojans, etc. because it does not rely exclusively on definitions.

[0016] Referring now to FIG. 2, it is a more detailed block diagram of the data access module 110 of FIG. 1. This embodiment of the data access module includes four modules: access monitor module 120, permission lookup module (connected with a lookup table 130), an access grant module 135, and an access deny module 140. These four modules together control access to data files 115 based on the application 105 requesting access to those data files.

[0017] The access monitor module 120 generally runs as a background process and is generally executed upon computer or device startup. The access monitor module 120 can be configured to detect a request for a data file and pass the information regarding that request on to the permission lookup module 125. For example, the module 120 can run as a background process and monitors file access requests (e.g., read/write/delete/modify/append) by applications running at any time.

[0018] In certain embodiments, the access monitor module 120 is configured to monitor for only certain types of requests. For example, the access monitor module 120 can be configured to monitor for requests related to certain file types or certain memory blocks. And any requests not falling in the file type or memory block range can be ignored by the “file wall” and handled according to the typical data retrieval method for that computer or device.

[0019] The permission lookup module 125 is generally responsible for determining whether the application 105 requesting a data file is permitted to access that data file. For example, the permission lookup module 125 could determine whether a downloaded game is permitted to access MICROSOFT WORD files. To make this type of determination, the permission lookup module 125 determines the identity of the application requesting access to the data file. Typically, the access monitor module 120 passes this information to the permission lookup module 125. The permission lookup module 125, however, could have the ability to determine the identity of the application on its own.

[0020] Once the permission lookup module 125 knows the type of application making the data request or its name, the permission lookup module 125 accesses the lookup table and determines which types of files the application is authorized to access. For example, the lookup table 130 could include a list of applications and file extensions corresponding to the type of files that each application can access. If an application is authorized to access the type of file corresponding to the request, then access is granted. And if the application is not authorized to access the type of file corresponding to the request, then access is denied.

[0021] In an alternate embodiment, the permission lookup module 125 indexes the lookup table 130 through the file extension corresponding to the requested data file. The lookup table 130 can then return a list of approved applications. The permission lookup module 125 can then compare the requesting application against the list of approved applications.

[0022] During installation (or through an options menu), the lookup table 130 portion of this permission lookup module 125 could, at the user's option, be automatically propagated based on default file extension matching. This means that the default applications that have been assigned associated file types in the operating system would be allowed permission in the database. For example, MS-WORD would automatically be allowed permission to access files that have a “.doc” file extension.

[0023] The access grant module 135 permits the data request to be executed in its normal fashion. The access deny module 135, however, blocks the requested file access. In certain embodiments, the access deny module 135 can ask the user whether the file access should be permitted. And if the user permits the access, a corresponding entry can be added to the lookup table 130. But if the user denies access, then the data request is blocked. In certain embodiments, an appropriate entry can be added to the lookup table 130 to indicate that the application does not have permission to access data files of the requested type.

[0024] When triggered, the access deny module 140 can take various actions to prevent the application from accessing the specific file. For example, it could take one or more of the following actions: locking the file by opening it; renaming the file; and/or sending an over-ride signal to the operating system to cancel the file access request.

[0025] Referring now to FIG. 3, it is a block diagram of the access deny module 140 shown in FIG. 2. This embodiment of the access deny module 140 includes three modules: application identifier 145, quarantine/removal module 150, and the reporting module 155 (which communicates with the lookup table 130).

[0026] The first module, the application identifier module 145, is responsible for identifying the application that is requesting access to a data file. Identification can usually be done by extracting the application name from the data request. This information can be passed to the quarantine/removal module 150.

[0027] The quarantine/removal module 150 is responsible for quarantining and/or removing applications that improperly attempt to access data files. Assuming that a user indicates that the application attempting to access the data file does not have permission to do so the quarantine/removal module 150 can quarantine and remove the offending application. For example, the quarantine/removal module 150 could change the application name and move it to an alternate location. And if necessary, this module 150 could uninstall the program using, for example, the WINDOWS uninstall feature or a similar feature for another operating system.

[0028] In some cases, an application may attempt to improperly access a data file even though the application is otherwise wanted by the user. In these cases, the reporting module 155 can add an entry to the lookup table 130 to indicate that this application should never be given access to files of a certain type.

[0029] Referring now to FIG. 4, it is a flow chart of one method for blocking file access. In this method, an application requests access to a data file. The request is intercepted, and the requesting application is identified. (Blocks 160 and 165) Next, the identified application is compared with the data file type to determine whether the application has permission to access data files of this type. (Block 170) Assuming that the application has permission, the data request is passed through for traditional handling. And if the application does not have permission to access the data file or the type of data file, then the data access request is denied. (Block 175) In certain embodiments, the requesting application is then quarantined or removed. (Block 180) Information about the application can also be reported to a remote facility or a local database so that a definition can be created and passed to anti-spyware programs. (Block 185).

[0030] Referring now to FIG. 5, it is a flow chart of another method for blocking file access. In this method, a request to access a data file is intercepted, the requesting application identified, and the permission checked as in the previously described method. (Blocks 190, 195 and 200) In this method, however, the user is provided with the ability to manually allow or deny access. (Block 205) If the user allows access, then the data request is permitted. But if the user denies access, the requesting program can be quarantined and removed. (Block 210).

[0031] In conclusion, the present invention provides, among other things, a system and method for protecting electronic devices and stored data. Those skilled in the art can readily recognize that numerous variations and substitutions may be made in the invention, its use and its configuration to achieve substantially the same results as achieved by the embodiments described herein. Accordingly, there is no intention to limit the invention to the disclosed exemplary forms. Many variations, modifications and alternative constructions fall within the scope and spirit of the disclosed invention as expressed in the claims.