DevelopingDeployingSecurely

Session Title: Developing and Deploying Securely

Problem Statement: Teach some of the fundamental security mechanisms that differentiate OpenSolaris from the competition.
Audience: Application Developers and System Administrators
Author: Christoph Schuba

Key Messages

Explain problem space and key OpenSolaris security technologies that solve them

Solaris privileges and RBAC
Solaris crypto and key management framework

Present a few current, ongoing, opensource projects that are part of OpenSolaris to engage students and folks looking for research and development opportunities

FMAC, FGAP, Crypto ZFS, Validated Execution

Abstract

OpenSolaris contains a number of security features available to developers and system integraters that truly distinguish it from other operating systems. This talk contains two parts. The main part presents two or three important problem areas and teaches how the OpenSolaris features solve these problems. We give two examples in the following paragraphs below. The second, much shorter part, presents current, ongoing opensource OpenSolaris security projects to attract new community members and to capture the imagination of students looking for research and development opportunities in the field of computer and network security. While the contents of this second part are expected to change over time, current projects to highlight would be, e.g, FMAC (Flexible Mandatory Access Control in the context of Solaris Trusted Extensions), FGAP (Fine-Grained Access Policy), Crypto ZFS, and Validated Execution.

OpenSolaris provides two alternatives to the traditional, all-or-nothing superuser-based UNIX authorization model: privileges and RBAC (Role-based Access Control.) With the former, OpenSolaris separates traditional superuser powers across a number of individual privileges for fine-grained control over the actions of processes. This technology is used to implement software according to the principle of least privilege, enabling applications to be protected from each other and to provide software fault isolation. RBAC is a mechanism designed to selectively grant privileges to users or roles based upon their unique needs and requirements. This talk presents how to write/modify, debug, configure, and deploy privilege-aware and RBAC-aware applications and server software.

Secondly, the Solaris cryptographic and key management frameworks transparently make software and hardware crypto providers available to application programs and kernel software alike. Cryptographic protections and certificate management are integral parts to writing applications that need to communicate securely, a very common use case. This talk will explain the capabilities of these frameworks. It presents just how simple it is to transparently take advantage of hardware-based crypto acceleration (e.g., from the Niagara T2 chip sets) even from Java applications that utilize the Java Cryptographic Extensions.

Slides

Presentation Slides (need to update to external links)

Version 1.0.2 - ready to go!

PDF Version : use this if you are not certain if your system has the right fonts!
ODP Version : includes speaker notes!

Demo

Demonstrate how to use the listed technologies

High-Level Talk Outline

Part	Topic	Minutes	Demo
Intro	Title and talk overview	2 (total)
Part I	Least privileges and RBAC	18 (total)	multiple
Part II	Cryptographic and Key Management Frameworks	10 (total)	multiple
Part III	OpenSolaris Security Projects	8 (total)	multiple
Closing	Resources and Pointers	3 (total)

Detailed Talk Outline

Part	Topic	Minutes	Demo
Intro	Title and Outline	2 (total)
	Title	1
	Outline	1
Part I	Least privileges and RBAC	18 (total)
	Motivation for technology, problem space, use case
	Solaris privileges - A discrete right that can be granted to a command, a user, a role, or a system. - Privileges enable a process to succeed - For example, PRIV_PROC_EXEC allows a process to call execve().		$ ppriv -l file_link_any Allows a process to create hardlinks to files owned by a uid different from the process' effective uid. proc_exec Allows a process to call execve(). proc_fork Allows a process to call fork1()/forkall()/vfork() proc_info Allows a process to examine the status of processes other than those it can send signals to. Processes which cannot be examined cannot be seen in /proc and appear not to exist. proc_session Allows a process to send signals or trace processes outside its session.
	- Give overview of idea: - split root into many dozens of privileges - split basic into five privileges - PA vs NPA - 4 different sets and their relationship: limit, permitted, effective, inheritable - (Theory behind it: do not present here: see URL in the back!)
	Backwards compatibility: basic, all		DEMO: ppriv on NPA non-root process [global 1]: $ cat [global 0]: # pgrep cat 1941 [global 0]: # ppriv -S 1941 1941: cat flags = <none> E: basic I: basic P: basic L: all [global 1]: $ cat^D
			DEMO: ppriv on NPA setuid process [global 1]: $ /usr/sbin/ping doesntexist [global 0]: # pgrep ping 1945 [global 0]: # ppriv -S 1945 1945: /usr/sbin/ping doesntexist flags = PRIV_AWARE E: basic I: basic P: basic,net_icmpaccess L: none [global 1]: $ /usr/sbin/ping doesntexist^C [XXX WATCH OUT - net_icmpaccess does not show in OS 2008.05!]
	Privilege bracketing Privilege relinquishing		DEMO: show available privileges - documentation man page and header file
			DEMO: Take the source code for ping and show - how to make program privilege aware - how to specify which privleges are needed - how to relinquish privileges - how to bracket privileges
	Privilege debugging		DEMO: show how to debug privilege use/lack of a process [global 1]: $ ppriv -e -D cat /etc/shadow cat[1185]: missing privilege "file_dac_read_ (eudi = 501, \ syscall = 225) needed at ufs_iaccess+0xd2 cannot open /etc/shadow [global 0]: tail /var/adm/messages [ID 702911 kern.notice] cat[1185]: missing privilege \ "file_dac_read_ (eudi = 501, syscall = 225) needed at \ ufs_iaccess+0xd2
			DEMO: Using DTrace for Privilege Debugging [global 0]: dtrace -l \| grep priv-
			DEMO: Using privdebug.pl
	Solaris RBAC Goal: assign privileged functions to specific user accounts Top down explain relationship between these elements: "authorizations", "rights profiles", "role designations" using figure "rbac-er-diagram.png".
	Authorization: - unique string that represents a user's right to perform some operation or class of operations. - defined in /etc/security/auth_attr database - check authorization using chkauthattr(3SECDB):.		DEMO: authorization definition: [global 0]: $ cat /etc/security/auth_attr solaris.:::All Solaris Authorizations::help=AllSolAuthsHeader.html [..] solaris.grant:::Grant All Solaris Authorizations::help=PriAdmin.html [..] solaris.system.:::Machine Administration::help=SysHeader.html solaris.system.date:::Set Date & Time::help=SysDate.html solaris.system.shutdown:::Shutdown the System::help=SysShutdown.html
			DEMO: Mapping of authorizations to users: DEMO policy_conf(4) [global 0]: # more /etc/security/policy.conf [..] AUTHS_GRANTED=solaris.device.cdrw PROFS_GRANTED=Basic Solaris User [..] DEMO user_attr(4) [global 0]: # more /etc/user_attr [..] root::::type=role;auths=solaris.*,solaris.grant;profiles=All;\\\\\\\\\\\\\ lock_after_retries=no;min_label=admin_low;clearance=admin_high jdoe::::profiles=Primary Administrator;roles=root [..]
	Rights Profiles: a mechanism used to bundle together the commands and authorizations needed to perform a specific function.		DEMO: Mapping of profiles to users: DEMO policy_conf(4) [global 0]: # more /etc/security/policy.conf [..] AUTHS_GRANTED=solaris.device.cdrw PROFS_GRANTED=Basic Solaris User [..] DEMO user_attr(4) [global 0]: # more /etc/user_attr [..] root::::type=role;auths=solaris.,solaris.grant;profiles=All;\ lock_after_retries=no;min_label=admin_low;\ clearance=admin_high jdoe::::profiles=Primary Administrator;roles=root [..] DEMO prof_attr(4) [global 0]: # more /etc/security/prof_attr [..] Primary Administrator:::Can perform all administrative tasks:\ auths=solaris.,solaris.grant;help=RtPriAdmin.html [..]
	Users and Roles: - roles are based on rights profiles (roleadd(1M)) - roles are assigned to users who are trusted to perform the tasks of the role (usermod -r) - users log in with their user name - users assume roles that can run restricted commands (su) OR - user uses pfexec		DEMO: removing/adding "Primary Administrator" profile [global 1]: $ whoami jdoe [global 1]: $ profiles Primary Administrator Console User Basic Solaris User All [global 1]: $ auths solaris.* [global 1]: $ grep jdoe /etc/user_attr jdoe::::type=normal;profiles=Primary Administrator;roles=root [global 1]: $ pfexec usermod -P "" jdoe UX: usermod: jdoe is currently logged in, some changes may not take effect until next login. [global 1]: $ grep jdoe /etc/user_attr jdoe::::type=normal;roles=root [global 1]: $ auths solaris.device.cdrw,solaris.profmgr.read,solaris.jobs.user,\ solaris.mail.mailq,solaris.device.mount.removable,\ solaris.admin.usermgr.read,solaris.admin.logsvc.read,\ solaris.admin.fsmgr.read,solaris.admin.serialmgr.read,\ solaris.admin.diskmgr.read,solaris.admin.procmgr.user,\ solaris.compsys.read,solaris.admin.printer.read,\ solaris.admin.prodreg.read,solaris.admin.dcmgr.read,\ solaris.snmp.read,solaris.project.read,solaris.admin.patchmgr.read,\ solaris.network.hosts.read,solaris.admin.volmgr.read [global 1]: $ pfexec usermod -P "Primary Administrator" jdoe UX: usermod: ERROR: Permission denied. [global 1]: $ auths\|grep grant [global 1]: $ su root Password: [global 1]: # whoami root [global 1]: # usermod -P "Primary Administrator" jdoe UX: usermod: jdoe is currently logged in, some changes may not take effect until next login. [global 1]: # exit exit [global 1]: $ grep jdoe /etc/user_attr jdoe::::type=normal;profiles=Primary Administrator;roles=root [global 0]: # auths solaris.*
	Programmatic RBAC check: Synopsis: chkauthattr(3SECDB) int chkauthattr(const char authname, const char username); The chkauthattr() function checks the policy.conf(4), user_attr(4), and prof_attr(4) databases in order for a match to the given authorization.		Example 1: Standard root check ruid = getuid(); if ((eflag \|\| lflag \|\| rflag) && argc == 1) { if ((pwp = getpwnam(argv)) == NULL) crabort(INVALIDUSER); if (ruid != 0) { if (pwp->pw_uid != ruid) crabort(NOTROOT); else pp = getuser(ruid); } else pp = argv++; } else {
			Example 2: Authorization check ruid = getuid(); if ((pwp = getpwuid(ruid)) == NULL) crabort(INVALIDUSER); strcpy(real_login, pwp->pw_name); if ((eflag \|\| lflag \|\| rflag) && argc == 1) { if ((pwp = getpwnam(argv)) == NULL) crabort(INVALIDUSER); if (!chkauthattr("solaris.jobs.admin", real_login)) { if (pwp->pw_uid != ruid) crabort(NOTROOT); else pp = getuser(ruid); } else pp = argv++; } else {
	Privileges and RBAC are complimentary - Rights profiles, privileges, and authorizations can be assigned directly to users - Privileges and authorizations can be assigned directly to roles

Part II	Cryptographic and Key Management Frameworks	10 (total)
	Motivation for technology, problem space, use case
	- Crypto used in lots of places: Userland: SSL, SSH, GSS, Kerberos, md5, PAM, ... Kernel: IPsec, WiFi drivers, ... - Problems with duplicate implementations/libraries OpenSSL, Mozilla NSS,... - Versioning/bug problems - Administrative challenge to utilize hardware acceleration - Need to take advantge of standard APIs - Need for plugable interface
	Solaris Cryptographic Frameworks - Introduced in Solaris 10 - New features added on ongoing basis (e.g., niagara 2 crypto provider, ECC algorithms and modes) - User-level and kernel-level interfaces - Administrative commands to control the framework - Consumer-producer architecture - Show and explain CF architecture figure - Benefits: no duplicate implementations, optimization for hardware, transparent use of hardware accelerators		DEMO: [global 0]: $ cryptoadm list User-level providers: Provider: /usr/lib/security/$ISA/pkcs11_kernel.so Provider: /usr/lib/security/$ISA/pkcs11_softtoken.so Kernel software providers: des aes arcfour blowfish ecc sha1 sha2 md4 md5 rsa swrand Kernel hardware providers:
	Terminology: - PKCS#11 Standardd API frpm RSA Labs - Consumers: application, library, or kernel using cryptographic functions E.g., uCF: digest, mac, encrypt, decrypt, pktool, ... E.g., kCF: IPsec, WiFi drivers, ZFS crypto, lofi crypto, ... - Producers: library, kernel, or hardware offering implementation of cryptographic functions - Plug-in: aka producer - Mechanism: algorithm (and mode) and security goal E.g., DES used for authenication -> determines features and required arguments - Token: implementation of a mechanism can be stateful hardware or software - Slot: collection of tokens - Metaslot: virtual (defualt) slot as superset of all slots selects best implementation - Session: active connection between consumer and token - Objects: store information (e.g., keys) session objects vs. token objects (persistent across sessions)
	uCF - User-Level Crypto Framework - libpkcs11.so is your friend! - API version 2.20 - Convenience functions. E.g., - SUNW_C_GetMechSession - SUNW_C_KeyToObject - Engine for OpenSSL library - Digest library (libmd.so) - Private libraries (libelfsign.so and libcryptoutil.so)		DEMO software token provider: [global 0]: $ man pkcs11_softtoken [XXX view output - not repeated here XXX]
	Administration via cryptoadm(1M) - Provider verification via elfsign(1) - Runtime verification by kcfd(1M) (FMRI: svc:/system/cryptosvc:default)
	kCF - Kernel-Level Crypto Framework - Similar programming logic to PKCS#11 - Kernel-Level Software providers: loadable kernel modules - kernel software providers are synchronous - kernel hardware providers: device nodes, drivers, usually asynchronous, framework handles scheduling, callbacks, state, etc.		DEMO: example kernel software provider [global 0]: $ modinfo \| grep -i swrand 80 f91fe000 1914 - 1 swrand (Kernel Random number Provider) [global 0]: $ cryptoadm list -mv [XXX output too long for here... XXX]
	Example code flows for md5 usage		MD5 Code Flow PKCS#11 only [XXX see preso/paper from Wolfgang XXX]
			MD5 Code Flow OKCS#11/Sun [XXX see preso/paper from Wolfgang XXX]
			MD5 Code Flow libmd [XXX see preso/paper from Wolfgang XXX]

Part III	OpenSolaris Security Projects	8 (total)
	Flexible Mandatory Access Control (FMAC)	2
	Crypto ZFS	2
	Validated Execution	2
	Datatethers	2

Closing	Resources and Pointers	2 (total)
	Possibly mention other interesting Solaris Security technologies	1
	Resources	1