Access control system and method

Abstract

A computer security technique is described. One example provides a security module that runs on a computing system and determines whether a user or a program associated with the user (e.g., a native executable file) should be allowed to access a resource, such as by reading, writing, or executing a file. An exemplary operating system provides a new system management mechanism that enforces rights and restrictions for specific administrative and application groups, each with its own superuser. Such a system may include a safe mode superuser that must log in when the system is in maintenance mode (e.g., single-user console mode), at which time the safe mode superuser is the only user allowed to make programs executable.

Description

[Technical Field]

[0001] (CROSS-REFERENCE TO RELATED APPLICATIONS) This application claims priority from U.S. Patent Application No. 18 / 113,037, the contents of which are incorporated herein by reference.

[0002] The present disclosure relates to methods, techniques, and systems for computer security, and more particularly to methods, techniques, and systems for inhibiting, controlling, or limiting the execution of malicious software or access to files or databases based on a novel system administration mechanism that enforces rights and restrictions for specific administrative and application groups, each with its own superuser. [Background technology]

[0003] Hackers, disgruntled employees, and other malicious parties are increasingly attempting to break into computing systems operated by home users, businesses, or governments. Often, hackers attempt to install and run malicious software on targeted computing systems. Malicious software (e.g., viruses, Trojan horses, worms, etc.) can be used by hackers to damage, control, gain access to, or otherwise compromise a computing system. It is also beneficial to prevent hackers or disgruntled employees from copying files, databases, etc. [Brief explanation of the drawings]

[0004] [Figure 1A] 1 is a flowchart illustrating a process performed by an exemplary embodiment. [Figure 1B] 1 is a flowchart illustrating a process performed by an exemplary embodiment. [Figure 1C] 1 is a flowchart illustrating a process performed by an exemplary embodiment. [Figure 1D]1 is a flowchart illustrating a process performed by an exemplary embodiment. [Figure 1E] 1 is a flowchart illustrating a process performed by an exemplary embodiment. [Figure 1F] 1 is a flowchart illustrating a process performed by an exemplary embodiment. [Figure 1G] 1 is a flowchart illustrating a process performed by an exemplary embodiment. [Figure 1H] 1 is a flowchart illustrating a process performed by an exemplary embodiment. [Figure 1I] 1 is a flowchart illustrating a process performed by an exemplary embodiment. [Figure 1J] 1 is a flowchart illustrating a process performed by an exemplary embodiment. [Figure 1K] 1 is a flowchart illustrating a process performed by an exemplary embodiment. [Figure 1L] 1 is a flowchart illustrating a process performed by an exemplary embodiment. [Figure 1M] 1 is a flowchart illustrating a process performed by an exemplary embodiment. [Figure 1N] 1 is a flowchart illustrating a process performed by an exemplary embodiment. [Figure 1O] 1 is a flowchart illustrating a process performed by an exemplary embodiment. [Figure 1P] 1 is a flowchart illustrating a process performed by an exemplary embodiment. [Figure 1Q] 1 is a flowchart illustrating a process performed by an exemplary embodiment. [Figure 1R] 1 is a flowchart illustrating a process performed by an exemplary embodiment. [Figure 1S] 1 is a flowchart illustrating a process performed by an exemplary embodiment.

[0005] [Figure 2]FIG. 1 is a block diagram of an exemplary computing system or device for implementing a computer security module according to an exemplary embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0006]

[0003] Embodiments described herein provide enhanced computer and network-based methods, devices, and systems for computer security, and more particularly for inhibiting, controlling, or restricting the execution of malicious software or access to files or databases. Some embodiments provide a computer security module ("CSM") configured to control (e.g., inhibit, limit, monitor) the execution of malicious software on a computing system.

[0007] The core function of a CSM is to determine whether to allow a program (e.g., a native executable, a script, etc.) to run. This decision is based at least in part on the source of the program, and specifically, whether the program is provided by one of a set of privileged (or "secure") sources. A privileged program source may be any module, mechanism, or process that can provide executable instructions, such as a directory or folder (e.g., on a local disk or network-accessible store), a computing device (e.g., a server computer), another program (e.g., a web server), etc.

[0008] In some cases, a privilege source is a privileged folder or a privileged directory. A privileged folder is a folder that has been identified as storing programs that are eligible to run on a computer system. The set of privileged folders may include one or more of the following: operating system folders (e.g., / bin, / sbin, / system32, etc.); application folders (e.g., / Program Files, / usr / bin); startup or services folders; third-party app folders; folders into which an organization (e.g., a company) that owns or manages the computer may install its own authorized programs; etc.

[0009] In some cases, a privilege source is a privileged computer or process, which may be identified by one or more identifiers such as a machine name, an IP address, a domain name, a process name, a process identifier, a process / program digest / signature (e.g., a hash of program instructions), etc.

[0010] Privileged sources can be managed by a “whitelist” or similar data structure. The whitelist includes multiple identifiers of privileged sources. Furthermore, the “whitelist” itself is a privileged source, meaning that it is subject to the access control rules described herein. The identifier may be or include a directory name (e.g., system32), a directory path (e.g., / usr / bin), an IP address, a domain name, a machine name, etc. In some cases, a URL may be used to identify a privileged source. Privileged sources may also be identified or determined based on other or additional characteristics. For example, some embodiments may consider a source privileged if communication with that source occurs at a specified time (e.g., within a time range), if the source is located within a specified geographic region, if the source address is associated with a particular organization (e.g., via a WHOIS lookup), etc. Some embodiments may generally base the determination of whether a source is privileged on whether there are one or more permitted or acceptable characteristics of communication with the source. Additional information regarding determining the acceptability of network communications can be found in U.S. Patent No. 10,084,791, issued September 25, 2018, entitled "Evaluating a Questionable Network Communication," the contents of which are incorporated herein by reference.

[0011] The CSM may be implemented in various ways. The CSM may be implemented as code residing in one or more locations within the operating system, including the loader, scheduler, memory manager, etc. For example, the loader may check the location of any program as it is loaded into memory. If the location is not within the set of privileged folders, the loader terminates execution. As another example, the scheduler may check whether the program was loaded from one of the privileged folders before switching to the next program on the ready queue. If not, the scheduler terminates the program. Similarly, when the memory manager is asked to create a new virtual address space (e.g., page tables, etc.), it can check whether the requesting program was loaded from one of the privileged folders.

[0012] Script interpreters may also be used to control the execution of potentially malicious programs. In some embodiments, a script interpreter (e.g., for shell scripts, VBScript, Perl, Python, etc.) will refuse to run / interpret a given script if it is not loaded from one of the privileged folders.

[0013] The described techniques require that privileged folders be “locked down.” In other words, the privileged folders are write-protected and / or executable-protected from normal users, and only users with appropriate administrative privileges can install programs into those folders. In some embodiments, as described further below, only privileged users logged in in maintenance mode are allowed to install programs or otherwise modify file access permissions. Additionally, other measures, such as secure boot, a locked BIOS, etc., may be taken to limit a malicious party's ability to install programs. As described further below, some embodiments further provide and implement additional privilege levels and user classes / groups. For example, one embodiment provides separate administrative and application groups. Each group may have its own superuser, distinct from the overall system superuser. Members of the administrative group and / or superusers are prevented from accessing files / folders dedicated to application purposes (e.g., executables, libraries, etc.), thereby limiting the domain of users allowed to access / modify application-specific code or data.

[0014] Some embodiments use modified access control lists to restrict access to resources (e.g., folders, files, libraries, executable files) on a computing system. Prior art access control lists (ACLs) identify one or more users or groups that have permission to read, write, or execute a resource. Prior art access control lists do not have the ability to restrict the source or method of access by a user. Some embodiments solve this problem by including an access source field in the ACL. The access source field identifies the computers that are allowed to access the resource associated with the ACL. The access source field may include an IP address, an IP address range, a hardware identifier (e.g., a MAC address), etc.

[0015] The process for using the modified ACL is as follows: When a user (or program) attempts to access a resource, the CSM checks the ACL for the resource. If the ACL includes an access source field, the CSM determines the access source for the user. If the user is accessing through a remote machine, the CSM determines the source IP address of that machine. The CSM then matches the source IP address with the allowable IP addresses in the ACL. If the source IP address is allowed, the CSM allows access to the resource. If not, the CSM restricts access. Other variations are also contemplated. For example, the ACL may specify that access is only allowed from a physical terminal and no remote network access is allowed. Alternatively, the ACL may specify that any access from the machine's subnet is allowed.

[0016] Some embodiments add and implement a new privilege level and corresponding user group or class to the operating system. This new privilege level exceeds root or superuser access and requires that access occur only when the system is booted in secure mode or maintenance mode by a privileged user, such as root, administrator, global superuser, administrative group superuser, or application group superuser. Maintenance mode, in some systems, is a diagnostic or administrative mode in which only core operating system services are initiated to diagnose and fix problems or to modify operating system components, configurations, or functionality. In typical systems, only certain privileged users are allowed to log in during maintenance mode. Such users may also be restricted to logging in only from the local console (no network login). Maintenance mode, in some systems, is also a single-user mode, so that only local administrative and application users (e.g., root) can log in. In some operating systems, maintenance mode can only be entered by pressing a keyboard key or other console input during boot. In other cases, the mode can only be entered by booting from a specific physical media device (e.g., a USB stick or CD-ROM).

[0017] In some embodiments, the operating system includes additional types or classes of users. Traditional operating systems distinguish between normal users and highly privileged users, sometimes called superusers or root users. In traditional systems, superusers have complete privileges to modify any system data. In some embodiments of the invention, the superuser concept is broken down into three subclasses: safe mode superusers, administrative superusers, and application superusers.

[0018] A safe mode superuser is the highest level user with full privileges, but is limited to logging in from the local console and / or when the system is booted in safe mode or maintenance mode. Embodiments may have a single safe mode superuser account or a group of safe mode superusers. A safe mode superuser can perform system updates, install new packages / programs, system backup / restore, etc. Only a safe mode superuser can modify the access control list to make a program executable, such as by modifying the executable bit and / or whitelist entry (e.g., when the executable bit is not available for files / operating systems or scripts). In some operating systems, scripts do not necessarily have an executable attribute associated with them, for example, because they are text files. Therefore, in such operating systems, some embodiments may use a whitelist to manage the execution or access of such script files. The whitelist may identify files in various ways. For example, the whitelist may use a partial or full filename or digest to determine the file's identity and / or content.

[0019] Only the safe mode superuser can manage the administration and superuser groups, for example, by adding / removing users from these groups. Typically, the safe mode superuser assigns top-level directories / folders to one of the application or administration groups. For example, the safe mode superuser might assign the "C:\Program Files" folder (on Windows) or the / bin directory (on Unix / Linux) to the application group and "C:\Windows" and "C:\Users" to the administration group.

[0020] An administrative group typically has a single administrative super user and one or more regular group members. Some embodiments support multiple administrative super users. An administrative super user has full privileges with some exceptions, including (1) the ability to modify application-related data on the system, including executable files, libraries, etc., and (2) the ability to manage (e.g., add, remove) any of the super user (or other) groups. An administrative super user can modify access control lists with exception executable bits, safe bits, or copy bits (or executable whitelists), as described further below. An application super user can manage application-related data, but cannot manage any of the other super user groups. A user cannot belong to both an administrative group and an application group simultaneously. In some embodiments, there is no safe mode super user. Instead, an administrative or application super user is only allowed to modify administrative or application groups when logged in from a local console and / or when the system is in maintenance mode.

[0021] In some embodiments, a new field (the "safe bit") is added to each resource's ACL that specifies that the resource can only be modified when the machine is running in safe or maintenance mode. This technique stops any hacker from accessing, modifying, or executing a folder or other resource, even if the hacker manages to gain root access. Unless the hacker has physical access and is able to boot the computing system into safe mode, the hacker cannot access resources protected by the safe bit. In embodiments in which multiple super user groups (e.g., administrative and application super user groups as discussed above) are implemented, the ACL for each resource must also specify a particular super user group in order for members of that group to access or modify the resource.

[0022] In some embodiments, entries in an ACL may also include a "copy bit" that controls whether a user is allowed to perform certain types of copy operations. For example, if an ACL does not specify a right to copy for a given file, the user cannot copy the given file to a different file system and / or storage medium. The user can read the file, but cannot copy the file to a USB stick or other storage medium. Because an application can open and read a file that does not have a copy bit, steps are taken to stop the application from writing the file to another file system / medium. In some embodiments, the operating system includes only applications that have been verified as not allowing saving files without a copy bit to a different file system / medium. Because the operating system only allows the execution of applications installed by the application superuser, the system can ensure the enforcement of copy bit semantics. In other embodiments, operating system internals may be modified to enforce the copy bit. For example, the operating system may track signatures (e.g., hashes) of files (or portions thereof, such as disk blocks) that do not have copy rights. Then, when a disk block is written, its signature is compared to the signature of the restricted file / block to determine if the block can be written.

[0023] As described above, various data structures, such as whitelists and / or access control lists, can be used to control access to specified resources. Some embodiments use whitelists and / or access control lists to specifically control program execution. For example, in some operating system file systems (e.g., Linux and other Unix variants), each resource has an associated executable attribute or bit. This attribute identifies the resource as executable, such as for a program or library. The operating system will only execute programs or libraries that have the executable attribute set (e.g., load the program / library's instructions and jump to the program / library's entry point). In a typical embodiment, the CSM allows the executable attribute to be set only under certain conditions, such as by a superuser and / or in maintenance mode (possibly with restricted login users and / or locations), as described above. Additionally, some embodiments will only execute programs for users accessing the computing system from specified sources, such as the local console or a specific network host. For example, the system may check the IP address associated with the access and restrict program execution to a specific IP address or address range. Access from a local console may be assigned a localhost IP address, such as 127.0.0.1. Some commercially available operating systems (e.g., Microsoft Windows®) do not provide an executable bit / attribute for files. Also, in Linux® and other Unix® variants, the executable attribute does not necessarily apply to shell scripts. While some shell scripts may be identified as executable, others may be run as arguments to a shell program and therefore may not have their executable bit set. In such cases, embodiments of the present invention rely on a whitelist or similar structure to identify executable content.The whitelist can only be modified by a specific privileged user (e.g., a safe mode superuser). Other embodiments actually modify the underlying Windows file system to add the executable attribute, so that a whitelist is not necessary, although the whitelist may still be used for other purposes, such as identifying IP addresses that are allowed to run a given program.

[0024] (Example Process) 1A-1S are flow diagrams of exemplary security processes performed by exemplary embodiments. The processes may be implemented as computer instructions executing on a computing system. As discussed above, these instructions may reside in one or more parts of the operating system, including the loader, scheduler, memory manager, etc. Additionally or alternatively, the instructions may reside in programs running "outside" the operating system, such as a shell command interpreter, a scripting language interpreter, a virtual machine (e.g., Java Virtual Machine, C# VM), etc.

[0025] Figure 1A is a flow diagram of exemplary logic for computer security. The illustrated logic in this and the following flow diagrams may be performed, for example, by module 100 described below with respect to Figure 2. Figure 1A shows a process 1A00 that includes the following blocks:

[0026] Block 1A01 includes receiving and storing indications of one or more privileged sources, each designated as providing programs that are permitted to execute on the computing system. A source may be a directory or folder on a local or remote file system. Additionally or alternatively, a source may be a computer (e.g., a server) identified by an IP address, domain name, machine name, URL, etc. In some embodiments, the process reads or accesses a "whitelist" of "safe" sources from a write-protected document stored in the file system. In the whitelist, each source is designated as being a source of programs eligible for execution.

[0027] Block 1A02 includes receiving program instructions. The program instructions may be received before or during starting the program, such as before or during the loading process. The program instructions may include or be used to determine the location of the program, specifically the identity of the directory from which the program is loaded. In the case of a program obtained from a remote source (e.g., JavaScript code received by a web browser), the instructions may be or include a URL, IP address, domain name, or other identifier of the remote source.

[0028] Block 1A03 includes determining whether the program is provided by one of one or more privileged sources. The program is looked up within a whitelist of privileged sources. This may be accomplished via a dictionary lookup, a hash table, etc. This operation may include looking up the program name, the remote program source (e.g., domain name, IP address), etc.

[0029] Block 1A04 includes disallowing a program to run when the program is not provided by any of the privilege sources. Disallowing a program to run may be accomplished in various ways, such as by terminating the load process, causing an exception (so that the program is terminated by the operating system), refusing to create virtual memory space, refusing a scheduler to run the process, or switching to the process, etc.

[0030] Figure 1B is an example logic flow diagram illustrating an extension of process 1A00 of Figure 1A. Figure 1B illustrates process 1B00, which includes process 1A00 and further includes the following blocks:

[0031] Block 1B01 includes determining whether the network-accessible source is one of one or more privileged sources when the indicated program is provided by a network-accessible source. In a typical embodiment, a web browser or other module fetching the program from a remote source will check whether the remote source is identified in a whitelist. This may include checking whether the IP address, domain name, machine name, or other identifier of the remote source is present on the whitelist.

[0032] Block 1B02 includes disallowing program execution when the network-accessible source is not one of one or more privileged sources. For example, a web browser or similar module refuses to load or execute a program when the source identifier is not present on a whitelist. Note that this approach may require the use of a web browser modified to perform these checks. A user cannot execute arbitrary remote code because they cannot manually download and execute such code (because only code in designated directories can execute), nor are they allowed to install an insecure web browser in one of the designated privileged directories.

[0033] Figure 1C is an example logic flow diagram illustrating an extension of process 1A00 of Figure 1A. Figure 1C illustrates process 1C00, which includes process 1A00 and further includes the following blocks:

[0034] Block 1C01 includes disallowing modification of one or more directories identified by one or more sources as providers of programs that are permitted to be executed by the computing system. For secure sources that are directories, operating system permissions can be used to restrict modification of such directories (e.g., by adding or removing programs) by non-privileged users.

[0035] 1D is an exemplary logic flow diagram illustrating an extension of process 1A00 of FIG. 1A. FIG. 1D illustrates process 1D00, which includes process 1A00, and disallowing program execution includes the following blocks:

[0036] Block 1D01 includes terminating the program, interrupting the program, and / or raising an exception.

[0037] 1E is an exemplary logic flow diagram illustrating an extension of process 1A00 of FIG. 1A. FIG. 1E illustrates process 1E00, which includes process 1A00, and does not allow the program to run, including the following blocks:

[0038] Block 1E01 includes executing the program in an alternative execution environment. In some embodiments, the program may instead be allowed to run, but within an alternative execution environment, such as a sandbox or isolated virtual machine. In such embodiments, the program may be monitored to better understand the behavior and characteristics of potentially malicious code.

[0039] Figure 1F is an example logic flow diagram illustrating an extension of process 1A00 of Figure 1A. Figure 1F illustrates process 1F00, which includes process 1A00 and further includes the following blocks:

[0040] Block 1F01 includes receiving an indication of one or more sources from a file. Some embodiments store the list of privileged sources in a file that is write-protected from non-administrative users.

[0041] Block 1F02 includes not allowing non-privileged users to modify files. Only administrative users can modify files that identify privileged execution sources.

[0042] 1G is an exemplary logic flow diagram for computer security. FIG. 1G shows a process 1G00 that includes the following blocks:

[0043] Block 1G01 includes receiving and storing an indication of one or more directories, each designated as containing programs that are permitted to run on the computing system. In some embodiments, the process reads the list of files from a write-protected document stored in the file system.

[0044] Block 1G02 includes receiving program instructions. The program instructions may be received before or during starting the program, such as before or during the loading process. The program instructions may include or be used to determine the location of the program, specifically the identity of the directory from which the program is loaded.

[0045] Block 1G03 involves determining whether the program is located in one of the one or more directories. The program's location is looked up in a list of privileged folders. This may be accomplished via a dictionary lookup, a hash table, etc.

[0046] Block 1G04 includes disallowing a program to run when the program is not located in any of the one or more directories. Disallowing a program to run may be accomplished in various ways, such as by terminating the load process, causing an exception (so that the program is terminated by the operating system), refusing to create virtual memory space, refusing a scheduler to run the process, or switching to the process, etc.

[0047] 1H is an exemplary logic flow diagram for computer security. FIG. 1H shows a process 1H00 that includes the following blocks:

[0048] Block 1H01 includes receiving an indication that a user is attempting to access a resource on a computing system. For example, a process may receive an indication that a user (or a program associated with the user) is attempting to read, write, or execute a file, directory, or program on the computing system.

[0049] Block 1H02 includes determining a source identifier associated with the user. For example, the process may receive an IP address associated with the remote access of the resource. Alternatively, the source identifier may be a hardware identifier such as a MAC address. In some cases, the process may receive a token (e.g., a random number) generated during an authentication process between the user and the system (or some other authenticating computer system). During authentication, this token may be associated with the source identifier (e.g., in a table). For example, a table may be used to associate an authentication token with an IP address or hardware address. This token may then be used to look up the source identifier.

[0050] Block 1H03 includes determining whether an access control list associated with the resource specifies the source identifier as allowable. In some embodiments, each resource has an access control list that further specifies one or more identifiers of local or remote sources that are permitted to access the resource. The identifiers may be network addresses or ranges, hardware identifiers, etc.

[0051] Block 1H04 includes disallowing access to the resource when the source identifier is designated as unacceptable. Disallowing access may include disallowing execution of the resource, as described above. Disallowing access may additionally or alternatively include refusing to open, read, or write the resource.

[0052] Figure 1I is an example logic flow diagram illustrating an extension of process 1H00 of Figure 1H. Figure 1I illustrates process 1I00, which includes process 1H00 and further includes the following blocks:

[0053] Block 1101 includes determining whether the computing system is running in maintenance mode. For example, the process may determine whether the computer was booted into safe mode or maintenance mode, such as by reading a flag or file or other identifier that was set during system boot.

[0054] Block 1102 involves determining whether the resource is accessible only in maintenance mode. In some embodiments, every resource has an associated permission bit that indicates whether the resource is accessible only in secure mode. This bit can be combined with other permission identifiers, such as user or group identifiers, to limit access to specific users.

[0055] Block 1103 includes controlling access based on (1) whether a source identifier is designated as acceptable, (2) whether a resource is accessible only in maintenance mode, and (3) whether the system is running in maintenance mode. Controlling access includes allowing or disallowing access to a resource. In some embodiments, some resources are locked down in the sense that they are accessible only in maintenance mode and when a source identifier is designated as an acceptable source.

[0056]

[0023] Figure 1J is an example logic flow diagram illustrating an extension of process 1H00 of Figure 1H. Figure 1J illustrates process 1J00, which includes process 1H00, where determining a source identifier associated with a user includes the following blocks:

[0057] Block 1J01 includes receiving a token generated during an authentication process between a user and a computing system. The token may be, for example, a random number.

[0058] Block 1J02 includes determining a source identifier based on the token. The process may look up the source identifier in a table that maps authentication tokens to IP addresses, hardware identifiers, user identifiers, etc.

[0059] 1K is an exemplary logic flow diagram for computer security. FIG. 1K shows a process 1K00 that includes the following blocks:

[0060] Block 1K01 includes receiving an indication that a user is attempting to access a resource on a computing system. For example, a process may receive an indication that a user (or a program associated with the user) is attempting to read, write, or execute a file, directory, or program on the computing system.

[0061] Block 1K02 includes determining whether the computing system has been booted in maintenance mode. For example, the process may determine whether the computer has booted into safe mode or maintenance mode, such as by reading a flag or file or other identifier that was set during system boot. As explained further above, maintenance mode, in some systems, is a diagnostic or administrative mode in which only core operating system services are initiated to diagnose and fix problems or to modify operating system components, configurations, or functionality.

[0062] Block 1K03 includes determining whether the resource is accessible only in maintenance mode. In some embodiments, every resource has an associated permission bit that indicates whether the resource is accessible only in secure mode. This bit can be combined with other permission identifiers, such as user or group identifiers, to limit access to specific users.

[0063] Block 1K04 includes disallowing access to the resource when the resource is accessible only in maintenance mode and when the system is not booted in maintenance mode. Disallowing access may include disallowing execution of the resource, as described above. Disallowing access may additionally or alternatively include refusing to open, read, or write the resource.

[0064] Figure 1L is an example logic flow diagram illustrating an extension of process 1K00 of Figure 1K. Figure 1L illustrates process 1L00, which includes process 1K00 and further includes the following blocks:

[0065] Block 1L01 includes determining a source identifier associated with the user. For example, the process may receive an IP address associated with the remote access of the resource. Alternatively, the source identifier may be a hardware identifier such as a MAC address.

[0066] Block 1L02 includes determining whether an access control list associated with the resource specifies the source identifier as allowable. In some embodiments, each resource has an access control list that further specifies one or more identifiers of local or remote sources that are permitted to access the resource. The identifiers may be network addresses or ranges, hardware identifiers, etc.

[0067] Block 1L03 includes controlling access based on (1) whether a source identifier is designated as acceptable, (2) whether a resource is accessible only in maintenance mode, and (3) whether the system is booted in maintenance mode. Controlling access includes allowing or disallowing access to a resource. In some embodiments, some resources are locked down in the sense that they are accessible only in maintenance mode and when a source identifier is designated as an acceptable source.

[0068] 1M is an exemplary logic flow diagram for computer security. FIG. 1M shows a process 1M00 that includes the following blocks:

[0069] Block 1M01 includes receiving an indication that a user is attempting to access a resource on a computing system, the computing system including an operating system representing multiple users and groups, including a safe mode superuser, an administrative group with a corresponding administrative superuser, and an application group with a corresponding application superuser. For example, a process may receive an indication that a user (or a program associated with the user) is attempting to read, write, or execute a file, directory, or program on the computing system. In this embodiment, the computing system executing the process hosts an operating system representing different groups, each representing a different type or class of user, as discussed in more detail above.

[0070] Block 1M02 includes determining a source identifier associated with the user, the user belonging to exactly one of a plurality of user groups. For example, the process may receive an IP address associated with the remote access of the resource. Alternatively, the source identifier may be a hardware identifier such as a MAC address. In some cases, the process may receive a token (e.g., a random number) generated during an authentication process between the user and the system (or some other authenticating computer system). During authentication, this token may be associated with the source identifier (e.g., in a table). For example, a table may be used to associate an authentication token with an IP address or hardware address. This token may then be used to look up the source identifier. As another alternative, the source identifier may be an indicator that the user is logged in from a local console.

[0071] Block 1M03 includes controlling access to the resource based on the resource, the user's group, and the source identifier. The process considers the resource and its associated attributes (e.g., whether the resource is a directory / folder, a data file, an executable file, a library), in addition to the user's class (e.g., safe mode superuser, application superuser, etc.) and the source of access (e.g., from a local terminal, remote network access, etc.). In some embodiments, the process uses an access control list associated with the resource that specifies access conditions that must be met to allow access. Such conditions may include one or more identifiers of local or remote sources that are allowed to access the resource. The identifier may be a network address or range, a hardware identifier, etc. The access conditions may further include the requested user class, the type of operation (e.g., execute, read, write), etc. In some embodiments, a “copy” attribute is included in the access control list. If the copy attribute is set, the user may not copy the resource to a remote or removable storage device, such as a USB drive.

[0072]

[0023] Figure 1N is an example logic flow diagram illustrating an extension of process 1M00 of Figure 1M. Figure 1N illustrates process 1N00, which includes process 1M00, controlling access to resources based on resources, groups of users, and source identifiers, including the following blocks:

[0073] Block 1N01 includes storing, for each resource stored by a file system managed by the operating system, an indication of users, groups, and / or sources that are authorized to read, write, and / or perform operations on the resource. In some embodiments, the operating system uses an access control list or similar data structure associated with each resource to store an indication (e.g., control bits, flags) of users, groups, sources, etc. that are authorized to perform certain operations on the resource.

[0074] Block 1N02 includes allowing modification of the resource based on the stored instructions and the user's group and source identifier. For example, if the resource is a directory, a process may allow or disallow modification of the directory (e.g., adding / removing files) based on the stored instructions. As described above, some embodiments implement group / permission semantics to control resource access. For example, when the resource is an executable or library, a process may allow modification of the resource only if the user is a safe mode superuser. Other embodiments may allow safe mode superusers in addition to application group superusers. As another example, when the resource is a directory containing an executable application or library, a process may allow modification of the resource only if the user is an application superuser or a member of an application group, if they have been granted permission to modify the resource by the application group superuser, etc.

[0075] As a further example, if the resource is an executable application or library, the process may allow modification of the resource only if (1) the user is a safe mode superuser and (2) the computing system is in maintenance mode. Some embodiments allow modification of an application group or an administrative group only if (1) the user is a safe mode superuser (or a member of the safe mode superuser group, if a safe mode superuser exists) and (2) the computing system is in maintenance mode. Some embodiments allow adding a user to an application group only if the user is not a member of the administrative group. Some embodiments allow adding a user to an application group only if (1) the user is not a member of the administrative group and (2) the computing system is in maintenance mode. Some embodiments allow adding a user to an application group only if (1) the user is not a member of the administrative group, (2) the computing system is in maintenance mode, and (3) the user was added by a safe mode superuser.

[0076] Figure 10 is an example logic flow diagram illustrating an extension of process 1M00 of Figure 1M. Figure 10 illustrates process 1O00, which includes process 1M00 and further includes the following blocks:

[0077] Block 1001 includes storing a list identifying executable programs or libraries. As mentioned above, some operating systems do not have an executable flag or bit associated with file permissions. In such systems, a process maintains a whitelist containing references to executable programs. If a program is not on the whitelist, it cannot be executed.

[0078] Block 1012 includes allowing only a secure mode superuser to modify the list during maintenance mode when the secure mode superuser is logged in. To provide a high degree of security assurance, the whitelist can only be modified by a secure mode superuser logged in during maintenance mode.

[0079] Block 1003 includes allowing the application to run only if the resource is an executable application and it is identified by a whitelist. A process checks the whitelist when a program is launched to determine if it is identified by the whitelist. If not, the program is terminated or otherwise restricted, such as by running in an alternative execution environment.

[0080]

[0023] Figure 1P is an example logic flow diagram illustrating an extension of process 1M00 of Figure 1M. Figure 1P illustrates process 1P00, which includes process 1M00, and the step of controlling access to a resource based on the resource, a group of users, and a source identifier includes the following blocks:

[0081] Block 1P01 includes controlling access based on an access control list associated with the resource, which specifies whether the resource can be copied to another file system or storage medium. Some embodiments use ACLs or other data structures to control copying of resources to a separate file or storage system. This technique can be used to stop a potentially malicious user from copying files to a USB drive or network destination.

[0082] Figure 1Q is an example logic flow diagram illustrating an extension of process 1P00 of Figure 1P. Figure 1Q illustrates process 1Q00, which includes process 1P00 and further includes the following blocks:

[0083] Block 1Q01 includes receiving an indication that a user intends to copy a resource. The process may receive this indication, for example, from an application tasked with creating a copy of the resource. In some embodiments, an application on the computing system (e.g., a UNIX cp command) is configured to check whether a given resource can be copied to a separate file system.

[0084] Block 1Q02 includes allowing a user to copy a resource only when the resource is being copied to a location in a file system that stores the resource based on an access control list associated with the resource. The process can check the ACL to determine if the copy bit is set. If not, the process does not allow the copy operation.

[0085]

[0023] Figure 1R is an example logic flow diagram illustrating an extension of process 1M00 of Figure 1M. Figure 1R illustrates process 1R00, which includes process 1M00, and the step of controlling access to a resource based on a resource, a group of users, and a source identifier includes the following blocks:

[0086] Block 1R01 includes storing digests of one or more disk blocks used to store resources on a first file system managed by the operating system. As described above, some embodiments use message digests to create signatures for files or file blocks. These digests can then be used to prohibit certain disk write operations required to copy a file.

[0087] Block 1R02 includes receiving an indication that a disk block is being written to a second file system, where the process receives an indication of a disk block that is about to be written to a second file system, such as a removable USB drive.

[0088] Block 1R03 includes disallowing a disk block from being written when the disk block's digest matches one or more of the stored digests. The process generates a digest (e.g., hash, checksum) for the disk block and compares it to the stored digests. If there is a match, the process disallows the write operation.

[0089]

[0023] Figure 1S is an example logic flow diagram illustrating an extension of process 1M00 of Figure 1M. Figure 1S illustrates process 1S00, which includes process 1M00, and the step of controlling access to a resource based on the resource, a group of users, and a source identifier includes the following blocks:

[0090] Block 1S01 includes storing, for each resource stored by a file system managed by the operating system, an indication of sources that are allowed to execute the resource. In some embodiments, the operating system uses access control lists and / or whitelists to store the sources that are allowed to execute each stored file, directory, etc. For example, each file / directory may have an access control list with an execute bit / attribute. The whitelist may then store IP addresses as sources that are allowed to execute specified programs / libraries on the computing system.

[0091] Block 1S02 includes allowing execution of a resource only if the resource is executable and if the source identifier matches one of the stored source instructions. For example, if the resource is a program and the whitelist indicates that the program can only be executed from IP address 127.0.0.1 (localhost), then the process is only allowed to run when the user is logged in from the local console. Of course, the whitelist may use IP address ranges to more efficiently specify allowable sources. Furthermore, the whitelist may be used only for executable resources, saving memory / storage by not expressing allowable sources for resources that can never be executed.

[0092] (Example of computing system implementation) 2 is a block diagram of an exemplary computing system or device for implementing a computer security module, according to an example embodiment. In particular, FIG. 2 illustrates a computing system 10 executing a module 100 that implements at least some of the techniques described herein.

[0093] In the illustrated embodiment, computing system 10 comprises computer memory (“memory”) 11, display 12, one or more central processing units (“CPUs”) 13, input / output devices 14 (e.g., keyboard, mouse, CRT or LCD display, etc.), other computer-readable media 15, and network connection 16. Module 100 is shown resident in memory 11. In other embodiments, some portions of the content, some or all of the components of module 100 may be stored on and / or transmitted via other computer-readable media 15. Module 100 preferably executes on one or more CPUs 13 to perform the techniques described herein. Other code or programs 30 (e.g., administrative interfaces, web servers, etc.) and potentially other data repositories, such as data repository 20, also reside in memory 11 and preferably execute on one or more CPUs 13. Notably, one or more of the components of FIG. 7 may not be present in any particular implementation. For example, some embodiments may not provide other computer-readable media 15 or display 12.

[0094] Module 100 is shown executing within memory 11 of device 100. Also within memory 11 are a user interface manager 41 and an application program interface ("API") 42. User interface manager 41 and API 42 are depicted with dashed lines to indicate that in other embodiments, the functionality performed by one or more of these components may be performed outside of module 100.

[0095] UI manager 41 provides views and controllers that facilitate user interaction with module 100 and its various components. For example, UI manager 41 may provide interactive access to module 100 so that a user or administrator can interact with module 100. In some embodiments, access to the functionality of UI manager 41 may be provided through a web server, possibly running as one of other programs 30. In such embodiments, a user operating a web browser running on user computing system 60 may interact with module 100 through UI manager 41.

[0096] The API 42 provides programmatic access to one or more functions of the module 100. For example, the API 42 may provide a programmatic interface to one or more functions of the module 100 that can be called by other programs 30 or one of some other modules. In this manner, the API 42 facilitates the development of third-party software, such as user interfaces, plug-ins, adapters (e.g., for integrating the functionality of the module 100 into a web application), and the like.

[0097] Module 100 can interact with other devices / systems, including computing systems 60, 62, and 64, using network connection 16 via network 99. Network 99 may be any combination of media (e.g., twisted pair, coaxial, fiber optic, radio frequency), hardware (e.g., routers, switches, repeaters, transceivers), and protocols (e.g., TCP / IP, UDP, Ethernet, Wi-Fi, WiMAX) that facilitate communication between remotely located people and / or devices.

[0098] It should be noted that module 100 may be implemented and / or executed using one or more general-purpose or special-purpose computing systems / devices. However, the mere possibility of implementing module 100 on a general-purpose computing system does not imply that the techniques themselves or the operations (taken alone or in combination) required to implement the techniques are conventional or well-known. These techniques are unconventional at least because they address and improve upon existing technology, such as by improving the operation, integration, or efficiency of one or more computing systems.

[0099] In an exemplary embodiment, the components / modules of module 100 are implemented using software programming techniques. For example, module 100 may be implemented as a "native" executable file that runs on CPU 13 along with one or more static or dynamic libraries. In other embodiments, module 100 may be implemented as instructions processed by a virtual machine that executes as one of the other programs 30.

[0100] The various components may be implemented using more monolithic programming techniques, for example, as executables running on a single CPU computer system, or may be decomposed using various structuring techniques (including, but not limited to, multiprogramming, multithreading, client-server, or peer-to-peer, each running on one or more computer systems having one or more CPUs). Some embodiments may execute asynchronously in parallel and communicate using message passing, remote procedural, or other distributed computing paradigms. Equivalent synchronous embodiments are also supported. Also, other functions may be implemented and / or performed by each component / module, in a different order, and by different components / modules, and still achieve the described functions.

[0101] Additionally, programming interfaces to data stored as part of module 100, such as in data store 20, may be available through language-specific APIs, through libraries for accessing files, databases, or other data repositories, through expression languages ​​such as XML, or through web servers, FTP servers, or other types of servers that provide access to the stored data. Data store 20 may be implemented as one or more database systems, file systems, or any other techniques for storing such information, or any combination of the above, including implementations that use distributed computing techniques.

[0102] Additionally, in some embodiments, some or all of the components of module 100 may be implemented or provided in other manners, such as at least partially in firmware and / or hardware, including, but not limited to, one or more application-specific integrated circuits ("ASICs"), standard integrated circuits, controllers that execute appropriate instructions, as well as microcontrollers and / or embedded controllers, field programmable gate arrays ("FPGAs"), complex programmable logic devices ("CPLDs"), etc. Some or all of the system components and / or data structures may also be stored as content (e.g., as executable or other machine-readable software instructions or structured data) on a computer-readable medium (e.g., a hard disk, memory, a computer network or cellular wireless network or other data transmission medium, or a portable media article to be read via an appropriate drive or appropriate connection, such as a DVD or flash memory device), such that the computer-readable medium and / or one or more associated computing systems or devices can be enabled or configured to execute or use or provide the content to perform at least a portion of the described techniques. Some or all of the components and / or data structures may be stored in a tangible, non-transitory storage medium. Some or all of the system components and data structures may also be stored as data signals on various computer-readable transmission media (e.g., by being encoded as part of a carrier wave or by being included as part of an analog or digital propagated signal) and then transmitted across wireless-based media and wire / cable-based media, and may take various forms (e.g., as part of a single or multiplexed analog signal, or as multiple discrete digital packets or frames). Such computer program products may also take other forms in other embodiments. Accordingly, embodiments of the present disclosure may be practiced with other computer system configurations.

[0103] (Example Group Structure and Permissions) The following table describes user capabilities in an exemplary embodiment. This exemplary embodiment provides a safe mode super user, an application super user (with a corresponding application user group), and an administrative super user (with a corresponding application user group). For each type of user, the table below indicates the actions they can or cannot perform in the system. When the table states that a user "cannot make programs executable," this means either setting the executable attribute (the "X bit") and / or modifying a whitelist or similar structure that tracks allowed executable programs.

[0104] As mentioned above, some existing operating systems (e.g., Linux and other Unix variants) provide the executable attribute. On such operating systems, shell scripts may not comply with this constraint because they may not necessarily have their executable bit set (e.g., when the script is intended to be executed as an argument to a shell program). In this case, a whitelist, as described above, is used. For systems that do not provide the executable attribute, two different approaches may be taken. First, a whitelist, as described above, is used. Alternatively, the file system is modified to add the executable attribute. When the executable attribute is set, read-only is implied, so that the file can only be modified in secure mode by specific privileged users. Also, as described above, systems that use the executable attribute associated with files can still use the whitelist for other security-related functions, such as restricting access to the file to users operating from specified IP addresses or meeting some other specified permission condition. [Table 1]

[0105] Variations to the above structures and mechanisms are contemplated. For example, some embodiments may not allow normal users in the administrative or application groups to perform password resets under any circumstances. In a typical embodiment of the invention, the secure mode superuser is the only user who can enable programs to run, thereby providing very high security assurance. Administrative and application-based functions are bifurcated to further limit users' ability to perform system-altering functions.

[0106] While embodiments of the present invention have been illustrated and described, as noted above, many changes can be made without departing from the spirit and scope of the invention. Accordingly, the scope of the invention is not limited by the above disclosure.

Claims

1. 1. A method for computer security, comprising: receiving an indication that a user is attempting to access a resource on a computing system, the computing system including an operating system representing a plurality of users and groups, including a safe mode superuser, an administrative group with a corresponding administrative superuser, and an application group with a corresponding application superuser; determining a source identifier associated with the user, the user belonging to exactly one of the plurality of user groups; controlling access to the resource based on the resource, the group of the user, and the source identifier; A method comprising:

2. controlling access to the resource based on the resource, the group of the user, and the source identifier, comprising: storing, for each resource stored by a file system managed by said operating system, an indication of users, groups, and / or sources that are permitted to read, write, and / or execute said resource; authorizing modification of the resource based on the stored instructions and the group and source identifier of the user; The method of claim 1 , comprising:

3. 2. The method of claim 1, further comprising the step of: if the resource is an executable application or library, allowing modification of the resource only if the user is the safe mode superuser.

4. storing a list identifying executable programs or libraries; allowing only the secure mode superuser to modify the list when the secure mode superuser is logged in during maintenance mode; If the resource is an executable application, allowing the application to run only if it is identified by the list; The method of claim 1 further comprising:

5. 2. The method of claim 1, further comprising: if the resource is a directory containing an executable application or library, allowing modification of the resource only if the user is a member of the application group, provided that the user has been given permission to modify the resource by the application superuser.

6. 2. The method of claim 1, further comprising: (1) if the resource is an executable application or library, allowing modification of its executable permission bits only when the user is the safe mode superuser and the computing system is in maintenance mode.

7. 2. The method of claim 1, further comprising: (1) allowing modification of the application superuser group or the administrative superuser group only when the user is a safe mode superuser; and (2) the computing system is in maintenance mode.

8. The method of claim 1 , further comprising the step of allowing the user to be added to the application group only if the user is not a member of the administrative group.

9. 2. The method of claim 1, further comprising: allowing the user to be added to the application group only when (1) the user is not a member of the administrative group and (2) the computing system is in maintenance mode.

10. 2. The method of claim 1, further comprising: allowing the user to be added to the application group only when: (1) the user is not a member of the administrative group; (2) the computing system is in maintenance mode; and (3) the user is being added by a user who is a superuser.

11. 2. The method of claim 1, wherein controlling access to the resource based on the resource, the group of the user, and the source identifier comprises controlling access based on (1) an access control list associated with the resource and (2) whether the user is a member of the application group, wherein the access control list indicates that the resource may only be modified by members of the application superuser group.

12. 2. The method of claim 1, wherein controlling access to the resource based on the resource, the group of the user, and the source identifier comprises controlling access based on (1) an access control list associated with the resource and (2) an IP address associated with the computing system, the access control list indicating that the resource may only be modified by a computing system with a specified IP address / range.

13. 2. The method of claim 1, wherein controlling access to the resource based on the resource, the group of the user, and the source identifier comprises controlling access based on an access control list associated with the resource, the access control list specifying whether the resource can be copied to another file system or storage medium.

14. receiving an indication that the user wishes to copy the resource; permitting the user to copy the resource only when the resource has been copied to a location in a file system that stores the resource based on the access control list associated with the resource; 14. The method of claim 13, further comprising:

15. receiving an indication that the user wishes to copy the resource; based on the access control list associated with the resource, not allowing the user to copy the resource because the resource has been copied to a file system or storage medium different from the file system or storage medium on which the resource is stored; 14. The method of claim 13, further comprising:

16. The method of claim 15, wherein the resource is copied to a USB drive.

17. controlling access to the resource based on the resource, the group of the user, and the source identifier, comprising: storing a digest of one or more disk blocks used to store the resource on a first file system managed by the operating system; receiving an indication that the disk block is being written to the second file system; disallowing the write of the disk block when the digest of the disk block matches one or more of the stored digests; The method of claim 1 , comprising:

18. controlling access to the resource based on the resource, the group of the user, and the source identifier, comprising: storing, for each resource stored by a file system managed by said operating system, an indication of sources from which said resource is permitted to be executed; allowing execution of the resource only if the resource is executable and if the source identifier matches one of the stored source indications; The method of claim 1 , comprising:

19. 1. A system for computer security, comprising: a processor; A module stored in memory that, when executed by the processor, receiving an indication that a user is attempting to access a resource on a computing system, the computing system including an operating system representing a plurality of users and groups, including a safe mode superuser, an administrative group with a corresponding administrative superuser, and an application group with a corresponding application superuser; determining a source identifier associated with the user, the user belonging to exactly one of the plurality of user groups; controlling access to the resource based on the resource, the group of the user, and the source identifier; and A system comprising:

20. The module comprises: controlling access to the resource based on the resource, the group of the user, and the source identifier; storing, for each resource stored by a file system managed by said operating system, an indication of users, groups, and / or sources that are permitted to read, write, and / or execute said resource; authorizing modification of the resource based on the stored instructions and the group and source identifier of the user; 20. The system of claim 19, further configured to:

Images