During use of the Internet, malware, spyware, and virus programs (hereinafter “MSV programs”) are often downloaded to computing devices, usually without a computing device user's knowledge. Computing devices include, but are not limited to desktop and laptop personal computers, personal digital assistants (PDAs), cellular telephones, etc. Computing devices are generically referred to hereinafter as “computer devices.” In order to safeguard the kernel, applications, user data, other programs, objects, etc., on a computer device from the malicious activities of MSV programs, a computer device user usually installs a commercially available, third party security protection product (hereinafter “SPT”). SPTs, for example Norton AntiVirus™ from Symantec™, Ad-aware® from Lavasoft AB, etc., are programs that monitor the activities of installed programs executing and objects (files and registry keys) running on the computer device, classify the programs and objects into “known good” or “known/suspected malicious” on the basis of a signature, and attempt to confine those programs that are malicious and objects that are infected by the malicious programs The problem with the monitoring, classifying, and confining the programs by the SPTs mentioned above is that the level of confinement that the SPTs can achieve is relatively limited as compared to the level of confinement that the system security reference monitor can enforce.
Current SPTs monitor the activities of programs executing and objects running on a computer device, usually from the time the computer device is powered on. Every program and object is classified by the SPT into “known good” or “known/suspected malicious” according to a match between the program image and a signature file for the SPT. Current SPTs confine the program based on a signature in the signature file. Confinement of a program (or confinement of an object infected by a malicious program) can result in the program (or object) being quarantined, deleted, or un-installed by the SPTs. In some instances, current SPTs display a dialog box notifying the computer device user of the malicious program and the objects infected by the malicious program. Based on this information, the computer device user can decide to allow the program to execute, and/or allow the infected object to remain, or to quarantine, delete, or uninstall the program and/or infected object from the computer device.
FIG. 1 is a functional flowchart illustrating exemplary actions 100 that occur when a user of a prior art computer device downloads a process to install a program. At block 101, on computer device start up, an SPT monitors the activity of all programs executing and objects running on the computer device. At block 102, the computer device user accesses the Internet and a process to install a program is downloaded to the computer device. The process is either knowingly downloaded by the computer device user, or unknowingly downloaded without the computer device user's permission. At block 103, the process installs the program. At block 104, if the SPT notices the newly installed program, at block 105 the SPT analyzes the program in order to assign the program a “known good” or “known/suspected malicious” classification (the “YES” branch from block 104). Analysis of the program may include the verification of the code origin of the program and/or the contents of a signature file of the program.
At block 106, the SPT checks to determine if the newly installed program is a malicious program (for example, an MSV program). If the newly installed program is a malicious program (the “YES” branch from block 106), at block 107 the SPT executes a mandatory (SPT specific) policy that confines the newly installed program, and warns the computer device user of the malicious program. It should be noted here that the security policy of the SPT is independent of the computer device security policy enforced by a mandatory security model integrated into an Operating System Reference Monitor (hereinafter “SRM”). At block 107, after the computer device user is warned of the malicious program, at block 108 the computer device user either allows or disallows the malicious program to execute. If the computer device user disallows (the “NO” branch from block 108) the newly installed program to execute (maybe because the computer device user unknowingly downloaded the process), at block 109 the confined program is permanently quarantined, deleted, or uninstalled by the SPT from the computer device. Next, at block 110 the computer device continues its “normal” functions.
If at block 104 the SPT does not notice the newly installed program, or at block 108 the computer device user allows the malicious program to execute, at block 111, the malicious program will execute with all the rights of the computer device user. If the computer device user is an “administrator,” the malicious program can execute any “administrator” level computer device task authorized by the operating system. This could potentially compromise the security of the computer device, especially if the malicious program manipulates data or programs that protect the integrity and/or privacy of the computer device.
Computer device users sometimes knowingly let a spyware program execute on their computer device in order to derive certain utility from the spyware program. For example, a computer device user interested in sharing multimedia files over the Internet with other computer device users may download a program to install a multimedia file sharing engine and jukebox along with a list of computer device users having the same interest from an Internet website like the KAZAA filing sharing site (hereinafter “KAZAA”). After the spyware program is executed, the spyware program cannot be confined by current SPTs as the spyware program's security privilege is the full privilege of the computer device user. In the example of the computer device user interested in sharing multimedia files over the Internet, once the program is executed, the computer device user can download a multimedia file from a computer device of another computer device user on the list. Similarly, other computer device users can download multimedia files from the computer device user's computer device. This could potentially compromise the security of the computer device user's computer device, especially if some other computer device user installs a virus program while downloading the multimedia file in order to manipulate data or programs protecting the integrity and/or privacy of the computer device user's computer device. Also, since the SPT can only monitor a limited set of programs and objects like files and registry keys running on the computer device, a program like the one from KAZAA discussed above running with the full security privileges of the computer device user may attempt to use other device objects to break out of the confinement the SPT seeks to impose. The SRM, on the other hand, is capable of fully enforcing computer device security policies on a wide range of objects, including those that current SPTs are not aware of. It is also important to note that in the case of spyware programs, the privacy of a computer device is equally important as the integrity of the computer device. Since a computer device user is concerned about programs accessing user confidential data, once a decision has been made to let a program (such as the one from KAZAA) execute, current SPTs can no longer restrict access to user confidential data since the program executes with complete rights and privileges of the computer device user.
As mentioned above, even though current operating systems implement a mandatory security model integrated into the SRM (for example the Mandatory Integrity Control in the Windows Operating System and the LINUX Security Modules in the LINUX Operating System), unfortunately, such mandatory security models do not implement the classification methods implemented by current SPTs. Consequently, the mandatory access control functionality on such a computer device is hardly ever used. On the other hand, current SPTs have a policy model that is not integrated into the computer device policy model, and thus, current SPTs do not provide the same level of isolation of malicious programs and objects infected by the malicious programs as the SRM. Consequently, it is desirable for the SRM to enforce security policy and to restrict current SPTs to provide the SRM with policy data that will help the SRM make a confinement decision. Once a decision is made to confine a malicious program or objects infected by the malicious program, the SRM is capable of providing a much higher level of enforcement than an SPT is normally capable of providing. By allowing the SRM enforce the security policy of the computer device, current SPTs are de-privileged. Further, the security damage that a compromised SPT can do to the computer device is restricted. Allowing the SRM enforce the security policy of the computer device is in contrast to current SPTs that install device drivers in order to confine malicious programs, and where a compromise in the SPTs result in a complete compromise of the trusted computing base (hereinafter “TCB”).
USPTO Backgrounds
USPTO Backgrounds