Fighting Spyware With Mandatory Access Control In Microsoft Windows Vista (Diploma Thesis Colloquium)

What Am I Going to Demonstrate? Mandatory access control (MAC) can be used to efficaciously and efficiently fight spyware in Microsoft Windows Vista because Even though application compatibility and user experience are affected Spyware depends on the ability to read in order to collect (sensitive) data The architecture that enables this (Microsoft Windows Integrity Mechanism [WIM]) is already implemented in this OS (Microsoft Windows Vista)

Scope and Definitions Spyware = software that collects sensitive information without appropriate user consent Effective = doing “right” things (i.e. setting right targets to achieve an overall goal [the effect]) Efficacious = getting things done (i.e. meeting targets) Efficient = doing things in the most economical way (good input to output ratio)

How Am I Going to Demonstrate? Introducing WIM and explaining how it works Demonstrating how WIM can be tweaked in order to enable my concept , and showing the result with an explicit example scenario

1. WIM C ore component of Microsoft Windows security architecture Restricts access permissions of less trustworthy applications running under same user account

1. WIM (cont.) Extends security architecture of OS by assigning integrity level (IL) to application processes and securable objects

1. WIM (cont.) IL = representation of trustworthiness of running application processes and objects Provides ability for resource managers to use pre-defined policies that block processes of lower integrity from reading, modifying, or executing objects of higher integrity Allows Microsoft Windows security model to enforce access control restrictions that cannot be defined by granting user or group permissions in access control lists (ACLs)

1. WIM (cont.) Microsoft Windows security architecture: Based on granting access rights and privileges to users or groups represented internally by security identifiers (SIDs) User logs on > Security Reference Monitor (SRM) sets user’s SID and group membership SIDs in security access token Security access token is assigned to every application process run by that user Application process opens object: Resource manager that manages object calls on SRM to make access decision SRM compares user and group SIDs in access token with access rights in security descriptor associated with object If user SID is granted full access rights in object’s ACL > application process user runs has full access to object

1.1. Extending Microsoft Windows Security Architecture WIM extends security architecture by defining new Access Control Entry (ACE) type to represent IL in object’s security descriptor (object IL) IL is also assigned to security access token when access token is initialized (subject IL) IL in access token is compared against IL in security descriptor when SRM performs access check Microsoft Windows Vista uses AccessCheck function to determine what access rights are allowed to securable objects Microsoft Windows restricts allowed access rights depending on: whether subject’s IL is higher or lower than object integrity policy flags in new access control ACE SRM implements IL as mandatory label to distinguish it from discretionary access under user control that ACLs provide

1.2. Features ILs assigned automatically to every security access token during access token creation = every process and thread has effective IL for access control SRM automatically assigns mandatory labels to specific object types There are controls on how object creator can set or initialize label on object creation

1.3. Purpose Restrict access permissions of less trustworthy applications running under same user account Microsoft Windows SRM assigns simple hierarchy of ILs to code running at different privilege levels for same user Microsoft Windows Vista incorporates concept of least privilege by enabling broader use of standard user accounts User Account Control (UAC) in Admin Approval Mode for administrator accounts = multiple applications on the same desktop running with different privilege levels

1.3. Purpose (cont.) Security problems addressed by WIM Primary : unauthorized tampering with user data and system state Secondary : information disclosure Prevented only with respect to access to process address space

1.3. Purpose (cont.) WIM does not provide a complete isolation barrier WIM is not an application sandbox

1.4. Earlier Integrity Models Biba Model Based on hierarchy of integrity labels and access policies allowed when subject IL dominates object IL WIM resembles Biba Model in following ways: uses hierarchy of integrity labels system uses set of ordered subjects, objects, and ILs subject’s IL dominates object’s IL integrity policies inhibit access to objects but are not used primarily to limit flow of information preventing information disclosure is not main goal

1.4. Earlier Integrity Models (cont.) WIM: Lower value indicates less trustworthiness; higher value indicates greater trustworthiness Lower-level subject cannot modify higher-level object Subject’s IL is not dynamic Policies do not inhibit or prevent higher-integrity subjects from reading or executing lower-integrity objects Does not inhibit or prevent reading data at any level Does not enforce strict integrity policy as described in Biba Model Assumes that processes designed to handle untrusted data from unknown or untrusted sources are running at lower IL, or that untrusted data is verified before use

1.4. Earlier Integrity Models (cont.) Conclusion WIM: Similar to earlier integrity models in computer security but Does not implement any model (at least not literally) instead Limits access permissions available to processes running with different privilege or trust levels

1.5. Security descriptor fields

1.6. Mandatory Label ACE ACE HEADER AceType: SYSTEM_MANDATORY_LABEL_ACE_TYPE AceFlags: ACE type inheritance flags Container Inherit (CI): subordinate folders inherit ACE Object Inherit (OI): subordinate files inherit ACE Inherit Only (IO): ACE does not apply to current object AceSize: size of mandatory label ACE ACE MASK : mandatory label policy flags NO_WRITE_UP: default policy NO_READ_UP: used only to restrict access to virtual memory NO_EXECUTE_UP: used to restrict launch activation perm. ACE SID IL Trusted Installer: highest possbible level of trust, able to modify OS System: generally services or objects part of the OS itself (e.g. LocalSystem) High: administrators Medium: default trust level for non-administrative users and associated data Low: “Everyone” account, PMIE, temporary Internet files Untrusted: anonymous or “Guest” accounts

WIM -> Concept I explained What WIM is and how it works I will now explain/demonstrate How WIM can be tweaked in order to enable my concept The effect of the implementation of my concept in an explicit example scenario

2. My Concept Major parts: Explicit mandatory label assigned to objects created by Web browsers and e-mail clients (when necessary) Configuration tweaking of integrity policies that restrict access permissions IL assigned to Web browsers and e-mail clients

2.1. Explicit Mandatory Label What? Assign explicit low mandatory label to objects created by Web browsers and e-mail clients When? Always (or when necessary) Why? Some operations might be handled by processes running at IL higher than low How? Create object with specific low mandatory label: Process creates SDDL security descriptor that defines low IL (e.g. #define LOW_INTEGRITY_SDDL_SACL_W_L”S:(ML;;NW;;;LW)” Process converts SDDL string to security descriptor using ConvertStringSecurityDescriptorToSecurityDescriptor Process assigns security descriptor with low IL to security attributes structure Process passes security attributes parameter to call to create object, such as CreateFile What for? Prevent process from reading user data files

2.2. Integrity Policy What? Enable NO_READ_UP mandatory label policy, and CI and OI inheritance Where? User profile ( C:\Users\<username> ) When? User profile initialization Why? Most common place to store personal files (sensitive data) How? Editing user profile folder ACE: ACE HEADER > AceFlags field: CI = 1, OI = 1 ACE MASK: SYSTEM_MANDATORY_POLICY_NO_READ_UP = 1 What for? Restrict read access to user profile by subjects with lower IL (Web browsers, e-mail clients, and related subjects)

2.3. Integrity Level What? Run Web browsers and e-mail clients with low IL When? Always Why? They handle untrustworthy input How? Designing them to run with low rights (least-privilege functionality) What for? To reduce access rights available to processes, in order to limit ability of exploit running in them to read user data files

2.4. Example Scenario Microsoft Windows Vista user receives attachment in e-mail -> saves it -> executes it Currently: attachment’s process is able to read and modify user’s data After 1: attachment’s process is unable to modify user’s data, but is still able to read it After 2: attachment’s process is unable to read or modify user’s data After 3? Eventual exploit running in Web browser or e-mail client is (also) unable to read (concept) or modify (WIM) user’s data

2.5. Concept Applicability Advantages of a MAC solution like this: Transparent to user Active protection Easily implementable in Microsoft Windows Vista Fights spyware in effective and efficient manner Why better than WIM or other Microsoft Windows Vista built-in feature(s)? Prevents information disclosure with respect to areas other than virtual memory address space of processes (such as: user profile )

What Did I Talk About? I introduced and explained what WIM is I demonstrated how WIM can be tweaked in order to enable my concept, and showed the result with an explicit example scenario

Conclusion It is possible to use MAC to efficaciously and efficiently fight spyware in Windows Vista because Even though application compatibility and user experience is affected, e.g. Uploading pictures to Web sites Copy and paste Spyware depends on ability to read in order to collect (sensitive) data Architecture that enables this (WIM) is already implemented in OS (Microsoft Windows Vista)

Conclusion (cont.) Although not Effective (denies all read access attempts, even if they are legitimate) this concept is Efficacious (disables all spyware, even if unknown and/or undiscovered) and Efficient (uses few resources, since it uses no real-time scanning)

Outlook Possible further improvement: Use UAC to intercept denied read access attempts and prompt user to make true final decision on whether these read accesses can take place

Thank you Diploma Thesis Colloquium Filipe Governa Hochschule für Angewandte Wissenschaften Hamburg (HAW Hamburg) / Hamburg University of Applied Sciences Hamburg (GERMANY), 17 July 2008

Fighting Spyware With Mandatory Access Control In Microsoft Windows Vista (Diploma Thesis Colloquium)

More Related Content

What's hot (20)

Viewers also liked (8)

Similar to Fighting Spyware With Mandatory Access Control In Microsoft Windows Vista (Diploma Thesis Colloquium) (20)

Recently uploaded (20)

Fighting Spyware With Mandatory Access Control In Microsoft Windows Vista (Diploma Thesis Colloquium)