diff options
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/design | 16 | ||||
| -rw-r--r-- | docs/design-acl | 10 | ||||
| -rw-r--r-- | docs/design-api | 10 | ||||
| -rw-r--r-- | docs/netdb-role-api | 10 | ||||
| -rw-r--r-- | docs/notes | 22 | ||||
| -rw-r--r-- | docs/objects-and-schemes | 100 | ||||
| -rw-r--r-- | docs/setup | 12 | ||||
| -rw-r--r-- | docs/stanford-naming | 217 |
8 files changed, 331 insertions, 66 deletions
diff --git a/docs/design b/docs/design index f7faa55..8f4b20d 100644 --- a/docs/design +++ b/docs/design @@ -148,9 +148,9 @@ Server Design * Optional ACLs for get, store, show, destroy, and flag operations. If there is an ACL for get, store, or show, that overrides the - normal permissions of the owner. In the absence of an ACL for - destroy or flag, only wallet administrators can destroy an object or - set flags on that object. This entry would need no special ACLs. + normal permissions of the owner. In the absence of an ACL for flag, + only wallet administrators can set flags on that object. This entry + would need no special ACLs. * Trace fields storing the user, remote host, and timestamp for when this object was last created, stored, and downloaded. @@ -369,3 +369,13 @@ Security Considerations operations on an object to allow retrieval of the complete history of an object. Third, all wallet operations are logged to syslog and therefore suitable for archiving, analysis, and forensics. + +License + + Copyright 2007, 2008, 2013 + The Board of Trustees of the Leland Stanford Junior University + + Copying and distribution of this file, with or without modification, + are permitted in any medium without royalty provided the copyright + notice and this notice are preserved. This file is offered as-is, + without any warranty. diff --git a/docs/design-acl b/docs/design-acl index dde3395..424b3c6 100644 --- a/docs/design-acl +++ b/docs/design-acl @@ -79,3 +79,13 @@ ACL Schemes (Not yet implemented.) <identifier> is the name of an AFS PTS group. Access is granted if the principal of the user is a member of that AFS PTS group. + +License + + Copyright 2006, 2007, 2008, 2013 + The Board of Trustees of the Leland Stanford Junior University + + Copying and distribution of this file, with or without modification, + are permitted in any medium without royalty provided the copyright + notice and this notice are preserved. This file is offered as-is, + without any warranty. diff --git a/docs/design-api b/docs/design-api index 8fa2374..9a36e61 100644 --- a/docs/design-api +++ b/docs/design-api @@ -167,3 +167,13 @@ Registering New Implementations where <type> or <scheme> is the object type or ACL scheme and <class> is the Perl class which implements that object type or ACL verifier. + +License + + Copyright 2006, 2007, 2008, 2013 + The Board of Trustees of the Leland Stanford Junior University + + Copying and distribution of this file, with or without modification, + are permitted in any medium without royalty provided the copyright + notice and this notice are preserved. This file is offered as-is, + without any warranty. diff --git a/docs/netdb-role-api b/docs/netdb-role-api index 6dbcfa4..c90182a 100644 --- a/docs/netdb-role-api +++ b/docs/netdb-role-api @@ -30,3 +30,13 @@ Wallet Issues We'll need to get a principal registered to use it that can query anything for any node but isn't otherwise authorized to use NetDB. + +License + + Copyright 2006, 2007, 2013 + The Board of Trustees of the Leland Stanford Junior University + + Copying and distribution of this file, with or without modification, + are permitted in any medium without royalty provided the copyright + notice and this notice are preserved. This file is offered as-is, + without any warranty. @@ -46,7 +46,7 @@ Server Issues ACL Management - Supported operations are: get, store, create (possibly triggered by a + Supported operations are: get, store, create (possibly triggered by a get or store of something that didn't already exist), destroy, show, and setting or clearing flags. Each of these need a separate ACL potentially. Not sure if we're going to need separate ACLs for each @@ -62,10 +62,9 @@ Server Issues that returns a default ACL given the object type and name if the object doesn't already exist. - Owner rights provides get, store, and show, but not destroy or setting - or clearing flags (not destroy because it's too destructive and we - don't want it done accidentally). This can be overridden by more - precise ACL settings. So the ACL logic would go like this: + Owner rights provides get, store, show, and destroy, but not setting + or clearing flags. This can be overridden by more precise ACL + settings. So the ACL logic would go like this: * If the user is an administrator and the operation isn't get or store, operation is permitted. @@ -74,7 +73,8 @@ Server Issues that specific ACL, apply that ACL. * If the object exists but with no specific ACL setting and the - operation is one of get, store, or show, apply the owner ACL. + operation is one of get, store, show, or destroy, apply the owner + ACL. * If the object doesn't exist and the action is get, store, or create, punt to a local policy if it exists and see if it returns a @@ -226,3 +226,13 @@ Client Issues There are other approaches, but the other approaches all require changes to the server side as well, whereas this is self-contained in the client and can be more easily dropped when we drop K4. + +License + + Copyright 2006, 2007, 2008, 2013 + The Board of Trustees of the Leland Stanford Junior University + + Copying and distribution of this file, with or without modification, + are permitted in any medium without royalty provided the copyright + notice and this notice are preserved. This file is offered as-is, + without any warranty. diff --git a/docs/objects-and-schemes b/docs/objects-and-schemes new file mode 100644 index 0000000..57c2f9f --- /dev/null +++ b/docs/objects-and-schemes @@ -0,0 +1,100 @@ + Supported Object Types and ACL Schemes + +Introduction + + This is a list of all supported wallet object types and ACL schemes in + the current version of wallet, with some brief information about the + properties of each one. For more detailed documentation, see the + documentation of the underlying Wallet::Object::* class or + Wallet::ACL::* class referenced here. + +Object Types + + file + + Stores an arbitrary file and allows retrieval of that file. The file + must be stored before it can be retrieved. All files are stored on + the local file system of the wallet server in a directory organized by + a hash of the name of the file object. The size of file objects is + limited by wallet server configuration. File contents may include nul + characters. + + Implemented via Wallet::Object::File. + + keytab + + Stores a keytab representing private keys for a given Kerberos + principal. The object name is the Kerberos principal (without the + realm). On object creation, the Kerberos principal is created in the + underlying KDC; on object destruction, the Kerberos principal is also + deleted. Normally, any retrieval of the object creates new random + keys for all supported enctypes and then returns a new keytab + containing those keys. Store is not supported. + + Keytab objects with the unchanging flag set will retrieve the existing + keys from the Kerberos KDC instead of randomizing the keys. For MIT + Kerberos, this requires a custom backend be installed on the KDC. + + The enctypes of the returned keys can be restricted by setting the + enctypes attribute on the wallet object. + + Implemented via Wallet::Object::Keytab. + +ACL Schemes + + krb5 + + The value is a string representation of a Kerberos principal name. + This ACL grants access if the authenticated wallet client user (as + determined by remctl or whatever other protocol is used for the wallet + transport) equals the ACL value. + + Implemented via Wallet::ACL::Krb5. + + krb5-regex + + Like krb5, but instead of taking the principal string, takes a regular + expression that is matched against the principal string. Grants + access if the regular expression matches the user identity. + + Implemented via Wallet::ACL::Krb5::Regex. + + ldap-attr + + The value is an LDAP attribute, an equal sign, and the value that + attribute must have. The LDAP entry for the user (determined via + site-local customization in the wallet configuration file) is + retrieved, and the wallet server checks that the user's LDAP entry + contains that attribute with that value. If so, access is granted. + This effectively implements an entitlement check. + + Implemented via Wallet::ACL::LDAP::Attribute. + + netdb + + The value is a hostname. NetDB (a system for managing DNS, DHCP, and + related machine information) is queried to see what roles the client + user has for that hostname. If the user has a role of user, admin, or + team, the ACL grants access. + + Implemented via Wallet::ACL::NetDB. + + netdb-root + + Identical to netdb, except that the user identity is taken as a + Kerberos principal and must be in the form of <user>/root@<realm>. + The /root part is stripped before checking NetDB for roles. This + forces users to use /root instances for wallet operations instead of + their normal principals. + + Implemented via Wallet::ACL::NetDB::Root. + +License + + Copyright 2012, 2013 + The Board of Trustees of the Leland Stanford Junior University + + Copying and distribution of this file, with or without modification, + are permitted in any medium without royalty provided the copyright + notice and this notice are preserved. This file is offered as-is, + without any warranty. @@ -34,7 +34,7 @@ SQLite Database Setup SQLite is very nice in that you don't have to create the database first. You don't even have to create the file. Just create - /etc/wallet.conf with something like: + /etc/wallet/wallet.conf with something like: $DB_DRIVER = 'SQLite'; $DB_INFO = '/path/to/database'; @@ -85,3 +85,13 @@ Wallet Configuration acl create command, add the ACL entries that should own that object to that ACL with acl add, and then set that ACL as the owner of the object with the owner command. + +License + + Copyright 2007, 2008, 2010, 2012, 2013 + The Board of Trustees of the Leland Stanford Junior University + + Copying and distribution of this file, with or without modification, + are permitted in any medium without royalty provided the copyright + notice and this notice are preserved. This file is offered as-is, + without any warranty. diff --git a/docs/stanford-naming b/docs/stanford-naming index 7315c1e..bdf5027 100644 --- a/docs/stanford-naming +++ b/docs/stanford-naming @@ -62,107 +62,202 @@ Object Naming it should get its own object type first and to agree on a naming convention for that type of thing. - All file object names start with a short indicator of the responsible - group, a dash, and then either the short, unqualified hostname (if - they're only used on a single host) or the service name for which that - object is used. + There are two basic types of file objects: ones that are tied to a + particular system, and ones that are not. For the ones that are tied + to a particular system, we use a naming convention very similar to + host-based Kerberos principals so that we can set up default ACLs + based on the host. For ones that are not, we require an indication of + the repsonsible group in each file object, since the rest of the name + can often be ambiguous. - Then, we use the following naming conventions for different types of - objects: + File objects are named with two or more slash-separated components + (again, similar to Kerberos principals). The first is the type of + file being stored. The rest vary based on the file type. - <group>-<server>-htpasswd-<app> + We previously instead used <group>-<server>-<type>, but that caused + various problems in parsing because groups, servers, and types all + also contained dashes. Slashes are much less ambiguous. This + document shows both the new and the old form. + + Host-based: + + htpasswd/<server>/<app> An .htpasswd file for HTTP Basic Authentication for special-case - web configurations that require such a thing. + web configurations that require such a thing. <server> is the + server (or group of servers) on which the file will be stored - <group>-<server>-pam-<app> + (OLD: <group>-<server>-htpasswd-<app>) + + password-ipmi/<server> + + Stores the password for remote IPMI/iLO/ILOM access to the + system. - A PAM configuration for <app> that requires secure information, - such as a password for pam_msyql. <server> may be either a - specific server name or a general class of servers (production and - test) that uses that PAM configuration. + (OLD: <group>-<server>-password-ipmi) - <group>-<server>-password-<account> + password-root/<server> - A password for some account that isn't covered by one of the more - specific naming conventions, such as a password used to connect to - a remote ssh service. + Stores the root password for a given server. - <group>-<server>-ssh-<type> + (OLD: <group>-<server>-password-root) + + password-tivoli/<server> + + Stores the Tivoli TSM backup password for a given server. See + also tivoli-key/<server>, but depending on what one wants to do + with the password, this may be a better representation. + + (OLD: <group>-<server>-password-tivoli) + + ssh-<type>/<server> Stores the SSH private key for <server>. For shared private keys across a pool, <server> should be the name of the pool, or possibly some unambiguous name for the set of systems. <type> is - the type of SSH key (RSA or DSA). + the type of SSH key (rsa or dsa, in lowercase). + + (OLD: <group>-<server>-ssh-<type>) - <group>-<server>-ssl-key + ssl-key/<server>[/<application>] - Stores the SSL X.509 certificate private key for <server>. Use - unix-star-ssl-key for the key for the *.stanford.edu certificate. - The public certificate we manage external to wallet since it - doesn't need to be protected or encrypted. + Stores the SSL X.509 certificate private key for <server>. Used + for Apache, Postfix, LDAP, and similar cases where the certificate + should match the host name. The public certificate we manage + external to wallet since it doesn't need to be protected or + encrypted. <server> here should be the CN of the certificate, + which may be different than the hostname (for hosts with multiple + virtual hosts, for example, or because the certificate is for a + load-balanced name). - <group>-<server>-tivoli-key + An optional <application> component may be added if there are + multiple certificates with the same host name as the CN but with + different private keys. (This may happen if, for example, + multiple services are running on the same FQDN but should have + isolated security contexts.) + + Use ssl-key/starYYYY.stanford.edu for the key for the + *.stanford.edu certificate, where YYYY is the expiration year. + + (OLD: <group>-<server>-ssl-key) + + ssl-keypair/<server>[/<application>] + + Same as ssl-key except that the signed certificate is included in + the same file as the private key. This is used for convenience + with some applications that want to have both the signed + certificate and private key in the same file. + + The meaning of <server> and <application> are the same as for + ssl-key. + + tivoli-key/<server> The Tivoli password or backup encryption key for this server. Both the password and the encryption key, if used, are stored in the same file, so both are stored together. This file is found at /etc/adsm/TSM.PWD. - <group>-<service>-config-<name> + (OLD: <group>-<server>-tivoli-key) + + In all cases, <server> should be a fully-qualified domain name in the + new naming convention. In the old naming convention, .stanford.edu + was omitted, but this adds unnecessary ambiguity. + + Service-based: + + config/<group>/<service>/<name> A configuration file named <name> that contains some secure information, such as a database password. Ideally, the secure data should be stored in a separate file and assembled into the - configuration file, but that isn't always the path of least - resistance. Only use this naming convention if there is not a - more specific one below. + configuration file. This is reserved for configuration files that + hold nothing but authentication information. Only use this naming + convention if there is not a more specific one below. - <group>-<service>-db-<name> + (OLD: <group>-<service>-config-<name>) - Stores the database password for the database named <name>. This - may be a file containing only the database password or a Perl - AppConfig configuration file with the database connection - information including the password. + db/<group>/<service>/<database> - <group>-<service>-gpg-key + Stores the database password for <service> access to the database + named <database>. This may be a file containing only the database + password or a Perl AppConfig configuration file with the database + connection information including the password. + + (OLD: <group>-<service>-db-<database>) + + gpg-key/<group>/<service> Stores the GnuPG private key for a service that needs to do GnuPG signing or encryption. - <group>-<service>-properties + (OLD: <group>-<service>-gpg-key) + + password/<group>/<service>/<name> + + A password for some account, service, keystore, or something + similar that is not covered by one of the more specific naming + conventions, such as a password used to connect to a remote ssh + service. <service> is the service that uses this password and + <name> is the thing the password is used for (such as the remote + account name). This may be a file containing only the password, + or a configuration file of some type that includes a field name + and the password. (However, use the db type described above for + database passwords.) + + (OLD: <group>-<server>-password-<account>) + + properties/<group>/<service>[/<name>] The properties file for a Java application that contains some secure data (such as SSL key passwords or database passwords). - Ideally the secure data should be stored in separate files, but - sometimes it's too hard to separate out chunks of a properties - file. + This should only be used for a properties file that contains only + the password and closely-related information, such as database + connection information. For anything else, switch to storing the + password separately using the password type above and building the + properties file dynamically from the password and a template. The + optional <name> component is for when there are multiple files + stored for a particular service. - <group>-<service>-puppetconf + (OLD: <group>-<service>-properties) - A puppet.conf configuration file for Puppet that contains some - secure data (such as SSL key passwords or database passwords). - Ideally the secure data should be stored in separate files, but - Puppet likes to use a single configuration file. + ssl-keystore/<group>/<service>[/<name>] - <group>-<service>-shibboleth + The Java keystore file (containing both public and private key) + used by a service for authentication to other services. If a + given service uses more than one, use the optional <name> + component to distinguish. - The shibboleth.xml configuration file for a service, when it - contains some secure data (such as database passwords for shared - sessions). Ideally, the secure data should be stored in separate - files and assembled into a shibboleth.xml file, but that isn't - always the path of least resistance. + (OLD: <group>-<service>-ssl-keystore) - <group>-<service>-ssl-pkcs12 + ssl-pkcs12/<group>/<service>[/<name>] The PKCS#12 file (containing both public and private key) used by a service for authentication to other services. If a given - service uses more than one, include the purpose in the <service> - part of the name. + service uses more than one, use the optional <name> component to + distinguish. + + (OLD: <group>-<service>-ssl-pkcs12) - In all cases, <server> is the server (or group of servers) on which - the file will be stored, not the server expecting that key material - for authentication. + If there are separate objects for different tiers, <service> should be + left unqualified for production and be qualified with a dash and the + tier for non-production. For example, ssl-keystore/idg/accounts would + be the production keystore for the Accounts application, and + ssl-keystore/idg/accounts-uat would be the keystore for the UAT + version. + + We previously stored a wider variety of configuration files before + developing a way to dynamically substitute the password into a larger + configuration file during deployment. The following file types are + obsolete and should no longer be used; instead, the configuration file + should be constructed by substituting a password (usually stored as a + password or db type) into the configuration file. + + Obsolete: + + <group>-<server>-pam-<app> + <group>-<service>-puppetconf + <group>-<service>-shibboleth ACL Naming @@ -222,3 +317,13 @@ ACL Naming krb5 host/example-dev.stanford.edu@stanford.edu Such an ACL would normally be named service/example. + +License + + Copyright 2008, 2009, 2010, 2011, 2013 + The Board of Trustees of the Leland Stanford Junior University + + Copying and distribution of this file, with or without modification, + are permitted in any medium without royalty provided the copyright + notice and this notice are preserved. This file is offered as-is, + without any warranty. |