Condor Sandbox Team
The Technion DSL Lab, Israel
Condor Local File System Sandbox
High Level Design Document
High Level Design Document
1
Condor Sandbox Team
The Technion DSL Lab, Israel
1 Table of Contents
1
Table of Contents
2
2
Introduction
3
3
Desired Architecture
3
3.1 The Policy Files
4
3.1.1 Description
4
3.1.2 Policy File Structure
4
3.1.3 Policy Memory Representation Structure
5
3.2 The SandBox Service
3.2.1 Description
6
6
3.2.2 Communication protocol between the Condor_Starter
and the Sandbox Service
6
3.2.3 Communication protocol between the Sandbox Service
and the Sandbox Driver
7
3.3 The SandBox Driver
9
3.3.1 Description
9
3.3.2 Technical Notes
9
3.4 Condor_Starter changes
10
3.4.1 Description
10
3.4.2 Technical Notes
10
3.5 General Guidelines
10
3.6 Appendices
11
3.6.1 C-style definitions of the Policy Data Structures
11
3.6.2 RPC Interface for controlling the Sandbox Service from
the Condor_Starter (IDL file)
11
3.6.3 Sequence Diagram – Spawning a new Condor Job
12
3.6.4 Sequence Diagram – Handling a file system access
request
13
High Level Design Document
2
Condor Sandbox Team
The Technion DSL Lab, Israel
2 Introduction
This is the High Level Design Document of the Condor File System
Sandbox project.
This document is based on the Team meetings that were held,
during of which the architecture was defined.
Since the requirements nearly enforce a specific design this
document will only extend the suggested and approved
architecture defined in the Requirements Document.
The main goal of this document is to elaborate the cross
component communication means and protocols and to bring a
high-level design of the various components and structures that
will be used.
3 Desired Architecture
It is obvious that the Sandbox, in its core, needs to be developed
as a filter driver. Since in this manner the sandboxing will be done
in kernel mode and that will ensure that the sandbox cannot be
easily hacked.
In order for the Sandbox to be as non-dependent of the Condor
system as possible, in respect of notifying the Sandbox when a
Condor-job terminates, there is a need for a dependent application
that will intercept the death of the Condor-jobs and will notify the
Sandbox driver.
For that application to be trustworthy, it needs to run in elevated
privileges so that it cannot be brutally terminated.
Such a goal can be achieved by making this application a
Windows Service application.
Further more, the Condor system will have to be slightly altered in
order for the Sandbox to be notified of newly spawned Condor-job.
The change needs to be done in a Condor component that is run
in elevated user rights so that the Sandbox can trust the incoming
configuration changes.
The following diagram (taken from the Requirements Document)
describes the high-level architecture and the sandboxing process:
High Level Design Document
3
Condor Sandbox Team
The Technion DSL Lab, Israel
CondorMaster Service
1
Execute
"ExeName.exe" under
the "ProcessPolicy.txt"
Policy restrictions
Condor_Startd Service
2
SandBox Service
3
Condor_Starter Process
Restrict (PID=134, User=Condor1) using
the Process Policy in "ProcessPolicy.txt"
5
6
A CondorJob Process
4
User mode
Kernel mode
SandBox Driver
System Policy
Path
AccessType
.\
Read
C:\Win\k.dll Read
Action
Allow
Deny
Process Policy Dictionary
PID
User
… ProcPolicy
7.a
7.b
134
8
File System
Condor1
7.c
Process Policy
Path
AccessType
C:\Temp\* Read
C:\
Read
Action
Allow
Deny
Figure1: The sandboxing process
3.1 The Policy Files
3.1.1 Description
The Policy Files will be text files that shall maintain a well-defined
syntax.
They shall be validated for correctness in the context of a usermode process, specifically, in the Sandbox Service.
The following sections describe the file syntax of the Policy Files
and the Data Structure that represents a Policy file.
3.1.2 Policy File Structure
1) The format of the policy file (a long string of rules) should
comply to the following guildlines
a. The three parts of a rule must be surrounded by ‘<’ and
‘>’.
High Level Design Document
4
Condor Sandbox Team
The Technion DSL Lab, Israel
i. These parts are formally describe in the
Requirements Document
b. Every two consecutive rules should be separated by a
semi-colon (‘;’).
c. An example for a correct policy file is:
<path1> <access1> <action1> ; <path2> <access2>
<action2> ; …
3.1.3 Policy Memory Representation Structure
1) The major data structure of the filter driver is the policies
hash table
a. The Hash table (PolicyDictionary) will be implemented
as a static sized array with entries of type
SB_POLICY_ENTRY.
b. Each entry (SB_POLICY_ENTRY) holds the process
ID of its associated process and a linked list of the
policy rules.
c. Each policy rule (SB_POLICY_RULE) contains the
path-name, access rights and action as described in
the Requirements Document.
2) (Optional) Another hash table is used for performance
issues:
d. The hash table maps file objects to policy rules. The
table is used in order to prevent searching for the
matching rule each time when exactly the same
request is made.
a. Since the policy rules are static – the request will
result in the same policy rule and the same
action to perform.
e. Each entry (SB_RULE_ENTRY) holds a pointer to a
linked list of nodes for a file object that was accessed
during the operation of the driver.
f. Each node (SB_RULE_NODE) holds a process ID
associated with its rule and a pointer to the rule from
the policies hash table.
3) Each hash table is protected by a dedicated synchronization
object to prevent asynchronous updating of the data causing
data corruption.
High Level Design Document
5
Condor Sandbox Team
The Technion DSL Lab, Israel
4) The following diagram denotes the structures:
Hash bucket Hash bucket Hash bucket
Static Size Array
Policy Dictionary
Policy
Entry
Policy
Entry
Policy
Entry
Policy
Rule
Policy
Entry
Policy
Entry
Policy
Rule
Policy
Rule
Priority 2
Rule Entry
Rule Entry
Rule Entry
Rule Node
…
Rule Entry
Rule Node
3.2 The SandBox Service
3.2.1 Description
The Sandbox Service will be implements as a standard Windows
Service.
The Service will use RPC to communicate with the
Condor_Starter; this will ensure better security and robustness.
3.2.2 Communication protocol between the Condor_Starter
and the Sandbox Service
1) The communication will be done via RPC
High Level Design Document
6
Condor Sandbox Team
The Technion DSL Lab, Israel
a. In a bullet bellow, the RPC functions will be referred to
as 'messages', since this will describe the protocol and
not the RPC functions prototypes
b. For the RPC function definition see Appendix 3.6.2
("RPC Interface for controlling the Sandbox Service
from the Condor_Starter")
2) On the Service side the request will be processed only if it
originated from a process running in context of the "Local
Service" account
3) The following messages will be used to communicate
between the Condor_Starter and the Sandbox Service
a. SandboxNewJob
i. Parameters
1. PID [in]– the Process ID of the newly
spawned (suspended) Condor job
2. PolicyFileMemFile [in]– A Policy File loaded
into the memory as a long sting
ii. Return Value
1. true – The Condor job's Process Policy was
successfully added to the Driver's
PolicyDictionary
a. Condor_Starter can resume the
suspended process
2. false – The Condor job's Process Policy
was not added to the Driver's
PolicyDictionary
a. Condor_Starter should terminate the
suspended process
iii. This function is blocking – execution will not
continue until it returns
3.2.3 Communication protocol between the Sandbox Service
and the Sandbox Driver
1) The communication will be done by issuing IOCTLs (sent via
the DeviceIoControl() function)
2) All parameters that should pass from/to the Driver will be
done using the DeviceIoControl() function's Input/Output
buffers
3) On the Driver side the request will be processed only if it
originated from a process running in context of the "Local
Service" account
4) Issuing any IOCTL from the following list will block the
Service from continuing execution
High Level Design Document
7
Condor Sandbox Team
The Technion DSL Lab, Israel
a. It will block only the thread that issued the call, other
worker thread will not be blocked
5) The following IOCTLs will be defined
a. IOCTL_SB_ACTIVATE
i. This IOCTL will instruct the Sandbox Driver to
enable the monitoring and restricting mechanism
ii. Parameters
1. ReturnValue [out] – A boolean describing
whether or not the operation was
successfully
iii. By default the Driver will not need this IOCTL to
start sandboxing, since it will, by default, start it
when it loads
iv. If returns 'false' (not successfully), the Service
should block all spawning processes from
resuming (by returning 'false' to any
SandboxNewJob() RPC call)
b. IOCTL_SB_DEACTIVATE
i. This IOCTL will instruct the Sandbox Driver to
stop monitoring the file system
1. No accesses to the file system will be
forbidden by the Driver, after this IOCTL is
processed.
ii. Parameters
1. ReturnValue [out] – A boolean describing
whether or not the operation was
successfully
iii. If Condor jobs are during execution when this
IOCTL is issued the return value will indicate a
failure
1. If the Service wishes to forcefully
deactivate the Driver it should first
terminate all Condor jobs
c. IOCTL_SB_LOAD_SYSTEM_POLICY
i. This IOCTL will instruct the Sandbox Driver to
load the System Policy
ii. Parameters
1. PolicyStructure [in] – The structure that
represents the System Policy file.
2. ReturnValue [out] – A boolean describing
whether or not the operation was
successfully
High Level Design Document
8
Condor Sandbox Team
The Technion DSL Lab, Israel
iii. Until this call is issued, the only effective rule is
the built-in "Deny All" rule.
iv. This IOCTL can be issued at any time the Driver
is loaded. It does not matter if the Driver is
activated or deactivated.
d. IOCTL_SB_SANDBOX_NEW_JOB
i. This IOCTL will instruct the Sandbox Driver to
load a new Process Policy and to activate the
sandbox on the new Condor job
ii. Parameters
1. PID [in] – The Process ID of the newly
spawned (suspended) Condor job
2. PolicyStructure [in] – The structure that
represents the Process Policy file.
3. ReturnValue [out] – A boolean describing
whether or not the operation was
successfully
iii. If returns 'false' (not successfully), the Service
should cause the spawned process to terminate
at once (by returning 'false' to the
SandboxNewJob call)
iv. Only if this IOCTL returns 'true', should the
Condor_Starter, eventually, resume the
suspended Condor job.
3.3 The SandBox Driver
3.3.1 Description
This software component is the only code that will run in kernel
mode.
Being a kernel-resident component will make it harder for any
hacker to detour the restriction mechanism it imposes.
Its main goal is to restrict the file-system IRPs that are sent via the
Condor-jobs according to the Policies described above.
It will be updated with the relevant System and Policy Files by the
Sandbox Service.
3.3.2 Technical Notes
1) Device specific information is kept regarding which driver
and device (File System) the filter driver is attached to.
2) This also helps to distinguish between calls made by the
Sandbox Service to the driver and calls made by Condor
High Level Design Document
9
Condor Sandbox Team
The Technion DSL Lab, Israel
jobs or other applications to a file system (and which pass
through the filter driver).
3.4 Condor_Starter changes
3.4.1 Description
The Condor_Starter's code will be altered so that it will notify the
Sandbox of a newly spawned Condor jobs.
Condor_Starter is run under the context of a System user account
and therefore will guaranty that the Sandbox Service can, and will,
trust it.
The Condor_Starter will spawn the new Condor job in suspended
mode and will only resume it if the Sandbox Service will approve
that the Sandbox Driver is ready for sandboxing this process.
For more details, refer to the Requirements Document.
3.4.2 Technical Notes
See the section 3.2.2 ("Communication protocol between the
Condor_Starter and the Sandbox Service") for more details on
success and fail paths behaviors.
3.5 General Guidelines
1) All functions written in the driver will be written in C and will
maintain the FileMon coding conventions
a. The data structures are global variables.
b. The functions receives all its input and output as
parameters.
c. The functions return a Boolean as result.
High Level Design Document
10
Condor Sandbox Team
The Technion DSL Lab, Israel
3.6 Appendices
3.6.1 C-style definitions of the Policy Data Structures
enum short _action {
DENY,
ALLOW
} ACTION;
typedef struct _policyentry {
HANDLE
Pid;
struct _policyentry *Next;
PSB_POLICY_RULE PolicyRules; // Pointer the the first object of a
linked list of rules.
} SB_POLICY_ENTRY, *PSB_POLICY_ENTRY;
typedef struct _policyrule {
PCHAR
PathName;
DWORD
DesiredAccess;
ACTION
Action;
struct _policyrule
*Next;
} SB_POLICY_RULE, *PSB_POLICY_RULE;
typedef struct _rulenode {
PSB_POLICY_RULE PolicyRule;
struct _rulenode
*Next;
} SB_RULE_NODE, *PSB_RULE_NODE;
typedef struct _ruleentry {
PFILE_OBJECT
FileObject;
struct _nameentry
*Next;
PSB_RULE_NODE
RuleNode;
} SB_RULE_ENTRY, *PSB_RULE_ENTRY;
3.6.2 RPC Interface for controlling the Sandbox Service from
the Condor_Starter (IDL file)
[
uuid(e1d84f53-a8b8-43d5-8960-e293d044a751),
version(1.0)
]
interface SBSControl
{
bool SandboxNewJob(
HANDLE PID,
_TCHAR PolicyFileMemFile);
}
High Level Design Document
11
Condor Sandbox Team
The Technion DSL Lab, Israel
3.6.3 Sequence Diagram – Spawning a new Condor Job
High Level Design Document
12
Condor Sandbox Team
The Technion DSL Lab, Israel
3.6.4 Sequence Diagram – Handling a file system access
request
High Level Design Document
13