IAM ====== Name: Validated Execution Submitter: john.zolnowsky@sun.com Owner: Gary Winiger Intern: Darren Reed Interest: valex-discuss@opensolaris.org Status: inception scheduled 04/09/2008 Exposure: open Comment: SUMMARY ======= This project will add the feature of validating signatures associated with objects (kernel modules, executables, libraries, and scripts) before allowing such objects to be executed. The administrative model will address what signatures to accept and what disposition is to be given to objects without associated signatures. The project will address infrastructure issues such as facilities and procedures to associate signatures with both OpenSolaris and independently developed objects. ISSUES ====== Issues for inception: Validated Execution (PSARC/2008/195) 9 Apr 2008 Submitter: John Zolnowsky Owner: Gary Winiger Intern: Darren Reed gw-0 Case boundaries relative to things like "cat foo | sh" i.e., the relationship with interpreters? ==> The ability to bypass this mechanism makes it possible to execute code without going through the validation mechanism. In our view that's ok. Our objective is to ensure that there is a way to execute code knowing it has not been tampered with, and to make sure that the normal ways to execute code do provide this assurance. This should answer the boundary question. djr-0 Further to gw-0, how does this project propose to handle "executable code" that we deliver as text that forms part of libraries for scripting languages, such as perl, ksh, etc. ==> The discussion on email has been how to do that. I understand the argument against modifying the interpreter. Still believe that modifying the interpreter is the best method that can be seen at this point. We want to make sure a privileged process doesn't undo the validation, which is the reason for having in the initial manifest be validated by TPM. We want to be sure that a malicious process with sufficient privilege can't simply clear the file attribute or other indicator that the code should be validated. Interpreters such as shells, perl, python, Ruby, JRuby should be modified to validate libraries ...but there is no definitive list yet. It doesn't include the things we don't ship. But, the weakness with the other approaches are greater. JVM should be included. Because Java is developed separately from Solaris, there are complications to how it may happen, but it makes sense. djm-0 Possible overlap with PSARC/2007/118 vscan Explain either: a) Why there is zero overlap despite both cases wanting to "validate" files before "use" ==> Vscan mechnaism is identifying toxic files. The designation is independent of content of file; There is no way of resolving that once the designation is made. A nondelegated file, however, can be delegated by putting a manifest in appropriate place; therefore the enforcing mechanism is cumbersome for doing the validation b/c you can no longer read the file. It is difficult to to come up with mechansim for priveleged context of envoking program can do the appropriate thing when file is not delegated. A nonvalidated file can be validated after putting a manifest in place. It is difficult ... The file system mechanism doesn't have full b) what parts of the vscan case will be used by this case eg the VFS layer hooks, ZFS state etc. ==> There was nothing useful from vscan case. gw-0a Would it help up front to have a walk through of the admin steps for: 1) adding a manifest, 2) adding a cert, 3) changes to an O_VALIDATE file, 4) update to the initial manifest (presuming it includes at least /etc/system which can change kernel memory and is changed by things like bsmconv)? Would Bob Hagmann be proud of this issue? If not, do this as a > 0 issue. ==> It is covered in the materials without specifying the specific admin commands, which is needed. 1-3) Need to elaborate the naming conventions within dir are. What matters is having a namespace withing dir. The validation daemon collects all manifests in the directory. For each manifest the daemon verifies its signature, loads hash values for everything in manifest. There can be multiple levels of certificates. There is no limit to that depth of that tree. We refer to the certificate at the root of each tree as a trust anchor. Adding a non-trust anchor certificate is the same as adding any other certifcate. The trust anchor certificates are special in that there is a file which lists the names. How does that differ from /etc/certs? You might want to trust only a subset of those as authorities that can find the manifest. It's simpler for the admin to specify one trust anchor than all the leaf nodes. **Name the file trust anchors. Another manifest entry that cover the new content of the file is needed ( replace existing or create new manifest and add to dir). Not necessary to revoke the old one. Use bart to generate the manifest and use something else to move the manifest to.. 4) Updating the hash ..required not privelege on Taking ownersip of TPM is something admin does. The admin command is responsible to prompting the user for passwd and storing with hash. **This needs to be in place for commitment. ram-1 Leveraging gw-0a, it was unclear to me how one would create, modify and validate an initial manifest? ==> see above. ram-2 Would it be better to move the /etc/signedexec directory to /etc/security/signedexec? ==> It may make more sense to move it to /etc/security. **Project team to look at this and consider moving to /etc/security. gw-1 20Q 3, Why does enabling validated execution by default need "wide adoption of manifests as part of software delivery"? Why isn't this case complete enough to turn validated execution on by default? What's missing? ==> In the absences of manifests for any SW, there are couple choices as the administrator depending on how you configure the privilege cap. Set the unvalidated privelege cap to basic, so that informally you are allowing validated programs to run with any privileges and unvalidated sw can are run without only basic privilege. For software without a manifest, the adminstrator can create one with the bart interfaces provided. In absences of manifest, the admin has a couple choices: be permissive and let run, don't let run or set unvalidated privelege to small set to allow validated sw to run with priveleges and unvalidated sw to run without priveleges. gww: This project could be helpful to meet the requirement for trusted recovery for the next system. djr-1 What steps are required for ISVs to deliver content covered by this case? ==> Already a mechanism in Solaris for key manangement framework to allow user certficate to find. Outline in design document. Refer to last section, bart command in document. gw-2 20Q 4, Case dependencies Are these all hard dependencies? (Need case number for libxmlsec for commitment) What changes to crypto framework are still needed? (What's the case number of the dependent parts? -- perhaps needed for patch binding Cteam verification) 20Q 11, XML-DSig case? 20Q 13, Are there no imported interfaces? Are there missing exported interfaces? EVALIDATE? 20Q 10, What's interesting to audit here? ==> TPM is a dependency for this project. TPM code will complete long before this gets added into Solaris11. Project team will bring TPM case to the ARC as a fast-track. (For those without TPM, must implicitly trust the initial manifest.) gw-3 Missing deliverables list: man page for signedexecadm List of files in initial manifest List of manifests delivered by this project and files within them. /etc/signedexec/disable taxonomy? Project Private ;-) ==> There is a strawman answer in the design doc, but it needs to be finalized and better defined. /etc/system was not in there, for example. gw-4 What is the name space under and how is it managed /etc/signedexec/{manifest,revocation,certlist} How do /etc/certs and /etc/signedexec/certlist differ? How are they administered? ==> Already discussed prior. gw-5 20Q 7, How does this project meet the SMF Policy? http://opensolaris.org/os/community/arc/policies/SMF-policy/ In particular with relationship to value and action authorizations, and method context? How does this project meet the Solaris Audit Policy? http://opensolaris.org/os/community/arc/policies/audit-policy/ In particular for administrative audit of things like /etc/signedexec/{manifest,revocation,certlist} and signedexecadm? ==> What user, what priveleges does it get launched from SMF with and how does principle of least privelege matter? ** Project team to look at this. gw-6 Spec 2.1 File Manifests Is there provision for attributes beyond owner, group, POSIX pbits? ACLs, Extended Attributes (attribute files?). What is the hash used for Solaris delivered manifests? ==> We only validate metadata that affects the execution context of the process. Today that means uid, gid, and permissions. The initial manifest could be extended to include future metadata attributes that affect execution, if any. gw: Would like to know the file hasn't given permissions to other files / extended attributes with integrity labels. We do that (verify any metadata) with bart. It's an RFE for extended attributes with Bart. **Project team to indicate hash algorithm. **Project team asked to include performance analysis on gw-7 Spec 2.2 step 2, presumably the manifest entry for the file has its signature validated so the hash for the file can be trusted. If not, why not? A spec update would help make this clearer. Is validation extensible to other attributes? For example extended attributes when they come into critical use. ==> Answered as part of gw-0a. gw-8 Spec 2.3 caching validation in particular invalidated are there parallels to vscan and quarantined? gw-9 Spec 3 how are additions/deletions to certlist managed (including audit)? ==> Talk extensively offline regarding this. gw-10 Spec 4 O_VERIFY errno, why not EVALIDATE? ==> Project team to fix. THE NEXT STEP =============