Difference between revisions of "User:Waqas Khan"
Waqas Khan (talk | contribs) (→Project Name) |
Waqas Khan (talk | contribs) (→Project Details) |
||
| Line 17: | Line 17: | ||
== Project Details == | == Project Details == | ||
| + | Privileges mean what a user is permitted to do. Common privileges including viewing and editing files, or modifying system files. | ||
| + | My part of the project will involve doing privilege escalation do cause havoc in the system | ||
| + | Types of privilege escalation | ||
| + | |||
| + | Vertical privilege escalation, also known as privilege elevation, where a lower privilege user or application accesses functions or content reserved for higher privilege users or applications | ||
| + | |||
| + | Horizontal privilege escalation, where a normal user accesses functions or content reserved for other normal users Mitigation strategies | ||
| + | |||
| + | Operating systems and users can use the following strategies to reduce the risk of privilege escalation: | ||
| + | |||
| + | Data Execution Prevention | ||
| + | Address space layout randomization (to make it harder for buffer overruns to execute privileged instructions at known addresses in memory) | ||
| + | Running applications with least privilege (for example by running Internet Explorer with the Administrator SID disabled in the process token) in order to reduce the ability of buffer overrun exploits to abuse the privileges of an elevated user. | ||
| + | Requiring kernel mode code to be digitally signed. | ||
| + | Use of up-to-date antivirus software | ||
| + | Patching | ||
| + | Use of compilers that trap buffer overruns[9] | ||
| + | Encryption of software and/or firmware components. | ||
| + | |||
| + | If the code in a package runs entirely with privileges equal to or lower than a standard user account, or has no facility for user interaction, this policy is unlikely to apply to it. In practice, packages which provide one or more of: | ||
| + | setuid binaries | ||
| + | PolicyKit policies | ||
| + | consolehelper configurations | ||
| + | udev rules | ||
| + | D-Bus services on the system bus | ||
== Project Plan == | == Project Plan == | ||
Revision as of 17:02, 12 November 2012
= Mock chroot-break/Privilege Escalation Risk Assessment =
Contents
Project Description
Mock creates chroots and builds packages in them. Its only task is to reliably populate a chroot and attempt to build a package in that chroot. This project involves investigating this risk, developing a proof-of-concept, and recommending changes to the mock/koji system to mitigate this risk.
Project Leader(s)
Waqas Khan
Project Contributor(s)
Project Details
Privileges mean what a user is permitted to do. Common privileges including viewing and editing files, or modifying system files.
My part of the project will involve doing privilege escalation do cause havoc in the system
Types of privilege escalation
Vertical privilege escalation, also known as privilege elevation, where a lower privilege user or application accesses functions or content reserved for higher privilege users or applications
Horizontal privilege escalation, where a normal user accesses functions or content reserved for other normal users Mitigation strategies
Operating systems and users can use the following strategies to reduce the risk of privilege escalation:
Data Execution Prevention Address space layout randomization (to make it harder for buffer overruns to execute privileged instructions at known addresses in memory) Running applications with least privilege (for example by running Internet Explorer with the Administrator SID disabled in the process token) in order to reduce the ability of buffer overrun exploits to abuse the privileges of an elevated user. Requiring kernel mode code to be digitally signed. Use of up-to-date antivirus software Patching Use of compilers that trap buffer overruns[9] Encryption of software and/or firmware components.
If the code in a package runs entirely with privileges equal to or lower than a standard user account, or has no facility for user interaction, this policy is unlikely to apply to it. In practice, packages which provide one or more of: setuid binaries PolicyKit policies consolehelper configurations udev rules D-Bus services on the system bus
Project Plan
Tracking mechanism (bugzilla, trac, github, ...):
Key contacts:
Goals for each release and plans for reaching those goals:
- 0.1
- 0.2
- 0.3
Communication
=== Mailing List
