From sac-owner Wed Apr 3 11:19:13 2002 Received: from sunmail2.Sun.COM (sunmail2.EBay.Sun.COM [129.150.166.10]) by sac.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id g33JJDR15824 for ; Wed, 3 Apr 2002 11:19:13 -0800 (PST) Received: (from noaccess@localhost) by sunmail2.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1-Sun.COM.mod.2) id LAA11263 for one-pager-not-2b-used-directly; Wed, 3 Apr 2002 11:17:39 -0800 (PST) Received: from romulus.Holland.Sun.COM (romulus.Holland.Sun.COM [129.159.201.5]) by sunmail2.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1-Sun.COM.mod.2) with ESMTP id LAA11203; Wed, 3 Apr 2002 11:17:34 -0800 (PST) Received: from holland (room101 [129.159.201.52]) by romulus.Holland.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.2) with ESMTP id VAA06348; Wed, 3 Apr 2002 21:17:10 +0200 (MEST) Message-Id: <200204031917.VAA06348@romulus.Holland.Sun.COM> To: one-pager@sun.com Subject: Least Privilege for Solaris Cc: least-priv@sun.com Date: Wed, 03 Apr 2002 21:17:10 +0200 From: Casper Dik Status: RO Content-Length: 7077 Template Version: @(#)onepager.txt 1.19 02/02/28 SMI Copyright 2002 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: Least Privilege for Solaris 1.2. Name of Document Author/Supplier: Casper Dik 1.3. Date of This Document: 04/04/02 1.4. Name of Major Document Customer(s)/Consumer(s): 1.4.1. The Steering Committees you expect to review your project SOESC, ONSC 1.4.2. The ARC(s) you expect to review your project PSARC 1.4.3. The Director/VP who is "Sponsoring" this project Sin-Yaw Wang 1.4.4. The name of your business unit SSTG 1.5. Email Aliases: 1.5.1. Responsible Manager: Scott.Rotondo@Sun.COM 1.5.2. Responsible Engineer: Casper.Dik@Sun.COM 1.5.3. Marketing Manager: Ravi.Iyer@Sun.COM 1.5.4. Interest List: least-priv@sun.com 2. Project Summary 2.1. Project Description This project provides a means for separating the powers of the all powerful uid 0 into several different privileges allowing processes with a non-0 effective uid to still have some of the powers that originally were root's prerogative as well as having uid 0 process that have less power than currently. 2.2. Risks and Assumptions It is assumed that the traditional super-user model of operation will be considered to be too risky to be used even in general purpose operating systems. 3. Business Summary 3.1. Problem Area This project provides the ability to give some of the super user's capability to individual processes without requiring them to run with full root privileges. This project provides the ability to restrict processes with uid 0 to only some of the privileges previously always associated with uid 0. This project provides the ability to limit a process and its offspring to a maximum set of privileges. 3.2. Market/Requester By allowing daemon processes to run with less than the full set of root privileges, this project reduces the vulnerability of Solaris systems to some security attacks. Trusted Solaris will use this project's privilege implementation for future releases. The Kevlar project can leverage Least Privilege but it can be implemented independently. 3.3. Business Justification The lack of features in this space is likely to be a competitive disadvantage. 3.4. Competitive Analysis Most operating systems have similar features, we're playing catch-up. (VMS, Microsoft Windows NT/2000/XP, IRIX. The Free operating systems (Linux, *BSD) all have distributions that have similar features. By offering an incremental change to Solaris, adoption will be completely painless for Solaris customers; the same cannot be said for other Unix offerings. 3.5. Opportunity Window/Exposure The competition is already offering products in this area, so we're behind. We need this functionality in the base OS to stay competitive. 3.6. How will you know when you are done? The design and specification documentation is nearly finished at this time. When the proposed functionality is completely implemented the relevant standard tests must succeed. The project must also meet Solaris quality standards at time of integration. 4. Technical Description The principle of Least Privilege is well established in secure operating systems research. Trusted Solaris has already shipped with similar technology. The project will deliver the kernel framework for maintaining and propagating privileges throughout the kernel. Those sections of the Solaris kernel where privilege checks are performed (suser(), drv_priv(), cr_uid == 0) are changed and new checks, against the effective privilege set, are performed instead. The implementation is loosely modeled on the Trusted Solaris design, with adaptations to cater for the special needs of standard Solaris and to make the design future proof. The project adds a number of privilege sets to the Solaris kernel credential structure. As we see the use of privileges evolve, our design hides the size of the privilege sets, the number of privilege sets, the number of privileges as well as the numeric value of the privileges from userland processes and ddi compliant kernel modules. Process privileges get their on entry under /proc/, as the /proc//cred format doesn't allow for extensions. New commands are created to inspect and change process privileges; the user_attr database is changed to allow users to log in with certain privileges and assume them through su(1); the exec_attr database is extended to allow privileges to be associated with executables in profiles. Some new privileges are defined for operations that are currently unprivileged. This allows for a more restricted type of user. All the kernels security policy decisions based on checks against uid 0 will be changed to checks against the relevant privileges. Compatibility is maintained by awarding effective uid 0 processes all privileges except when a process or one of its ancestors changes it to be "privilege aware". Processes without an effective uid of 0 will always honor their possibly non-empty effective privilege set. There is no global setting to enable or disable this feature; we believe that such is setting is both unnecessary because of the achieved compatibility and counter productive as it wouldn't allow us to make use of privileges as part of the standard OS and make ISV/customer acceptance harder. Alternative implementation (Linux "inspired on defunct POSIX draft standard capabilities", Trusted Solaris "Privilege sets") use fixed size bit sets and user visible manifest constants when manipulating privileges. Past experience has shown that for any number N, and for almost any object O, the statement "we'll never need more than N of O" is invariably untrue. 5. Reference Documents Trusted Solaris documentation on privileges. http://docs.sun.com:80/ab2/coll.175.4/TRSOLDEV/@Ab2PageView/3103 Kevlar documentation http://kevlar.eng/ 6. Resources and Schedule 6.1. Projected Availability Q2C2003 6.2. Cost of Effort 60 staff months 6.3. Cost of Capital Resources Existing equipment can be used. 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: OS/Networking 6.4.2. Contributing OpCo/BU/Division Name: Software Systems Group 6.4.3. Type of SC Approval needed: Standard 6.4.4. Project Boundary Conditions: 6.4.5. Is this a necessary project for OEM agreements: N 6.4.6. Notes/Dependencies: None currently. 6.4.7. Target RTI Date/Release: Solaris 10 6.4.8. Target Code Design Review Date Two or three design reviews have been held. Initial code review planned for H2CY2002 6.4.9. Did this project have prior SOESC approval for a Marketing Release and now your requesting to go into an Update Release or Early Access CD? No. 6.5. ARC review type: Standard 7. Prototype Availability 7.1. Prototype Availability Now. 7.2. Prototype Cost 15 staff months.