Browse Prior Art Database

Method to trust the file based arguments passed to trusted/privileged commands

IP.com Disclosure Number: IPCOM000247766D
Publication Date: 2016-Oct-06
Document File: 3 page(s) / 27K

Publishing Venue

The IP.com Prior Art Database

Abstract

This article discusses a unique method of letting a process work on trusted data. This method builds the user's confidence/trust in the data that their programs are using. This method fits along side the "trusted" execution of executables. The trusted execution has mechanisms to prevent a executable from being loaded, if that executable is not trusted. This article discusses a solution to trust arguments (file arguments) that are passed to trusted executables, and only allow "trusted" arguments to be loaded and processed by the executables.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 43% of the total text.

Page 01 of 3

Method to trust the file based arguments passed to trusted /privileged commands

Disclosed is a method to enable trusted processes to trust the data or input that they process. The discussed method is mainly around file arguments, where such file arguments in turn contain other commands that need to be executed. But the same solution can be extended to processes that use configuration files or other data files.

In the current RBAC (Role Based Access Control) mechanisms there is a limitation which if exploited by a malicious user (a user who has inadvertently/ accidentally gained authorization) could lead to the system being compromised. This is seen in those unix commands which accept another executable/script file as an argument (file_argument) and execute commands from the file_argument.

A typical syntax of such commands could be:

-file

(where -file denotes any option that specifies that the argument that follows is a file name).

Let's call this command "FArgsCmd" for ease of explanation. FArgsCmd when executed, in turn executes the commands present in file_argument. FArgsCmd is just an example. End users can have custom scripts that might span across OS subsystems. For eg, FArgsCmd could be a command to optimize the system performance or FArgsCmd could be a command to monitor the health of the system which spans across different OS sub-systems. If the FArgsCmd command spanned across OS subsystems, during its execution it might get a set of privileges to do activities across the system.

To elaborate the flaw, lets create a user foo who has the authorization to execute FArgsCmd. Say that the user's account was compromised by a malicious named 'mal' user. Then this mal user would now have authorization to execute FArgsCmd command as well. What if this mal user now creates his own file_argument with a set of malicious commands and passes it to FArgsCmd? The FArgsCmd process having the privilege to exec the commands within the file_argument passed to it would execute the malicious commands within file_arugment. This could end up compromising the whole system.

Note that via access control mechanisms like Role Based Access Control and others, the user foo/mal cannot execute any other privileged commands at command line, but can execute the FArgsCmd privileged command. By virtue of the privileges to execute FArgsCmd, which could span across various OS sub systems, a malicious user can make FArgsCmd command execute commands belonging to these OS sub systems via file_argument.

The solution is to enable commands like FArgsCmd accept only those file based arguments that have been verified by another trusted or authorized user (other than the user who created this file_argument). These files will now become trusted entities. Trusted/privileged commands must be made to work only on Trusted data/arguments.

Implementation:

1


Page 02 of 3

When commands like FArgsCmd are executed, these commands first need to look up a trusted database created f...