CA2001863C - Secure file handling in a computer operating system - Google Patents
Secure file handling in a computer operating systemInfo
- Publication number
- CA2001863C CA2001863C CA002001863A CA2001863A CA2001863C CA 2001863 C CA2001863 C CA 2001863C CA 002001863 A CA002001863 A CA 002001863A CA 2001863 A CA2001863 A CA 2001863A CA 2001863 C CA2001863 C CA 2001863C
- Authority
- CA
- Canada
- Prior art keywords
- file
- write
- read
- security label
- security
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
- G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F2221/2113—Multi-level security, e.g. mandatory access control
Abstract
A method of, administering secure access to files of a computer system.
For a process-file pair, a first security label associated with the process is compared with a second security label associated with the file in response to a request to read or write the file. If the security label of the destination (file or process) of the read or write operation does not dominate the security label of the source (file or process), the security label of the destination is dynamically raised accordingly. If the security label of the file or process is raised, an indicator associated with this process and with this file is set to a first state representing that the file is safe for this process-file pair. Indicators associated with every other process linked with this file are set to a second state representing that the file is unsafe for those process-file pairs. The steps of testing the security labels of a file and a process on a read or write operation are omitted when the indicator associated with the process-pair is set to the safe state.
The security labels of certain files are assigned a frozen status. These security labels of such files cannot be altered in response to attempted read or write operations. Therefore, an attempt to write a file having frozen status is denied when the security label of the writing process dominates that of the file. This mechanism is used to guarantee that files cannot be written to media external to the system, such as terminals disk drives, tape drives and the like, unless the security label of the external media clears the media for access to the file.
For a process-file pair, a first security label associated with the process is compared with a second security label associated with the file in response to a request to read or write the file. If the security label of the destination (file or process) of the read or write operation does not dominate the security label of the source (file or process), the security label of the destination is dynamically raised accordingly. If the security label of the file or process is raised, an indicator associated with this process and with this file is set to a first state representing that the file is safe for this process-file pair. Indicators associated with every other process linked with this file are set to a second state representing that the file is unsafe for those process-file pairs. The steps of testing the security labels of a file and a process on a read or write operation are omitted when the indicator associated with the process-pair is set to the safe state.
The security labels of certain files are assigned a frozen status. These security labels of such files cannot be altered in response to attempted read or write operations. Therefore, an attempt to write a file having frozen status is denied when the security label of the writing process dominates that of the file. This mechanism is used to guarantee that files cannot be written to media external to the system, such as terminals disk drives, tape drives and the like, unless the security label of the external media clears the media for access to the file.
Description
SECURE FILE HANDLING IN A COMPUTER OPERATING SYSTEM
Field of the Invention The invention relates to the field of security in compu~e~ systems generally and, in particular, to the control of secure access to files in a coml,u 5 system by authorized users.
Technical Back~round Con~uL~,l security is becoming an increasingly important and urgent issue. As witness to this, consider the present day concern over COlll~)U~,l viruses which, if introduced into colllpulel systems, have the ability to read and/or destroy 10 unprotected data. Indeed, a number of such virus attacks have recently received nationwide attention.
Colllpul~l security is an encomp~sing term. It includes many aspects of protecting a colllpulel or colllpulel system. Security issues include system access by unauthorized users or programs and limitation of file access to limited users or 15 groups of users. We are concerned here primarily with the control of access to files.
A standard technique of protecting access to files is by means of permissions. In the collu~ ;ial versions of the UNIX (Registered trademark of AT&T) operating system, for example, every file is associated with a set of READ and VVRITE
permission bits. In fact, there are three sets of such permission bits for each file, one 20 set for the owner of a file, one set for members of a group associated with the file, and a final set for all other users of the system. A file owner controls the states of these permission bits. Thus, a file owner may prevent others from reading or writing a file by setting the READ, WRITE bits for group members and for all other system users to an unallowed state. Conversely, the file owner might allow all system users 25 total access to a file by setting the READ and WRITE bits associated with all users.
The file permission technique works well in any system in which the users are sensitive to security issues and diligently ~lmini~t~r the permission bits over which they have control. However, all system users are not always diligent. As such, the permission bit scheme represents a potential weak link in overall system 30 security. A further disadvantage of the permission scheme is that it is necessarily limited in its flexibility. Some systems require many levels of defined securityclassifications for users and files alike. Military systems are good examples of such systems, in which files may range in levels from unclassified to top secret and be further partitioned in compartments to which the level may apply. Access to such35 files must be limited to users having appropriate security clearances and the security classifications must follow the files as they move in a system. In such label systems, both files and user processes are assigned security labels. A user process cannot read a file unless the process security label dominates that of the file. By dominate, it is meant that the security label of the process is sufficient to allow access to the file in accordance with the file security label. Similarly, a process cannot write a file unless 5 the label of the file is at least as high as that of the process.
File access control, including the above permission and labeling methods, are discussed in CRYPTOGRAPHY AND DATA SECURITY, D.
Denning, Addison-Wesley, 1982, Chapter 4, pp. 191-258. Also discussed at page 287 of the book is a method commonly referred to as dynamic security labels. In the 10 dynamic security label method, the security labels of files and processes are raised as necessary to allow processes to access files. With such dynamic label methods, some additional form of protection must also be used to prevent llltim~te n~uthorized leakage of data to destinations external to the system. The dynamic security label method has advantages over fixed label types of methods. Fixed label 15 methods tend to suffocate system users and may in severe cases render flexible and productive use of a system almost impossible. Dynamic labels provide reasonable levels of security while mitig~ting this suffocating tendency of fixed labels.
However, the dynamic security label method has never been commonly used for two reasons. First, it is known that the technique introduces covert channels through 20 which security breaches may occur. This, however, is not a serious problem. The new covert ch~nnel~ are generally limited in bandwidth to approximately one bit of information per system call. Thus, attempts to "smuggle" significant amounts of info~ ation through such a covert channel is detectable by relatively simple means.
Additionally, to use such a channel, the user must already be cleared to use the data.
25 Second, and more important, the verification of process and file security labels on every read and write operation adds a tremendous amount of overhead to routine system operations. Thus, it is desirable to find ways of reducing this overhead to acceptable levels, thereby allowing advantageous use of the dynamic security label method.
30 Summary of the Invention The invention is a method of ~lmini~tering secure access to files of a co.l,pu~l system. First and second security labels are associated with files andprocesses, respectively. For a given process-file pair, the first security label is co~ d with the second security label in response to an attempt by the process to35 read (or write) the file. If the security label of the destination file or process of the read (or write) operation does not dominate the security label of the source file or process, the security label of the destination is dynamically raised sufficiently to dominate the security label of the source. The source and destination of a read operation, for example, are a file and a process, respectively. An in(licatQr associated with this process and with this file is set to a first state representing that the file is 5 safe for this process-file pair after the comparison of process and file security labels.
In(li~ators associated with every other process presently capable of accessing this file are set to a second state representing that the file is unsafe for those process-file pairs. The steps of testing the security labels of a file and a process on a read (or write) operation are omitted when the indicator associated with the process-pair is 10 set to the safe state.
The security labels of certain files are assigned a frozen status. The security labels of such files cannot be altered in response to a~ ed read or write operations. Therefore, an attempt to write a file having frozen status is denied when the security label of the writing process dominates that of the file. This mechanism 15 is used to guarantee that data cannot be written to media external to the system, such as termin~l~, disk drives, tape drives and the like, unless the security label of the external m~lillm clears the medium for access to the data.
In a preferred embo~lim~nt, the safe/unsafe in-lic~sor for each process-file pair actually comprises two intlicators, a SAFE-TO-READ indicator and a 20 SAFE-TO-WRITE indicator. For a given process-file pair, the SAFE-TO-READ
inrlic~tor associated with the pair is set to a safe state on a request to read the file by the process if the security label of the process is found to dominate the security label of the file or if the security label of the process is raised as a result of the read.
Similarly, the SAFE-TO-WRITE inrlicator associated with the pair is set to a safe 25 state on a request to write the file if the label of the file dominates or is raised. All SAFE-TO-READ indicators for all other processes associated with the file are set to an unsafe state on a request to write the file when the file label is raised and all SAFE-TO- WRITE in(1i~ atnrs for all other files associated with the process are set to an unsafe state when the process label is raised.
30 Brief Description of the Drawin~
In the drawing, Fig. 1 shows the format of an illustrative security label in which one section defines a security level and a second section divides the security level into comp~ Illlents to which the security level applies;
Fig. 2 illustrates the relationship between files, processes, file descriptors and safe-to-read/write bits, which are used to reduce the label verification overhead in an illustrative system used to explain the invention;
Fig. 3 shows an illustrative flowchart of the verification process for 5 READ operations; and Fig. 4 shows an illustrative flowchart of the verification process for READ operations.
Detailed Description The dynamic security label method described herein has been 10 implçm.qnted in a research version of the UNIX operating system (UNIX is a registered tr~dem~rk of AT&T). The invention is described in terms of this operating system. However, it is understood that this imple~ nla~ion is illustrative of the preferred embodiment and in no way limits applicability of the invention to other ope~ g systems. In the UNIX system, processes (p) operate on files (f). A
15 given file may be associated at any given time with more than one process. Each such process-file relationship is identified by a file descriptor (d). Processes may spawn child processes, i.e., images of itself. Such child processes inherit certain characteristics of the parent process, such as a process security label. However, new file descliptcl~ are ge~ ed for a child process. Thus, file descriptors uniquely20 identify every instance of a process-file relationship. Another attribute of the UNIX
system is that media eYtçrn~l to a system are also represented by files. Thus, terminals, disk drives, tape drives and the like are represented internally in the system as files. Thus, a write to a termin~l is accomplished as a write to the intPrn~l file representing the t~nnin~l A further attribute of the UNIX system is its file 25 system which is divided into directories, which again are represented by files. Each directory can consist of ordinary files and other subdirectories, and so on.
Fig. 1 introduces the notion of a security label as being associated with a process (p) or with a file (f). The illustrative security label in Fig. 1 is divided into two sections. The first SECURITY LEVEL section stores a nllm~ric representation 30 of an overall security level. This section might consist of three bits and be binary encoded to represent the customary military document classification levels uncl~c~ifie~, confidential, secret and top secret. The second section of Fig. 1,SECURITY COMPARTMENTS, further partition the SECURITY LEVEL. These bits might, for example, represent individual countries to which the security level 35 applies. For example, the first two bits of SECURITY COMPARTMENTS might represent countries A and B, respectively. With the use of dynamic security labels, 200186;~
as files are read and written within the system, the labels associated with the files and with the processes performing the read and write operations are raised as necessary.
On a read operation, a process label is raised to dominate the label of a file being read. On a write operation, a file label is raised to dominate the label of a process 5 performing the write. However, in accordance with one aspect of the invention, the security labels associated with external media such as tçrmin~lc, disk drives, tape drives and the like are frozen and cannot be altered, except by mech~nicm~ having no relationship to the present invention. Thus, an attempt to write to a file representing an external mçAillm having a security label that does not dominate the 10 security label of the writing process is denied.
As one example of the use of dynamic labels, assume that a process is executing which has an initial security label 011 00... (secret security level with no clearance for countries A and B. Assume further that the process creates a new file NEWFILE. The new file initially may be labeled 000 00... by default. If the process 15 attempts to wIite the name of the file into a directory, the security label of the directory is raised, if nececc~ry~ to at least that of the process. Now assume that the process reads another file OLDFILE, which say is labeled confitlçnti~l for country A
(001 10...). In this case, the process label is raised to the logical union of the labels of the process and the file OLDFILE [(011 00...) UNION (001 10...) = (011 10...).
20 Finally, assume that the process aUC;Illpts to write OLDFILE to a file associated with an output tçrmin~l If the security label of the file associated with the terminal does not dominate that of OLDFILE, the write is denied.? Thus, security is m~int~ined.
The security labels of files and processes are raised as n.ocecs~ry for internaloperations of the system. At a point when external access is aUelllpted,however,25 access is denied unless the external access point has the proper authorization.
In the UNIX operating system, each file (f) that is opened by a process (p) is identified by a unique file descriptor (d). If two separate processes open the same file, each process-file pair is similarly identified by a dirr~len~ file descriptor, even though both processes are using the same file. Fig. 2 illustrates this process-file 30 arrangement. In this Fig., a file (f) and a process (p) are joined by dotted lines to a file descriptor (d). When the process refers to the file, it does so through theoperating system by means of the file descriptor. In accordance with the invention, two other indicators are associated with a file descriptor, a SAFE-TO-READ bit and a SAFE-TO- WRITE bit. These bits are shown in Fig. 2 as attached to the file 35 descriptor by means of a solid line. The SAFE bits allow use of the dynamic label security method with acceptable system overhead, as described below. In accordance with the invention, also associated with each file is an indicator FROZEN, as shown in Fig. 2. The state of this indicator identifies whether or not the security label of the file may be raised at read and write time. The use of this file attribute is discussed further below in connection with attempted writes of data to 5 media, such as tçrmin~l~, that are external to the system.
Fig. 3 and Fig. 4 show illustrative flowcharts of algorithms that are executed by the operating system each time a read or a write operation, respectively, is requested by a process. In Fig. 3, when a read operation is requested by a process, step 300 interrogates the SAFE-TO-READ bit associated with the file descriptor in 10 question. If the SAFE-TO-READ bit is set, this means that the security labels for this process and file have been verified on an earlier read operation and the labels raised, if necessary. The safe state of the bit implies that no further system operation has taken place since that time to invalidate the earlier verification. Thus, if the SAFE-TO-READ bit is set, the algorithm merely exits at 302 and other portions of15 the opel~ing system, not shown, perform the read operation.
If the SAFE-TO-READ bit is not set at step 300, then the process and file security labels are verified. Step 304 ~lçt~rminçs if the label of the file in question is domin~te~l by the label of the process requesting a read. If so, a read of the file by the process is p ~ led without any further ado. In this case, the SAFE-20 TO-READ bit is set at step 310 and exit is made at 312 to pelrc,llll the read operation.
At step 304, if the security label of the process does not dominate that of the file, then step 306 raises the label of the process by an a~propliate amount. In this illustrative embo~1iment, raising of the process label is performed by logically 25 ORing the present process label with the present file label. Next, at step 308, the operating system searches for and determines all file descriptors (d) that are associated with the present process (p). Step 308 then clears all the SAFE-TO-WRITE bits associated with the found file descriptors. This is necessary since the raising of the security label of the process has rendered future write operations by 30 this process unsafe without reverification. After these operations have been performed, step 310 set the SAFE-TO-READ bit for this particular file descriptorand exit is made at 312.
In Fig. 4, when a write operation is requested by a process, step 400 interrogates the SAFE-TO-WRITE bit associated with the file descriptor in question.
35 If the SAFE-TO-WRITE bit is set, this means that the security labels for this process and file have been verified on an earlier write operation and the labels raised, if ;~001863 necessary. The safe state of the bit implies that no further system operation has taken place since that time to invalidate the earlier verification. Thus, if the SAFE-TO-WRITE bit is set, the algorithm merely exits at 402 and other portions of theup~ldling system, not shown, perform the write operation.
If the SAFE-TO-WRITE bit is not set at step 400, then the process and file security labels are verified. Step 404 determines if the label of the file in question dominates the label of the process requesting a write. If so, a write of the file by the process is permitted without any further ado. In this case, the SAFE-TO-WRITE bit is set at step 414 and exit is made at 416 to perform the write operation.
Recall that write operations are subject to a special consideration, namely, that writes to an external medium are not permitted by merely raising the security label of the file associated with the medium. Rather, the security labels of such external media are frozen at their assigned states. Therefore, at step 404, if the security label of the file does not dominate that of the process, then step 406 15 determines if the file security label is frozen. If the label is frozen, the write operation is denied by pelrolllfing an error return to the operating system at 408. If the file security label is not frozen, step 410 raises the label of the file by an appr~l;ate amount. In this illustrative embodiment, raising of the process label is pc.roll,led by logically ORing the present process label with the present file label.
20 Next, at step 412, the opel~ling system searches for and determines all file descriptors (d) that are associated with the present file (f~. Step 412 then clears all the SAFE-TO-READ bits associated with the found file descriptors. Clearing of the SAFE-TO-READ bits is necessary since the raising of the security label of the file has rendered all future read operations of this file unsafe without reverification.
25 After these operations have been performed, step 414 sets the SAFE-TO-WRITE bit for this particular file descriptor and exit is made at 416 to perform the instant write operation.
It is to be understood that the above described arrangements are merely illustrative of the application of principles of the invention and that other 30 arrangements may be devised by wolhel~ skilled in the art without departing from the spirit and scope of the invention.
Field of the Invention The invention relates to the field of security in compu~e~ systems generally and, in particular, to the control of secure access to files in a coml,u 5 system by authorized users.
Technical Back~round Con~uL~,l security is becoming an increasingly important and urgent issue. As witness to this, consider the present day concern over COlll~)U~,l viruses which, if introduced into colllpulel systems, have the ability to read and/or destroy 10 unprotected data. Indeed, a number of such virus attacks have recently received nationwide attention.
Colllpul~l security is an encomp~sing term. It includes many aspects of protecting a colllpulel or colllpulel system. Security issues include system access by unauthorized users or programs and limitation of file access to limited users or 15 groups of users. We are concerned here primarily with the control of access to files.
A standard technique of protecting access to files is by means of permissions. In the collu~ ;ial versions of the UNIX (Registered trademark of AT&T) operating system, for example, every file is associated with a set of READ and VVRITE
permission bits. In fact, there are three sets of such permission bits for each file, one 20 set for the owner of a file, one set for members of a group associated with the file, and a final set for all other users of the system. A file owner controls the states of these permission bits. Thus, a file owner may prevent others from reading or writing a file by setting the READ, WRITE bits for group members and for all other system users to an unallowed state. Conversely, the file owner might allow all system users 25 total access to a file by setting the READ and WRITE bits associated with all users.
The file permission technique works well in any system in which the users are sensitive to security issues and diligently ~lmini~t~r the permission bits over which they have control. However, all system users are not always diligent. As such, the permission bit scheme represents a potential weak link in overall system 30 security. A further disadvantage of the permission scheme is that it is necessarily limited in its flexibility. Some systems require many levels of defined securityclassifications for users and files alike. Military systems are good examples of such systems, in which files may range in levels from unclassified to top secret and be further partitioned in compartments to which the level may apply. Access to such35 files must be limited to users having appropriate security clearances and the security classifications must follow the files as they move in a system. In such label systems, both files and user processes are assigned security labels. A user process cannot read a file unless the process security label dominates that of the file. By dominate, it is meant that the security label of the process is sufficient to allow access to the file in accordance with the file security label. Similarly, a process cannot write a file unless 5 the label of the file is at least as high as that of the process.
File access control, including the above permission and labeling methods, are discussed in CRYPTOGRAPHY AND DATA SECURITY, D.
Denning, Addison-Wesley, 1982, Chapter 4, pp. 191-258. Also discussed at page 287 of the book is a method commonly referred to as dynamic security labels. In the 10 dynamic security label method, the security labels of files and processes are raised as necessary to allow processes to access files. With such dynamic label methods, some additional form of protection must also be used to prevent llltim~te n~uthorized leakage of data to destinations external to the system. The dynamic security label method has advantages over fixed label types of methods. Fixed label 15 methods tend to suffocate system users and may in severe cases render flexible and productive use of a system almost impossible. Dynamic labels provide reasonable levels of security while mitig~ting this suffocating tendency of fixed labels.
However, the dynamic security label method has never been commonly used for two reasons. First, it is known that the technique introduces covert channels through 20 which security breaches may occur. This, however, is not a serious problem. The new covert ch~nnel~ are generally limited in bandwidth to approximately one bit of information per system call. Thus, attempts to "smuggle" significant amounts of info~ ation through such a covert channel is detectable by relatively simple means.
Additionally, to use such a channel, the user must already be cleared to use the data.
25 Second, and more important, the verification of process and file security labels on every read and write operation adds a tremendous amount of overhead to routine system operations. Thus, it is desirable to find ways of reducing this overhead to acceptable levels, thereby allowing advantageous use of the dynamic security label method.
30 Summary of the Invention The invention is a method of ~lmini~tering secure access to files of a co.l,pu~l system. First and second security labels are associated with files andprocesses, respectively. For a given process-file pair, the first security label is co~ d with the second security label in response to an attempt by the process to35 read (or write) the file. If the security label of the destination file or process of the read (or write) operation does not dominate the security label of the source file or process, the security label of the destination is dynamically raised sufficiently to dominate the security label of the source. The source and destination of a read operation, for example, are a file and a process, respectively. An in(licatQr associated with this process and with this file is set to a first state representing that the file is 5 safe for this process-file pair after the comparison of process and file security labels.
In(li~ators associated with every other process presently capable of accessing this file are set to a second state representing that the file is unsafe for those process-file pairs. The steps of testing the security labels of a file and a process on a read (or write) operation are omitted when the indicator associated with the process-pair is 10 set to the safe state.
The security labels of certain files are assigned a frozen status. The security labels of such files cannot be altered in response to a~ ed read or write operations. Therefore, an attempt to write a file having frozen status is denied when the security label of the writing process dominates that of the file. This mechanism 15 is used to guarantee that data cannot be written to media external to the system, such as termin~l~, disk drives, tape drives and the like, unless the security label of the external m~lillm clears the medium for access to the data.
In a preferred embo~lim~nt, the safe/unsafe in-lic~sor for each process-file pair actually comprises two intlicators, a SAFE-TO-READ indicator and a 20 SAFE-TO-WRITE indicator. For a given process-file pair, the SAFE-TO-READ
inrlic~tor associated with the pair is set to a safe state on a request to read the file by the process if the security label of the process is found to dominate the security label of the file or if the security label of the process is raised as a result of the read.
Similarly, the SAFE-TO-WRITE inrlicator associated with the pair is set to a safe 25 state on a request to write the file if the label of the file dominates or is raised. All SAFE-TO-READ indicators for all other processes associated with the file are set to an unsafe state on a request to write the file when the file label is raised and all SAFE-TO- WRITE in(1i~ atnrs for all other files associated with the process are set to an unsafe state when the process label is raised.
30 Brief Description of the Drawin~
In the drawing, Fig. 1 shows the format of an illustrative security label in which one section defines a security level and a second section divides the security level into comp~ Illlents to which the security level applies;
Fig. 2 illustrates the relationship between files, processes, file descriptors and safe-to-read/write bits, which are used to reduce the label verification overhead in an illustrative system used to explain the invention;
Fig. 3 shows an illustrative flowchart of the verification process for 5 READ operations; and Fig. 4 shows an illustrative flowchart of the verification process for READ operations.
Detailed Description The dynamic security label method described herein has been 10 implçm.qnted in a research version of the UNIX operating system (UNIX is a registered tr~dem~rk of AT&T). The invention is described in terms of this operating system. However, it is understood that this imple~ nla~ion is illustrative of the preferred embodiment and in no way limits applicability of the invention to other ope~ g systems. In the UNIX system, processes (p) operate on files (f). A
15 given file may be associated at any given time with more than one process. Each such process-file relationship is identified by a file descriptor (d). Processes may spawn child processes, i.e., images of itself. Such child processes inherit certain characteristics of the parent process, such as a process security label. However, new file descliptcl~ are ge~ ed for a child process. Thus, file descriptors uniquely20 identify every instance of a process-file relationship. Another attribute of the UNIX
system is that media eYtçrn~l to a system are also represented by files. Thus, terminals, disk drives, tape drives and the like are represented internally in the system as files. Thus, a write to a termin~l is accomplished as a write to the intPrn~l file representing the t~nnin~l A further attribute of the UNIX system is its file 25 system which is divided into directories, which again are represented by files. Each directory can consist of ordinary files and other subdirectories, and so on.
Fig. 1 introduces the notion of a security label as being associated with a process (p) or with a file (f). The illustrative security label in Fig. 1 is divided into two sections. The first SECURITY LEVEL section stores a nllm~ric representation 30 of an overall security level. This section might consist of three bits and be binary encoded to represent the customary military document classification levels uncl~c~ifie~, confidential, secret and top secret. The second section of Fig. 1,SECURITY COMPARTMENTS, further partition the SECURITY LEVEL. These bits might, for example, represent individual countries to which the security level 35 applies. For example, the first two bits of SECURITY COMPARTMENTS might represent countries A and B, respectively. With the use of dynamic security labels, 200186;~
as files are read and written within the system, the labels associated with the files and with the processes performing the read and write operations are raised as necessary.
On a read operation, a process label is raised to dominate the label of a file being read. On a write operation, a file label is raised to dominate the label of a process 5 performing the write. However, in accordance with one aspect of the invention, the security labels associated with external media such as tçrmin~lc, disk drives, tape drives and the like are frozen and cannot be altered, except by mech~nicm~ having no relationship to the present invention. Thus, an attempt to write to a file representing an external mçAillm having a security label that does not dominate the 10 security label of the writing process is denied.
As one example of the use of dynamic labels, assume that a process is executing which has an initial security label 011 00... (secret security level with no clearance for countries A and B. Assume further that the process creates a new file NEWFILE. The new file initially may be labeled 000 00... by default. If the process 15 attempts to wIite the name of the file into a directory, the security label of the directory is raised, if nececc~ry~ to at least that of the process. Now assume that the process reads another file OLDFILE, which say is labeled confitlçnti~l for country A
(001 10...). In this case, the process label is raised to the logical union of the labels of the process and the file OLDFILE [(011 00...) UNION (001 10...) = (011 10...).
20 Finally, assume that the process aUC;Illpts to write OLDFILE to a file associated with an output tçrmin~l If the security label of the file associated with the terminal does not dominate that of OLDFILE, the write is denied.? Thus, security is m~int~ined.
The security labels of files and processes are raised as n.ocecs~ry for internaloperations of the system. At a point when external access is aUelllpted,however,25 access is denied unless the external access point has the proper authorization.
In the UNIX operating system, each file (f) that is opened by a process (p) is identified by a unique file descriptor (d). If two separate processes open the same file, each process-file pair is similarly identified by a dirr~len~ file descriptor, even though both processes are using the same file. Fig. 2 illustrates this process-file 30 arrangement. In this Fig., a file (f) and a process (p) are joined by dotted lines to a file descriptor (d). When the process refers to the file, it does so through theoperating system by means of the file descriptor. In accordance with the invention, two other indicators are associated with a file descriptor, a SAFE-TO-READ bit and a SAFE-TO- WRITE bit. These bits are shown in Fig. 2 as attached to the file 35 descriptor by means of a solid line. The SAFE bits allow use of the dynamic label security method with acceptable system overhead, as described below. In accordance with the invention, also associated with each file is an indicator FROZEN, as shown in Fig. 2. The state of this indicator identifies whether or not the security label of the file may be raised at read and write time. The use of this file attribute is discussed further below in connection with attempted writes of data to 5 media, such as tçrmin~l~, that are external to the system.
Fig. 3 and Fig. 4 show illustrative flowcharts of algorithms that are executed by the operating system each time a read or a write operation, respectively, is requested by a process. In Fig. 3, when a read operation is requested by a process, step 300 interrogates the SAFE-TO-READ bit associated with the file descriptor in 10 question. If the SAFE-TO-READ bit is set, this means that the security labels for this process and file have been verified on an earlier read operation and the labels raised, if necessary. The safe state of the bit implies that no further system operation has taken place since that time to invalidate the earlier verification. Thus, if the SAFE-TO-READ bit is set, the algorithm merely exits at 302 and other portions of15 the opel~ing system, not shown, perform the read operation.
If the SAFE-TO-READ bit is not set at step 300, then the process and file security labels are verified. Step 304 ~lçt~rminçs if the label of the file in question is domin~te~l by the label of the process requesting a read. If so, a read of the file by the process is p ~ led without any further ado. In this case, the SAFE-20 TO-READ bit is set at step 310 and exit is made at 312 to pelrc,llll the read operation.
At step 304, if the security label of the process does not dominate that of the file, then step 306 raises the label of the process by an a~propliate amount. In this illustrative embo~1iment, raising of the process label is performed by logically 25 ORing the present process label with the present file label. Next, at step 308, the operating system searches for and determines all file descriptors (d) that are associated with the present process (p). Step 308 then clears all the SAFE-TO-WRITE bits associated with the found file descriptors. This is necessary since the raising of the security label of the process has rendered future write operations by 30 this process unsafe without reverification. After these operations have been performed, step 310 set the SAFE-TO-READ bit for this particular file descriptorand exit is made at 312.
In Fig. 4, when a write operation is requested by a process, step 400 interrogates the SAFE-TO-WRITE bit associated with the file descriptor in question.
35 If the SAFE-TO-WRITE bit is set, this means that the security labels for this process and file have been verified on an earlier write operation and the labels raised, if ;~001863 necessary. The safe state of the bit implies that no further system operation has taken place since that time to invalidate the earlier verification. Thus, if the SAFE-TO-WRITE bit is set, the algorithm merely exits at 402 and other portions of theup~ldling system, not shown, perform the write operation.
If the SAFE-TO-WRITE bit is not set at step 400, then the process and file security labels are verified. Step 404 determines if the label of the file in question dominates the label of the process requesting a write. If so, a write of the file by the process is permitted without any further ado. In this case, the SAFE-TO-WRITE bit is set at step 414 and exit is made at 416 to perform the write operation.
Recall that write operations are subject to a special consideration, namely, that writes to an external medium are not permitted by merely raising the security label of the file associated with the medium. Rather, the security labels of such external media are frozen at their assigned states. Therefore, at step 404, if the security label of the file does not dominate that of the process, then step 406 15 determines if the file security label is frozen. If the label is frozen, the write operation is denied by pelrolllfing an error return to the operating system at 408. If the file security label is not frozen, step 410 raises the label of the file by an appr~l;ate amount. In this illustrative embodiment, raising of the process label is pc.roll,led by logically ORing the present process label with the present file label.
20 Next, at step 412, the opel~ling system searches for and determines all file descriptors (d) that are associated with the present file (f~. Step 412 then clears all the SAFE-TO-READ bits associated with the found file descriptors. Clearing of the SAFE-TO-READ bits is necessary since the raising of the security label of the file has rendered all future read operations of this file unsafe without reverification.
25 After these operations have been performed, step 414 sets the SAFE-TO-WRITE bit for this particular file descriptor and exit is made at 416 to perform the instant write operation.
It is to be understood that the above described arrangements are merely illustrative of the application of principles of the invention and that other 30 arrangements may be devised by wolhel~ skilled in the art without departing from the spirit and scope of the invention.
Claims (10)
1. We claim:
A method of administering secure access to files of a computer system, comprising:
a) associating a first security label with a file, b) associating a second security label with a process, c) comparing the first security label to the second security label in response to an attempt by the process to read (or write) the file, d) dynamically raising the security label of the destination (file or process) of a read (or write) operation of the file if the security label of thedestination does not dominate the security label of the source (file or process), CHARACTERIZED BY, e) setting an indicator associated with this process and with this file to a first state representing that the file is safe after performing step c), f) setting an indicator associated with every other process that is presently capable of accessing this file to a second state representing that the file is unsafe for the other processes if the security label is changed in step d), and g) omitting steps c) through f) on subsequent read (or write) attempts of the file by a process when the indicator associated with the process-file pair is set to the first state.
A method of administering secure access to files of a computer system, comprising:
a) associating a first security label with a file, b) associating a second security label with a process, c) comparing the first security label to the second security label in response to an attempt by the process to read (or write) the file, d) dynamically raising the security label of the destination (file or process) of a read (or write) operation of the file if the security label of thedestination does not dominate the security label of the source (file or process), CHARACTERIZED BY, e) setting an indicator associated with this process and with this file to a first state representing that the file is safe after performing step c), f) setting an indicator associated with every other process that is presently capable of accessing this file to a second state representing that the file is unsafe for the other processes if the security label is changed in step d), and g) omitting steps c) through f) on subsequent read (or write) attempts of the file by a process when the indicator associated with the process-file pair is set to the first state.
2. The method of claim 1 further comprising the step of associating with the security labels of predefined files a frozen status, whereby the security label of such files cannot be altered in response to attempted read or write operations.
3. The method of claim 2 wherein an attempt to write a file having frozen status and in which the security label of the process dominates that of the file is denied.
4. The method of claim 3 wherein such predefined files represent media external to the system.
5. The method of claim 4 wherein such media comprise access ports to the system.
6. The method of claim 5 wherein such access ports to the system comprise terminals, disk drives and tape drives.
7. The method of claim 1 wherein the indicator for a file-process pair further comprises a SAFE-TO-READ indicator and a SAFE-TO-WRITE indicator.
8. The method of claim 7 wherein step e) further comprises setting the SAFE-TO-READ indicator associated with a file-process pair to a safestate on a request to read a file by the process, and setting the SAFE-TO-WRITE indicator associated with a file-process pair to a safe state on a request to write a file.
9. The method of claim 7 wherein step f) further comprises setting all SAFE-TO-READ indicators for all other processes associated with the file to an unsafe state on a request to write the file.
10. The method of claim 7 wherein step f) further comprises setting all SAFE-TO-WRITE indicators for all other processes associated with thefile to an unsafe state on a request to read the file.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US07/277,630 US4984272A (en) | 1988-11-30 | 1988-11-30 | Secure file handling in a computer operating system |
| US277,630 | 1988-11-30 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CA2001863A1 CA2001863A1 (en) | 1990-05-31 |
| CA2001863C true CA2001863C (en) | 1995-12-05 |
Family
ID=23061714
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002001863A Expired - Fee Related CA2001863C (en) | 1988-11-30 | 1989-10-31 | Secure file handling in a computer operating system |
Country Status (4)
| Country | Link |
|---|---|
| US (1) | US4984272A (en) |
| EP (1) | EP0371673B1 (en) |
| JP (1) | JP2603344B2 (en) |
| CA (1) | CA2001863C (en) |
Families Citing this family (119)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5144660A (en) * | 1988-08-31 | 1992-09-01 | Rose Anthony M | Securing a computer against undesired write operations to or read operations from a mass storage device |
| US5315657A (en) * | 1990-09-28 | 1994-05-24 | Digital Equipment Corporation | Compound principals in access control lists |
| US5504814A (en) * | 1991-07-10 | 1996-04-02 | Hughes Aircraft Company | Efficient security kernel for the 80960 extended architecture |
| US5475833A (en) * | 1991-09-04 | 1995-12-12 | International Business Machines Corporation | Database system for facilitating comparison of related information stored in a distributed resource |
| US5627967A (en) * | 1991-09-24 | 1997-05-06 | International Business Machines Corporation | Automated generation on file access control system commands in a data processing system with front end processing of a master list |
| US5305456A (en) * | 1991-10-11 | 1994-04-19 | Security Integration, Inc. | Apparatus and method for computer system integrated security |
| US5454000A (en) * | 1992-07-13 | 1995-09-26 | International Business Machines Corporation | Method and system for authenticating files |
| IL103062A (en) * | 1992-09-04 | 1996-08-04 | Algorithmic Res Ltd | Data processor security system |
| AU675816B2 (en) * | 1992-12-14 | 1997-02-20 | Commonwealth Of Australia, The | Message document security |
| US5369707A (en) * | 1993-01-27 | 1994-11-29 | Tecsec Incorporated | Secure network method and apparatus |
| US5349643A (en) * | 1993-05-10 | 1994-09-20 | International Business Machines Corporation | System and method for secure initial program load for diskless workstations |
| US6604118B2 (en) | 1998-07-31 | 2003-08-05 | Network Appliance, Inc. | File system image transfer |
| US5963962A (en) | 1995-05-31 | 1999-10-05 | Network Appliance, Inc. | Write anywhere file-system layout |
| US7174352B2 (en) | 1993-06-03 | 2007-02-06 | Network Appliance, Inc. | File system image transfer |
| WO1994029795A1 (en) | 1993-06-04 | 1994-12-22 | Network Appliance Corporation | A method for providing parity in a raid sub-system using a non-volatile memory |
| US5572711A (en) * | 1993-09-28 | 1996-11-05 | Bull Hn Information Systems Inc. | Mechanism for linking together the files of emulated and host system for access by emulated system users |
| US5680452A (en) * | 1993-10-18 | 1997-10-21 | Tecsec Inc. | Distributed cryptographic object method |
| US5369702A (en) * | 1993-10-18 | 1994-11-29 | Tecsec Incorporated | Distributed cryptographic object method |
| KR100202941B1 (en) * | 1994-10-31 | 1999-06-15 | 배길훈 | Car collision type judging device taking advantage of three-direction speed reduction signal |
| US6724554B1 (en) | 1995-03-10 | 2004-04-20 | Iomega Corporation | Read/write protect scheme for a disk cartridge and drive |
| US5644444A (en) * | 1995-03-10 | 1997-07-01 | Iomega Corporation | Read/write protect scheme for a disk cartridge and drive |
| GB2299000B (en) * | 1995-03-14 | 1999-10-27 | Marconi Gec Ltd | A communications system |
| JPH08272625A (en) * | 1995-03-29 | 1996-10-18 | Toshiba Corp | Device and method for multiprogram execution control |
| US6011847A (en) * | 1995-06-01 | 2000-01-04 | Follendore, Iii; Roy D. | Cryptographic access and labeling system |
| JP4162099B2 (en) | 1995-06-02 | 2008-10-08 | 富士通株式会社 | Device having function to cope with virus infection and storage device thereof |
| US5999622A (en) * | 1995-11-22 | 1999-12-07 | Microsoft Corporation | Method and apparatus for protecting widely distributed digital information |
| US5692124A (en) * | 1996-08-30 | 1997-11-25 | Itt Industries, Inc. | Support of limited write downs through trustworthy predictions in multilevel security of computer network communications |
| US6367017B1 (en) | 1996-11-07 | 2002-04-02 | Litronic Inc. | Apparatus and method for providing and authentication system |
| US5844497A (en) * | 1996-11-07 | 1998-12-01 | Litronic, Inc. | Apparatus and method for providing an authentication system |
| US6268788B1 (en) | 1996-11-07 | 2001-07-31 | Litronic Inc. | Apparatus and method for providing an authentication system based on biometrics |
| US5920570A (en) * | 1996-11-26 | 1999-07-06 | Lucent Technologies Inc. | Reliable multi-cast queue |
| US7212632B2 (en) | 1998-02-13 | 2007-05-01 | Tecsec, Inc. | Cryptographic key split combiner |
| US6105132A (en) * | 1997-02-20 | 2000-08-15 | Novell, Inc. | Computer network graded authentication system and method |
| US5937159A (en) * | 1997-03-28 | 1999-08-10 | Data General Corporation | Secure computer system |
| US6212636B1 (en) | 1997-05-01 | 2001-04-03 | Itt Manufacturing Enterprises | Method for establishing trust in a computer network via association |
| US6694433B1 (en) * | 1997-05-08 | 2004-02-17 | Tecsec, Inc. | XML encryption scheme |
| US6192408B1 (en) * | 1997-09-26 | 2001-02-20 | Emc Corporation | Network file server sharing local caches of file access information in data processors assigned to respective file systems |
| US6516351B2 (en) | 1997-12-05 | 2003-02-04 | Network Appliance, Inc. | Enforcing uniform file-locking for diverse file-locking protocols |
| US7079653B2 (en) * | 1998-02-13 | 2006-07-18 | Tecsec, Inc. | Cryptographic key split binding process and apparatus |
| US8077870B2 (en) * | 1998-02-13 | 2011-12-13 | Tecsec, Inc. | Cryptographic key split binder for use with tagged data elements |
| US7095852B2 (en) * | 1998-02-13 | 2006-08-22 | Tecsec, Inc. | Cryptographic key split binder for use with tagged data elements |
| US6457130B2 (en) * | 1998-03-03 | 2002-09-24 | Network Appliance, Inc. | File access control in a multi-protocol file server |
| US6317844B1 (en) | 1998-03-10 | 2001-11-13 | Network Appliance, Inc. | File server storage arrangement |
| US6279011B1 (en) | 1998-06-19 | 2001-08-21 | Network Appliance, Inc. | Backup and restore for heterogeneous file server environment |
| US6574591B1 (en) | 1998-07-31 | 2003-06-03 | Network Appliance, Inc. | File systems image transfer between dissimilar file systems |
| US6119244A (en) * | 1998-08-25 | 2000-09-12 | Network Appliance, Inc. | Coordinating persistent status information with multiple file servers |
| AUPP660298A0 (en) * | 1998-10-20 | 1998-11-12 | Canon Kabushiki Kaisha | Apparatus and method for preventing disclosure of protected information |
| US6073106A (en) * | 1998-10-30 | 2000-06-06 | Nehdc, Inc. | Method of managing and controlling access to personal information |
| US6343984B1 (en) | 1998-11-30 | 2002-02-05 | Network Appliance, Inc. | Laminar flow duct cooling system |
| JP4294142B2 (en) | 1999-02-02 | 2009-07-08 | 株式会社日立製作所 | Disk subsystem |
| US20040034686A1 (en) * | 2000-02-22 | 2004-02-19 | David Guthrie | System and method for delivering targeted data to a subscriber base via a computer network |
| US7058817B1 (en) | 1999-07-02 | 2006-06-06 | The Chase Manhattan Bank | System and method for single sign on process for websites with multiple applications and services |
| US6961749B1 (en) | 1999-08-25 | 2005-11-01 | Network Appliance, Inc. | Scalable file server with highly available pairs |
| EP1085396A1 (en) | 1999-09-17 | 2001-03-21 | Hewlett-Packard Company | Operation of trusted state in computing platform |
| US7043553B2 (en) * | 1999-10-07 | 2006-05-09 | Cisco Technology, Inc. | Method and apparatus for securing information access |
| US7305475B2 (en) | 1999-10-12 | 2007-12-04 | Webmd Health | System and method for enabling a client application to operate offline from a server |
| US7519905B2 (en) * | 1999-10-12 | 2009-04-14 | Webmd Corp. | Automatic formatting and validating of text for a markup language graphical user interface |
| US7877492B2 (en) * | 1999-10-12 | 2011-01-25 | Webmd Corporation | System and method for delegating a user authentication process for a networked application to an authentication agent |
| US20040034833A1 (en) * | 1999-11-12 | 2004-02-19 | Panagiotis Kougiouris | Dynamic interaction manager for markup language graphical user interface |
| US20050028171A1 (en) * | 1999-11-12 | 2005-02-03 | Panagiotis Kougiouris | System and method enabling multiple processes to efficiently log events |
| US20020007284A1 (en) * | 1999-12-01 | 2002-01-17 | Schurenberg Kurt B. | System and method for implementing a global master patient index |
| US6883120B1 (en) | 1999-12-03 | 2005-04-19 | Network Appliance, Inc. | Computer assisted automatic error detection and diagnosis of file servers |
| US6715034B1 (en) | 1999-12-13 | 2004-03-30 | Network Appliance, Inc. | Switching file system request in a mass storage system |
| US8712792B2 (en) * | 2000-02-24 | 2014-04-29 | Webmd, Llc | Personalized health communication system |
| US8775197B2 (en) * | 2000-02-24 | 2014-07-08 | Webmd, Llc | Personalized health history system with accommodation for consumer health terminology |
| US8612245B2 (en) * | 2000-02-24 | 2013-12-17 | Webmd Llc | Personalized health history system with accommodation for consumer health terminology |
| US7103556B2 (en) * | 2000-11-02 | 2006-09-05 | Jpmorgan Chase Bank, N.A. | System and method for aggregate portfolio client support |
| GB2376763B (en) * | 2001-06-19 | 2004-12-15 | Hewlett Packard Co | Demonstrating integrity of a compartment of a compartmented operating system |
| US7065644B2 (en) * | 2001-01-12 | 2006-06-20 | Hewlett-Packard Development Company, L.P. | System and method for protecting a security profile of a computer system |
| GB0102515D0 (en) * | 2001-01-31 | 2001-03-21 | Hewlett Packard Co | Network adapter management |
| GB0102518D0 (en) * | 2001-01-31 | 2001-03-21 | Hewlett Packard Co | Trusted operating system |
| GB0102516D0 (en) * | 2001-01-31 | 2001-03-21 | Hewlett Packard Co | Trusted gateway system |
| GB2372592B (en) | 2001-02-23 | 2005-03-30 | Hewlett Packard Co | Information system |
| GB2372595A (en) * | 2001-02-23 | 2002-08-28 | Hewlett Packard Co | Method of and apparatus for ascertaining the status of a data processing environment. |
| US8849716B1 (en) | 2001-04-20 | 2014-09-30 | Jpmorgan Chase Bank, N.A. | System and method for preventing identity theft or misuse by restricting access |
| WO2002099598A2 (en) | 2001-06-07 | 2002-12-12 | First Usa Bank, N.A. | System and method for rapid updating of credit information |
| GB2376762A (en) * | 2001-06-19 | 2002-12-24 | Hewlett Packard Co | Renting a computing environment on a trusted computing platform |
| GB2376764B (en) * | 2001-06-19 | 2004-12-29 | Hewlett Packard Co | Multiple trusted computing environments |
| GB0114898D0 (en) * | 2001-06-19 | 2001-08-08 | Hewlett Packard Co | Interaction with electronic services and markets |
| CA2490695C (en) * | 2001-06-29 | 2014-08-12 | Michael Alfred Hearn | Security system and method for computers |
| US7962950B2 (en) * | 2001-06-29 | 2011-06-14 | Hewlett-Packard Development Company, L.P. | System and method for file system mandatory access control |
| US7266839B2 (en) * | 2001-07-12 | 2007-09-04 | J P Morgan Chase Bank | System and method for providing discriminated content to network users |
| GB2378013A (en) * | 2001-07-27 | 2003-01-29 | Hewlett Packard Co | Trusted computer platform audit system |
| GB2382419B (en) * | 2001-11-22 | 2005-12-14 | Hewlett Packard Co | Apparatus and method for creating a trusted environment |
| US7987501B2 (en) | 2001-12-04 | 2011-07-26 | Jpmorgan Chase Bank, N.A. | System and method for single session sign-on |
| GB0130690D0 (en) * | 2001-12-21 | 2002-02-06 | Esselte Nv | Label printer |
| US7318238B2 (en) * | 2002-01-14 | 2008-01-08 | Microsoft Corporation | Security settings for markup language elements |
| US20040158734A1 (en) * | 2002-02-01 | 2004-08-12 | Larsen Vincent Alan | System and method for process-based security in a portable electronic device |
| US20040093525A1 (en) * | 2002-02-01 | 2004-05-13 | Larnen Vincent Alan | Process based security tai building |
| US7249379B2 (en) * | 2002-02-01 | 2007-07-24 | Systems Advisory Group Enterprises, Inc. | Method and apparatus for implementing process-based security in a computer system |
| US20040243845A1 (en) * | 2002-02-01 | 2004-12-02 | Larsen Vincent Alan | System and method for process-based security in a network device |
| US20180165441A1 (en) | 2002-03-25 | 2018-06-14 | Glenn Cobourn Everhart | Systems and methods for multifactor authentication |
| US20030226014A1 (en) * | 2002-05-31 | 2003-12-04 | Schmidt Rodney W. | Trusted client utilizing security kernel under secure execution mode |
| US7134022B2 (en) * | 2002-07-16 | 2006-11-07 | Flyntz Terence T | Multi-level and multi-category data labeling system |
| US7058660B2 (en) | 2002-10-02 | 2006-06-06 | Bank One Corporation | System and method for network-based project management |
| US8301493B2 (en) * | 2002-11-05 | 2012-10-30 | Jpmorgan Chase Bank, N.A. | System and method for providing incentives to consumers to share information |
| JP2004234378A (en) * | 2003-01-30 | 2004-08-19 | Fujitsu Ltd | Security management device and security management method |
| US7265193B2 (en) * | 2003-01-31 | 2007-09-04 | Exxonmobil Chemical Patents Inc. | Polymerization process |
| US7296010B2 (en) * | 2003-03-04 | 2007-11-13 | International Business Machines Corporation | Methods, systems and program products for classifying and storing a data handling method and for associating a data handling method with a data item |
| US7373647B2 (en) * | 2003-04-30 | 2008-05-13 | International Business Machines Corporation | Method and system for optimizing file table usage |
| US20040268139A1 (en) * | 2003-06-25 | 2004-12-30 | Microsoft Corporation | Systems and methods for declarative client input security screening |
| US7669239B2 (en) * | 2003-09-15 | 2010-02-23 | Jpmorgan Chase Bank, N.A. | Secure network system and associated method of use |
| US7802294B2 (en) | 2005-01-28 | 2010-09-21 | Microsoft Corporation | Controlling computer applications' access to data |
| US7810153B2 (en) * | 2005-01-28 | 2010-10-05 | Microsoft Corporation | Controlling execution of computer applications |
| US8296162B1 (en) | 2005-02-01 | 2012-10-23 | Webmd Llc. | Systems, devices, and methods for providing healthcare information |
| US7650501B1 (en) * | 2005-02-15 | 2010-01-19 | Sun Microsystems, Inc. | System and methods for construction, fusion, prosecution, and maintenance of minimized operating environments |
| EP2194476B1 (en) | 2005-03-22 | 2014-12-03 | Hewlett-Packard Development Company, L.P. | Method and apparatus for creating a record of a software-verification attestation |
| US8078740B2 (en) * | 2005-06-03 | 2011-12-13 | Microsoft Corporation | Running internet applications with low rights |
| US8117441B2 (en) * | 2006-06-20 | 2012-02-14 | Microsoft Corporation | Integrating security protection tools with computer device integrity and privacy policy |
| US8185737B2 (en) | 2006-06-23 | 2012-05-22 | Microsoft Corporation | Communication across domains |
| US8127133B2 (en) * | 2007-01-25 | 2012-02-28 | Microsoft Corporation | Labeling of data objects to apply and enforce policies |
| US8380530B2 (en) | 2007-02-02 | 2013-02-19 | Webmd Llc. | Personalized health records with associative relationships |
| AU2008253593A1 (en) * | 2007-05-18 | 2008-11-27 | Secure Keys Pty Limited | A security token and system and method for generating and decoding the security token |
| US10019570B2 (en) * | 2007-06-14 | 2018-07-10 | Microsoft Technology Licensing, Llc | Protection and communication abstractions for web browsers |
| US9594901B2 (en) * | 2008-12-02 | 2017-03-14 | At&T Intellectual Property I, L.P. | Methods, systems, and products for secure access to file system structures |
| US8930324B2 (en) * | 2012-06-15 | 2015-01-06 | Russell A. Blaine | Guarded file descriptors |
| US10586076B2 (en) * | 2015-08-24 | 2020-03-10 | Acronis International Gmbh | System and method for controlling access to OS resources |
| US9674202B1 (en) | 2015-12-29 | 2017-06-06 | Imperva, Inc. | Techniques for preventing large-scale data breaches utilizing differentiated protection layers |
| US9674201B1 (en) | 2015-12-29 | 2017-06-06 | Imperva, Inc. | Unobtrusive protection for large-scale data breaches utilizing user-specific data object access budgets |
Family Cites Families (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4135240A (en) * | 1973-07-09 | 1979-01-16 | Bell Telephone Laboratories, Incorporated | Protection of data file contents |
| US4858117A (en) * | 1987-08-07 | 1989-08-15 | Bull Hn Information Systems Inc. | Apparatus and method for preventing computer access by unauthorized personnel |
| US4864616A (en) * | 1987-10-15 | 1989-09-05 | Micronyx, Inc. | Cryptographic labeling of electronically stored data |
| US4918653A (en) * | 1988-01-28 | 1990-04-17 | International Business Machines Corporation | Trusted path mechanism for an operating system |
| US4885789A (en) * | 1988-02-01 | 1989-12-05 | International Business Machines Corporation | Remote trusted path mechanism for telnet |
| US4926476A (en) * | 1989-02-03 | 1990-05-15 | Motorola, Inc. | Method and apparatus for secure execution of untrusted software |
-
1988
- 1988-11-30 US US07/277,630 patent/US4984272A/en not_active Expired - Lifetime
-
1989
- 1989-10-31 CA CA002001863A patent/CA2001863C/en not_active Expired - Fee Related
- 1989-11-21 EP EP89312048A patent/EP0371673B1/en not_active Expired - Lifetime
- 1989-11-30 JP JP1309440A patent/JP2603344B2/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| CA2001863A1 (en) | 1990-05-31 |
| EP0371673A3 (en) | 1991-04-03 |
| US4984272A (en) | 1991-01-08 |
| EP0371673B1 (en) | 1997-08-27 |
| JPH02194450A (en) | 1990-08-01 |
| EP0371673A2 (en) | 1990-06-06 |
| JP2603344B2 (en) | 1997-04-23 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CA2001863C (en) | Secure file handling in a computer operating system | |
| US8402269B2 (en) | System and method for controlling exit of saved data from security zone | |
| US7536524B2 (en) | Method and system for providing restricted access to a storage medium | |
| KR910005995B1 (en) | Method of protecting system files and data processing system | |
| CA2496664C (en) | Encrypting operating system | |
| US5414852A (en) | Method for protecting data in a computer system | |
| KR100450402B1 (en) | Access control method by a token with security attributes in computer system | |
| US8145900B2 (en) | Crypto-pointers for secure data storage | |
| US5265159A (en) | Secure file erasure | |
| US7570560B2 (en) | System and method for logical shredding of data stored on WORM media | |
| McIlroy et al. | Multilevel security in the UNIX tradition | |
| WO2005081115A1 (en) | Application-based access control system and method using virtual disk | |
| EP0407060B1 (en) | Method of providing mandatory secrecy and integrity file security in a computer system | |
| Hughes et al. | A universal access, smart-card-based, secure file system | |
| KR101227187B1 (en) | Output control system and method for the data in the secure zone | |
| EP1540444A2 (en) | Computer encryption systems | |
| EP1053519B1 (en) | A method of protecting data stored in the memory device of a computer system and equipment to carry out this method | |
| JPH10340232A (en) | File copy preventing device, and file reader | |
| CN1662981A (en) | Method and device for protecting user information against manipulations | |
| RO137262A2 (en) | Data protection system by access control of direct operations of data modification | |
| Wormington et al. | Secure DBMS | |
| JPS5865470A (en) | Software protection circuit | |
| Kochanski | Security considerations for encryption products | |
| Sion et al. | Towards Regulatory Compliance in Data Management | |
| JPH0387945A (en) | File security control system |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request | ||
| MKLA | Lapsed |