WO2016094990A1

WO2016094990A1 - Self-protecting file protection

Info

Publication number: WO2016094990A1
Application number: PCT/BR2015/000201
Authority: WO
Inventors: Fabio CAVALHEIRI MARENGHI; Heros DA SILVA ARAUJO; Thiago PEREIRA MORAIS; Paulo Márcio FIGUEIREDO ALVES
Original assignee: Gas Informatica Ltda
Priority date: 2014-12-15
Filing date: 2015-12-15
Publication date: 2016-06-23

Abstract

In example embodiments described herein, a device driver is employed to protect certain files. The device driver registers itself with an operating system and requests system notifications when a process attempts to delete, write data, or change attributes of a file. The device driver intercepts messages to delete, write data, or change attributes of a file and determines whether the request is for a protected file. If the request is for a protected file, the request is denied.

Description

Self Protecting File Protection

CROSS REFERENCE TO RELATED APPLICATIONS

[0001] This application claims priority to US Provisional Application No. 62/091 ,936, filed on December 15, 2014.

TECHNICAL FIELD

[0002] The present disclosure relates generally to computer systems and more particularly to protection of files.

BACKGROUND

[0003] Modern computers are controlled by operating systems that execute computer programs. The operating system manages files for computer programs. For example, the operating system will assist the application to create or provide access to files.

BRIEF DESCRIPTION OF THE DRAWINGS

[0004] The accompanying drawings incorporated herein and forming a part of the specification illustrate the example embodiments.

[0005] FIG. 1 is a simplified block diagram illustrating an example of a system with a self protection device driver that protects files in accordance with an example embodiment.

[0006] FIG. 2 illustrates an example of a computer system upon which an example embodiment can be implemented.

[0007] FIG. 3 is a block diagram illustrating an example of a methodology that registers a self protection device driver with an operating system to protect a file. OVERVIEW OF EXAMPLE EMBODIMENTS

[0008] The following presents a simplified overview of the example embodiments in order to provide a basic understanding of some aspects of the example embodiments. This overview is not an extensive overview of the example embodiments. It is intended to neither identify key or critical elements of the example embodiments nor delineate the scope of the appended claims. Its sole purpose is to present some concepts of the example embodiments in a simplified form as a prelude to the more detailed description that is presented later.

[0009] In example embodiments described herein, a device driver is employed to protect certain files. The device driver registers itself with an operating system and requests system notifications when a process attempts to delete, write data, or change attributes of a file. The device driver intercepts messages to delete, write data, or change attributes of a file and determines whether the request is for a protected file. If the request is for a protected file, the request is denied.

DESCRIPTION OF EXAMPLE EMBODIMENTS

[0010] This description provides examples not intended to limit the scope of the appended claims. The figures generally indicate the features of the examples, where it is understood and appreciated that like reference numerals are used to refer to like elements. Reference in the specification to "one embodiment" or "an embodiment" or "an example embodiment" means that a particular feature, structure, or characteristic described is included in at least one embodiment described herein and does not imply that the feature, structure, or characteristic is present in all embodiments described herein.

[0011] Described in an example embodiment herein is a technique that can protect an application's files from being deleted or windows. This technique employs a device drier that filters specific internal messages in ring 0 (or kernel mode), such as, for example for the WINDOWS operating system, DELETE, FILE_WRITE_DATA, FILE_WRITE_ATTRIBUTES, FILE_WRITE_EA, FILE_APPEND_ DATA, WRITE_DAC, or WRITEjDWNER.

[0012] The device driver registers itself with the operating system and requests to receive system notifications, such as I RP MJ CREATE messages (see e.g., http://msdn. microsoft.com/en-us/library/windows/hardware/ff 548630%28v=vs.85 %29.aspx), from the operating system. For example, for the Microsoft WINDOWS operating system, the device driver may use a pre operation routine, such as PFLT_PRE_OPERATION_CALLBACK, or a post operation callback routine, such as PFLT_POST_OPERATlON_CALLBACK routine for each type of I/O operation that the device driver handles, such as IRP_MJ_CREATE messages, see e.g., http://msdn. microsoft.com/en-us/library/windows/hardware/ff 544668%28v=vs.85%29.aspx and http://msdn. microsoft. com/en-us/library/windows/hardware/ff544687%28v^:=vs.85⁰/o29.aspx. Upon registration, the system's I/O Manager sends an IRP_MJ_CREATE request when a new file or directory is being created, or when an existing file, device, directory, or volume is being opened. For example, when an application sends a file input or output (input/output or I/O) request, the request is intercepted device driver. The device driver then determines whether the I/O request is for a protected (or predefined) file. If the request is for a protected file, the request is prevented from executing. Optionally, an "access denied" response may be returned to the operating system. If the request is not for a protected file, the request is allowed to continue executing.

[0013] FIG. 1 is a simplified block diagram illustrating an example of a system 100 with a self protection (device) driver 102 that protects files in accordance with an example embodiment. The self protection device driver 102 registers itself with the operating system (OS) kernel 106 to receive notifications from an operating system when a predetermined file system request is by sent by an operating system file input/output manager 108. For example, whenever the File I/O manager 108 sends a IRP_MJ_CREATE request.

[0014] The self protection device driver 102 then intercepts a notification from the operating system's file I/O manager 108 that a process has made a file input/output (I/O) request for a file that generated the predetermined file system request. The self protection device driver 102 determines whether the file in the file system request contains data representative of a protected file. If the file I/O request is for a protected file, the self protection device driver 102 prevents further execution of the file I/O request. The self protection device driver 102 may also send data to the operating system indicating access to the file is denied responsive to determining that the file system request contains data representative of a protected file. If the file I/O request is not for a protected file, then the request is allowed to continue executing.

[0015] For example, if a first process sends a first file I/O request for a protected file, the file I/O manager 108 notifies the self protection device driver 102 of the first request (e.g., the self protection device driver 102 intercepts the request). Because the first request is for a protected file, the self protection device driver 102 blocks the file I/O request. However, if the first or another (e.g., second) process sends a second request for an unprotected (not predefined) file, the self protection device driver 102 intercepts the second request, and upon determining that the second request is not for a protected file, allows the second request to pass through. The file I/O request may be a request to delete a file, write data to the file, or change the attributes of the file. For example, in the Windows environment, the I/O request may be any of DELETE, F I L E_WR I TE DATA , F!LE_WRITE_ATTRIBUTES, FILE_WRITE_EA, FILE_APPEND_DATA, WRITE_DAC_WR!TE_OWNER. In particular embodiments, the intercepted file system requests are sent from the kernel mode.

[0016] FIG. 2 illustrates an example of a computer system 200 upon which an example embodiment can be implemented. For example, computer system 200 may be employed for implementing components of system 100 described in FIG..

[0017] Computer system 200 includes a bus 202 or other communication mechanism for communicating information and a processor 204 coupled with bus 202 for processing information. Computer system 200 also includes a main memory 206, such as random access memory (RAM) or other dynamic storage device coupled to bus 202 for storing information and instructions to be executed by processor 204. Main memory 206 also may be used for storing a temporary variable or other intermediate information during execution of instructions to be executed by processor 204. Computer system 200 further includes a read only memory (ROM) 208 or other static storage device coupled to bus 202 for storing static information and instructions for processor 204. A storage device 210, such as a magnetic disk or optical disk, is provided and coupled to bus 202 for storing information and instructions.

[0018] An aspect of the example embodiment is related to the use of computer system 200 for a self protecting process. According to an example embodiment, a self protecting process is provided by computer system 200 in response to processor 204 executing one or more sequences of one or more instructions contained in main memory 206. Such instructions may be read into main memory 206 from another computer-readable medium, such as storage device 210. Execution of the sequence of instructions contained in main memory 206 causes processor 204 to perform the process steps described herein. One or more processors in a multi-processing arrangement may also be employed to execute the sequences of instructions contained in main memory 206. In alternative embodiments, hard-wired circuitry may be used in place of or in combination with software instructions to implement an example embodiment. Thus, embodiments described herein are not limited to any specific combination of hardware circuitry and software.

[0019] The term "computer-readable medium" as used herein refers to any medium that participates in providing instructions to processor 204 for execution. Such a medium may take many forms, including but not limited to non-volatile media. Non-volatile media include for example optical or magnetic disks, such as storage device 210. Common forms of computer-readable media include for example floppy disk, a flexible disk, hard disk, magnetic cards, paper tape, any other physical medium with patterns of holes, a RAM, a PROM, an EPROM, a FLASHPROM, CD, DVD or any other memory chip or cartridge, or any other medium from which a computer can read.

[0020] In view of the foregoing structural and functional features described above, a methodology 300 in accordance with an example embodiment will be better appreciated with reference to FIG. 3. While, for purposes of simplicity of explanation, the methodology 300 of FIG 3 is shown and described as executing serially, it is to be understood and appreciated that the example embodiment is not limited by the illustrated order, as some aspects could occur in different orders and/or concurrently with other aspects from that shown and described herein. Moreover, not all illustrated features may be required. The methodology 300 described herein is suitably adapted to be implemented in logic. "Logic", as used herein, includes but is not limited to hardware, firmware, software and/or combinations of each to perform a function(s) or an action(s), and/or to cause a function or action from another component. For example, based on a desired application or need, logic may include a software controlled microprocessor, discrete logic such as an application specific integrated circuit (ASIC), a programmable/programmed logic device, memory device containing instructions, or the like, or combinational logic embodied in hardware. Logic may also be fully embodied as software that performs the desired functionality when executed by a processor. For example, methodology 300 may be implemented by the self protection device driver 102 described in FIG. 1 or the processor 204 described in FIG. 2.

[0021] At 302, a driver registers itself with the operating system (OS) kernel, to receive notifications from an operating system when a predetermined file system request is by sent by an operating system file input/output manager 108. For example, whenever a File System I/O manager sends a IRP MJ CREATE request,

[0022] At 304, the driver intercepts a notification from the operating system that a process has made a file input/output (I/O) request for a file. At 306, the driver determines whether the requested file is for a protected (or predefined) file.

[0023] If, at 306, the file I/O request was determined to be for a predefined file (YES), at 308, the driver 102 prevents further execution of the file I/O request. The driver may also return an "access denied" response to the operating system. If, however, at 306 the file I/O request was determined not to be for a predefined or protected file (NO), at 310, the request is allowed to continue executing.

[0024] For example, if a first process sends a first file I/O request for a protected file, the driver intercepts the first request. Because the first request is for a protected file, the driver 102 blocks the file I/O request. However, if the first or another (e.g., second) process sends a second request for an unprotected (not predefined) file, the driver intercepts the second request, and upon determining that the second request is not for a protected file, allows the second request to pass through. The file I/O request may be a request to delete a file, write data to the file, or change the attributes of the file. For example, in the Windows environment, the I/O request may be any of DELETE, F I L E_WR I TE_D ATA , FILE_WRITE_ATTRIBUTES, FILE_WRITE_EA, FILE_APPEND_DATA, WRITE_DAC_WRITE_OWNER. In particular embodiments, the intercepted file system requests are sent from the kernel mode.

[0025] Described above are example embodiments. It is, of course, not possible to describe every conceivable combination of components or methodologies for purposes of describing the example embodiments, but one of ordinary skill in the art will recognize that many further combinations and permutations of the example embodiments are possible. Accordingly, it is intended to embrace all such alterations, modifications and variations that fall within the spirit and scope of any claims filed in applications claiming priority hereto interpreted in accordance with the breadth to which they are fairly, legally and equitably entitled.

Claims

CLAIM(S)

1. A tangible, non-transitory computer readable medium of instructions with instructions encoded thereon for execution by a processor and when executed operable to:

register with an operating system to receive notifications from an operating system when a predetermined file system request is by sent by an operating system file input/output manager;

intercept a notification from the operating system that a process has made a file input/output request for a file that generated the predetermined file system request;

determine whether the file in the file system request contains data representative of a protected file; and prevent the execution of the file input/output request responsive to determining that the file system request contains data representative of a protected file.

2. The tangible, non-transitory computer readable medium of instructions of claim 1 , the instructions are operable to return data to the operating system indicating access to the file is denied responsive to determining that the file system request contains data representative of a protected file.

3. A tangible, non-transitory computer readable medium of instructions of claim 1 , the instructions are further operable to:

receive a notification from the operating system that a second process has made a second file input/output request for a second file that generated a second predetermined file system request;

determine whether the second file in the second file system request contains data representative of a protected file; and

allow the second process to access the second file responsive to determining that the second file system request does not contain data representative of a protected file.

4. The tangible, non-transitory computer readable medium of instructions of claim 1, wherein the predetermined file system request is an IRP MJ CREATE request.

5. The tangible, non-transitory computer readable medium of instructions of claim 1, wherein the file input/output request is a one of a group consisting of a process requesting to delete the file and the process requesting to write to the file.

6. The tangible, non-transitory computer readable medium of instructions of claim 1, wherein the file input/output request is one of a group consisting of DELETE, FILE_WRITE_DATA, FILE_WRITE_ATTRIBUTES, FILE_WRITE_EA, FILE_APPEND_DATA, WRITE JDAC_WRITE_OWNER.

7. The tangible, non-transitory computer readable medium of instructions of claim 1, wherein the predetermined file system request is sent in kernel mode.

8. An apparatus, comprising:

a processor;

logic encoded on a tangible, non-transitory computer readable medium for execution by the processor and when executed operable to:

determine whether the file in the file system request contains data representative of a protected file; and

prevent the execution of the file input/output request responsive to determining that the file system request contains data representative of a protected file.

9. The apparatus set forth in claim 8, the logic is further operable to return data to the operating system indicating access to the file is denied responsive to determining that the file system request contains data representative of a protected file.

10. The apparatus set forth in claim 9, the logic is further operable to:

11. The apparatus set forth in claim 8, wherein the predetermined file system request is an IRP_MJ_CREATE request.

12. The apparatus set forth in claim 8, wherein the file input/output request is a one of a group consisting of a process requesting to delete the file and the process requesting to write to the file.

13. The apparatus set forth in claim 8, wherein the file input/output request is one of a group consisting of DELETE, FILE_WRITE_DATA, FILE_WRITE_ATTRIBUTES, FILE_WRITE_EA, FILE_APPEND_DATA, WRITE_DAC_WRITE_OWNER.

14. The apparatus set forth in claim 8, wherein the predetermined file system request is sent in kernel mode.

15. A method, comprising:

registering with an operating system to receive notifications from the operating system when a predetermined file system request is by sent by an operating system file input/output manager;

intercepting a notification from the operating system that a process has made a file input/output request for a file that generated the predetermined file system request;

determining whether the file in the file system request contains data representative of a protected file; and

preventing the execution of the file input/output request responsive to determining that the file system, request contains data representative of a protected file.

16. The method of claim 15, further comprising returning data to the operating system indicating access to the file is denied responsive to determining that the file system request contains data representative of a protected file.

17. the method of claim 16, further comprising:

receiving a notification from the operating system that a second process has made a second file input/output request for a second file that generated a second predetermined file system request; determining whether the second file in the second file system request contains data representative of a protected file; and

allowing the second process to access the second file responsive to determining that the second file system request does not contain data representative of a protected file.

18. The method of claim 15, wherein the predetermined file system request is an IRP_MJ_CREATE request.

19. The method of claim 15, wherein the file input/output request is a one of a group consisting of a process requesting to delete the file and the process requesting to write to the file.

20. The method of claim 16, wherein the file input/output request is one of a group consisting of DELETE, F I LE_WR I T E_D AT A , FILE_WRITE_ATTRIBUTES, FILE_WRITE_EA, F I LE_APP E N D_D ATA , WRITE_DAC_WRITE_OWNER.