cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John Burwell (JIRA)" <j...@apache.org>
Subject [jira] [Created] (CLOUDSTACK-1389) Interactive Password Prompts during Management Server Startup
Date Tue, 26 Feb 2013 03:00:13 GMT
John Burwell created CLOUDSTACK-1389:
----------------------------------------

             Summary: Interactive Password Prompts during Management Server Startup
                 Key: CLOUDSTACK-1389
                 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1389
             Project: CloudStack
          Issue Type: Bug
      Security Level: Public (Anyone can view this level - this is the default.)
          Components: Management Server
    Affects Versions: 4.1.0
         Environment: devcloud
            Reporter: John Burwell
            Priority: Blocker


When starting the management server with no SSL certificate present, the system attempts to
run a shell script, /Users/jburwell/Documents/projects/cloudstack/src/cloudstack-basho/client/
target/cloud-client-ui-4.1.0-SNAPSHOT/WEB-INF/classes/cloud.keystore
-storepass vmops.com -keypass vmops.com -keyalg RSA -validity 3650 -dname
cn="Cloudstack User",ou="0.8.31",o="0.8.31",c="Unknown", to automatically generate the SSL
certificate.  This shell script requires that sudo be installed and that the daemon user have
password-less sudo access to successfully.  If the daemon user does not have password-less
sudo access, sudo attempts to prompt the user for a password -- causing daemon startup to
fail.  In addition to encouraging administrators to grant too much privilege to a daemon user
and interactively prompting from a daemon process, this script's behavior presents the following
potential security vulnerabilities:

   1. If this script successfully executes in a production environment, it will create a SSL
certificate with known default credentials, vmops.com, that could be exploited by an attacker.
 Additionally, it makes assumptions about algorithms and key lengths that may not be applicable
to a user's environment.  In this scenario, the system defaults to an less secure state with
little or no notice to the administrator.
   2. It assumes/encourages a daemon user account has password-less sudo access.  Granting
such access to a daemon user would be not be considered a security best practice.  Daemon
users should have least privilege necessary to execute in order to limit the impact of a security
breach.
   3. It assumes/mandates the presence of an optional package on some distributions.  RHEL/CentOS
do not require sudo in a minimal installation, and some administrators elect not to use it.
 While I personally don't agree with such an approach, I don't think we should force our opinions
on CloudStack administrators. 

I suggest extracting the script into the bin directory for manual execution (e.g. generate-certificate.sh)
that accepts the password, algorithm, and key length as command line parameters, and places
the resulting keys in the appropriate locations.  If the agent starts and the keys are not
present, an error should be logged explaining the problem, and the system should either fallback
to non-SSL or gracefully exit.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message