InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Secure execution of privileged scripts

IP.com Disclosure Number: IPCOM000187932D
Original Publication Date: 2009-Sep-18
Included in the Prior Art Database: 2009-Sep-18
Document File: 2 page(s) / 28K

Publishing Venue



Secure execution of privileged scripts

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

Page 1 of 2

Secure execution of privileged scripts

Role Based Access Control (RBAC) provides an ability for execution of privileged commands/operations for non-root users. The users will be able to execute them by virtue of the roles assigned to them. Historically users were granted the ability to execute privileged commands by setting up of the setuid bit on the command and modifying the owner to "root". RBAC on the other hand eliminates the need of setting up of the setuid bit on the command which is unsafe as the command would be executable by large set of users. RBAC provides the ability for controlled execution of privileged commands to selected set of users based on roles.

The commands could be one of binary executables or shell scripts. None of the current Unix* operating systems honor the setuid bit on shell scripts. This was due to the limitation in the way scripts get executed. The well known TOCTTOU (Time Of Check To Time Of Use) attack brings in a serious vulnerability issue because of which the current Unix operating systems dishonor setuid bits on scripts.

The RBAC implementation however allows enablement of scripts to authorized users. This triggers an issue that if a privileged script is executed by an authorized user, it is potentially possible to misuse the privileges (intended for the script) to be assigned to malicious piece of code. One way to recreate the issue is to execute the privileged script with a symbolic link. When such a script is executed, the link gets resolved to the target in the kernel (exec()) and if it is determined that the target is a privileged script, the corresponding set of privileges get assigned to the interpreter process (example: ksh). When the interpreter process begins execution, it parses through the script and executes each of the commands within it. The path to the script will be fed in the first argument to the interpreter process. The process parses the script after opening the same. At this point, the symbolic link gets resolved to the target at two occasions:

1. in exec()
2. open() which is invoked by the interpreter process

In-between these two time instances, it is quite possible to modify the link to point to a malicious script. By doing so, the interpreter process ends up opening the wrong script and executes it with certain set of privileges assigned during exec(). This is how the...