Forked from
emulab / emulab-devel
25209 commits behind the upstream repository.
-
Leigh B. Stoller authored
* SSL based server (sslxmlrpc_server.py) that wraps the existing Python classes (what we export via the existing ssh XMLRPC server). I also have a demo client that is analogous the ssh demo client (sslxmlrpc_client.py). This client looks for an ssl cert in the user's .ssl directory, or you can specify one on the command line. The demo client is installed on ops, and is in the downloads directory with the rest of the xmlrpc stuff we export to users. The server runs as root, forking a child for each connection and logs connections to /usr/testbed/log/sslxmlrpc.log via syslog. * New script (mkusercert) generates SSL certs for users. Two modes of operation; when called from the account creation path, generates a unencrypted private key and certificate for use on Emulab nodes (this is analagous to the unencrypted SSH key we generate for users). The other mode of operation is used to generate an encrypted private key so that the user can drag a certificate to their home/desktop machine. * New webpage (gensslcert.php3) linked in from the My Emulab page that allows users to create a certificate. The user is prompted for a pass phrase to encrypt the private key, as well as the user's current Emulab login password. mkusercert is called to generate the certificate, and the result is stored in the user's ~/.ssl directory, and spit back to the user as a text file that can be downloaded and placed in the users homedir on their local machine. * The server needs to associate a certificate with a user so that it can flip to that user in the child after it forks. To do that, I have stored the uid of the user in the certificate. When a connection comes in, I grab the uid out of the certificate and check it against the DB. If there is a match (see below) the child does the usual setgid,setgroups,setuid to the user, instantiates the Emulab server class, and dispatches the method. At the moment, only one request per connection is dispatched. I'm not sure how to do a persistant connection on the SSL path, but probably not a big deal right now. * New DB table user_sslcerts that stores the PEM formatted certificates and private keys, as well as the serial number of the certificate, for each user. I also mark if the private key is encrypted or not, although not making any use of this data. At the moment, each user is allowed to get one unencrypted cert/key pair and one encrypted cert/key pair. No real reason except that I do not want to spend too much time on this until we see how/if it gets used. Anyway, the serial number is used as a crude form of certificate revocation. When the connection is made, I suck the serial number and uid out of the certificate, and look for a match in the table. If cert serial number does not match, the connection is rejected. In other words, revoking a certificate just means removing its entry from the DB for that user. I could also compare the certificate itself, but I am not sure what purpose that would serve since that is what the SSL handshake is supposed to take of, right? * Updated the documentation for the XMLRPC server to mention the existence of the SSL server and client, with a pointer into the downloads directory where users can pick up the client.
Leigh B. Stoller authored* SSL based server (sslxmlrpc_server.py) that wraps the existing Python classes (what we export via the existing ssh XMLRPC server). I also have a demo client that is analogous the ssh demo client (sslxmlrpc_client.py). This client looks for an ssl cert in the user's .ssl directory, or you can specify one on the command line. The demo client is installed on ops, and is in the downloads directory with the rest of the xmlrpc stuff we export to users. The server runs as root, forking a child for each connection and logs connections to /usr/testbed/log/sslxmlrpc.log via syslog. * New script (mkusercert) generates SSL certs for users. Two modes of operation; when called from the account creation path, generates a unencrypted private key and certificate for use on Emulab nodes (this is analagous to the unencrypted SSH key we generate for users). The other mode of operation is used to generate an encrypted private key so that the user can drag a certificate to their home/desktop machine. * New webpage (gensslcert.php3) linked in from the My Emulab page that allows users to create a certificate. The user is prompted for a pass phrase to encrypt the private key, as well as the user's current Emulab login password. mkusercert is called to generate the certificate, and the result is stored in the user's ~/.ssl directory, and spit back to the user as a text file that can be downloaded and placed in the users homedir on their local machine. * The server needs to associate a certificate with a user so that it can flip to that user in the child after it forks. To do that, I have stored the uid of the user in the certificate. When a connection comes in, I grab the uid out of the certificate and check it against the DB. If there is a match (see below) the child does the usual setgid,setgroups,setuid to the user, instantiates the Emulab server class, and dispatches the method. At the moment, only one request per connection is dispatched. I'm not sure how to do a persistant connection on the SSL path, but probably not a big deal right now. * New DB table user_sslcerts that stores the PEM formatted certificates and private keys, as well as the serial number of the certificate, for each user. I also mark if the private key is encrypted or not, although not making any use of this data. At the moment, each user is allowed to get one unencrypted cert/key pair and one encrypted cert/key pair. No real reason except that I do not want to spend too much time on this until we see how/if it gets used. Anyway, the serial number is used as a crude form of certificate revocation. When the connection is made, I suck the serial number and uid out of the certificate, and look for a match in the table. If cert serial number does not match, the connection is rejected. In other words, revoking a certificate just means removing its entry from the DB for that user. I could also compare the certificate itself, but I am not sure what purpose that would serve since that is what the SSL handshake is supposed to take of, right? * Updated the documentation for the XMLRPC server to mention the existence of the SSL server and client, with a pointer into the downloads directory where users can pick up the client.
GNUmakefile.in 1.18 KiB