1
edit
Changes
Created page with '== 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 pr…'
== 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 ==
a privilege escalation exploit could be used to cause the system to break. My plan is to find out why and how this is done. and then find a way to make changed to mock/koji.
Key contacts:
<!-- Add links to any mentors or key participants in the community. -->
Goals for each release and plans for reaching those goals:
<!-- Note: each contributor is expected to have unique goals. These goals may be ''related'' to other students' work, but must be ''distinct'' and ''attainable'' regardless of the state of the other students' work. For example, under the umbrella of one project title, one student may work on packaging a piece of software and another may work on documentation, or one may work on solving one bug and another on solving another bug, but two students must not work on the same bug or depend on the other students' work in order to be able to complete their own project. -->
* 0.1
* 0.2
* 0.3
== Communication ==
=== Mailing List
=== Upsteam Wiki and Web ===
=== Links/Bugs/Tracking ===
=== Source Code Control ===
=== Blogs ===
==== Seneca Particpants ====
==== Non-Seneca Participants ====
==== Planets ====
== Project News ==
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 ==
a privilege escalation exploit could be used to cause the system to break. My plan is to find out why and how this is done. and then find a way to make changed to mock/koji.
Key contacts:
<!-- Add links to any mentors or key participants in the community. -->
Goals for each release and plans for reaching those goals:
<!-- Note: each contributor is expected to have unique goals. These goals may be ''related'' to other students' work, but must be ''distinct'' and ''attainable'' regardless of the state of the other students' work. For example, under the umbrella of one project title, one student may work on packaging a piece of software and another may work on documentation, or one may work on solving one bug and another on solving another bug, but two students must not work on the same bug or depend on the other students' work in order to be able to complete their own project. -->
* 0.1
* 0.2
* 0.3
== Communication ==
=== Mailing List
=== Upsteam Wiki and Web ===
=== Links/Bugs/Tracking ===
=== Source Code Control ===
=== Blogs ===
==== Seneca Particpants ====
==== Non-Seneca Participants ====
==== Planets ====
== Project News ==
