1. 23 May, 2018 1 commit
    • Leigh Stoller's avatar
      Limit new certificate expiration to no later then the signer expiration · d7e60116
      Leigh Stoller authored
      so that we do not get into the same situation as the Geni Portal.
      
      All of the Cloudlab clusters are more then two years from the CA
      expiration, so this won't present a problem for a while, but we do have
      certificates floating around that are set to expire after the CA.
      User certificates we can regenerate as needed, slice certificates will
      age out before then.
      
      I bet this *is* a problem on geni racks where expiration is much closer
      to now.
      d7e60116
  2. 11 Oct, 2017 1 commit
  3. 20 Sep, 2016 1 commit
    • Leigh Stoller's avatar
      Two changes: · aea0f297
      Leigh Stoller authored
      1. Fix max days, supposed to be 1000 but was getting set back to 365 in
         one missed place.
      
      2. Add -P option; use the existing passphrase from the DB instead of a
         new one. This makes it easy to update someones encrypted certificate,
         reusing their key (-r) and their password.
      
      Note to self; we do not give Portal users a UI for updating their
      encrypted certificates, and we do not do it for them when they
      expire. That will need to change real soon (like, by tomorrow morning
      when the next user gets an expired certificate error).
      aea0f297
  4. 16 Mar, 2016 1 commit
  5. 01 Mar, 2016 1 commit
  6. 26 May, 2015 1 commit
  7. 13 Feb, 2015 1 commit
  8. 28 Jan, 2015 2 commits
  9. 22 Jan, 2015 1 commit
  10. 15 Sep, 2014 1 commit
  11. 27 Aug, 2014 1 commit
    • Leigh Stoller's avatar
      Large set of changes for using the Geni trusted signer tool, to · 980f6cbd
      Leigh Stoller authored
      authenticate Geni users to CloudLab (who do not have Emulab accounts).
      CloudLab users must have an account to do anything (unlike APT which allows
      guest users). But instead of requiring them to go through the Emulab
      account creation (high bar), let then use their Geni credentials to prove
      who they are. We then build a local account for that new user, and save off
      the speaksfor credential so that we can act on their behalf when talking to
      the backend clusters (and their MA to get their ssh keys).
      
      These users do not have a local account password, so they cannot log into
      the web interface using the Emulab login page, nor do they have a shell on
      ops.
      
      Once authenticated, we put the appropriate cookies into the browser via
      javascript, so they can use the Cloud (okay, APT) web interface (they
      appear logged in).
      
      I make use of the nonlocal_id field of the users table, which was not being
      used for anything else. Officially, these are "nonlocal" users in the code
      (IsNonLocal()).
      
      When a nonlocal user instantiates a profile, we use their speaksfor
      credential to ask their home MA for their ssh keys, which we then store in
      the DB, and then provide to the aggregate via the CreateSliver call.
      Note that no provision has been made for users who edit their profile and
      add keys; I am not currently expecting these users to stumble into the web
      interface (yet).
      980f6cbd
  12. 20 Aug, 2014 1 commit
  13. 05 Nov, 2012 1 commit
  14. 24 Sep, 2012 1 commit
    • Eric Eide's avatar
      Replace license symbols with {{{ }}}-enclosed license blocks. · 6df609a9
      Eric Eide authored
      This commit is intended to makes the license status of Emulab and
      ProtoGENI source files more clear.  It replaces license symbols like
      "EMULAB-COPYRIGHT" and "GENIPUBLIC-COPYRIGHT" with {{{ }}}-delimited
      blocks that contain actual license statements.
      
      This change was driven by the fact that today, most people acquire and
      track Emulab and ProtoGENI sources via git.
      
      Before the Emulab source code was kept in git, the Flux Research Group
      at the University of Utah would roll distributions by making tar
      files.  As part of that process, the Flux Group would replace the
      license symbols in the source files with actual license statements.
      
      When the Flux Group moved to git, people outside of the group started
      to see the source files with the "unexpanded" symbols.  This meant
      that people acquired source files without actual license statements in
      them.  All the relevant files had Utah *copyright* statements in them,
      but without the expanded *license* statements, the licensing status of
      the source files was unclear.
      
      This commit is intended to clear up that confusion.
      
      Most Utah-copyrighted files in the Emulab source tree are distributed
      under the terms of the Affero GNU General Public License, version 3
      (AGPLv3).
      
      Most Utah-copyrighted files related to ProtoGENI are distributed under
      the terms of the GENI Public License, which is a BSD-like open-source
      license.
      
      Some Utah-copyrighted files in the Emulab source tree are distributed
      under the terms of the GNU Lesser General Public License, version 2.1
      (LGPL).
      6df609a9
  15. 02 Aug, 2012 1 commit
  16. 18 Jun, 2012 1 commit
  17. 30 Jan, 2012 1 commit
    • Leigh Stoller's avatar
      Changes to make it easier for ProtoGeni users! · 3dac3cb8
      Leigh Stoller authored
      * When generating an encrypted SSL certificate, derive an SSH public
        key from the private key and store in the pubkeys table for the
        user. Note that SSH version 2 RSA keys are actually just openssl RSA
        keys, and that ssh-keygen can extract an ssh compatible public key
        from it.
      
      * Change getsslcert.php3 to return the ssh private and public key when
        give the "ssh" boolean argument. This is mostly for the benefit of
        Flack; we probably need a better UI for the user to get this stuff. 
      
      * Remove the requirement that users must upload an SSH key to use
        protogeni, since we now create one for them when they create their
        encrypted SSL certificate.
      
      * Some cleanup; instead of looking at the comment field to determine
        what pubkeys are Emulab created (and should not be deleted), use new
        internal and nodelete flags.
      3dac3cb8
  18. 05 Oct, 2011 1 commit
  19. 12 Aug, 2011 1 commit
  20. 15 May, 2009 1 commit
  21. 17 Nov, 2008 1 commit
    • Leigh Stoller's avatar
      Minor changes to user certs to support certificate revocation lists · 4809cd65
      Leigh Stoller authored
      in the protogeni code. We no longer save the unencrypted certs after
      they are revoked, since protogeni will ignore them. I redid the the
      DB table as well, adding a revoked stamp, and the DN so that we can
      generate the CRL list from the DB directly, without having to run them
      all through openssl.
      
      This commit requires all certs to be regenerated, and the ssl xmlrpc
      server to be restarted.
      4809cd65
  22. 27 Oct, 2008 1 commit
  23. 01 Oct, 2008 1 commit
  24. 15 Jan, 2007 1 commit
  25. 09 Jan, 2007 1 commit
  26. 31 May, 2005 1 commit
  27. 26 Oct, 2004 1 commit
  28. 25 Oct, 2004 1 commit
  29. 01 Sep, 2004 1 commit
    • Leigh Stoller's avatar
      SSL version of the XMLRPC server. · a9c1045e
      Leigh 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.
      a9c1045e