Browse Prior Art Database

Security layer to prevent access to file system objects from malicious code Disclosure Number: IPCOM000126911D
Original Publication Date: 2005-Aug-10
Included in the Prior Art Database: 2005-Aug-10
Document File: 2 page(s) / 66K

Publishing Venue



In this article, we present an extension of the security layers of common file systems such as Unix and NTFS that is based on process attributes such as the paths of the executable, their size, checksum and so on.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 53% of the total text.

Page 1 of 2

Security layer to prevent access to file system objects from malicious code

Common file systems provide security layers that are based on user credentials. Each file system object (such as a folder, a file, a link) is associated to a security descriptor (the actual name may vary depending on the operating system) that enlists which users and/or user groups are allowed to access it and which operations can be done. In other words, the security descriptor describes WHO can access the file system object and WHAT it can do over it.

In times of viruses and other internet threats, this security model may be too weak or inadequate in some cases:

    Threat 1) A malicious code can be spawned using the current user credentials (for example while browsing the internet) and can therefore access the file systems objects for which the user is entitled to access.

    Threat 2) Some executable can be replaced on the file system without user consent and/or for malicious ends. Let's say the process A spawns the process B to perform some tasks. If B is replaced with something else that nevertheless exposes the same interface, process A may not notice the difference and thus trigger, by calling some API of the replaced B executable, an unwanted (and maybe dangerous) behavior.

    Threat 3) Some application-specific files, such as database files, are normally not conceived to be accessed by any other process than the one which created them. Another process may unintentionally or maliciously damage these files by writing on it if the user credentials are such to allow the operation.

    For the reasons exposed above, we think it is worth to provide file systems with an additional security layer based on the attributes of the caller process. Some of these attributes may be:

- the path of the executable and its name - a binary checksum of the executable - the size of the executable - the name of the company who created executable (it may be too naive to rely on this though) - the version of the executable

    So, for example, back to the database example, we may declare that the database files can be accessed in writing only by a process that runs on an executable which name is db2syscs.exe, is located under the DB2 directory (C:\Program Files\IBM\SQLLIB\bin), has size 103544 bytes and check...