cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Burwell <>
Subject Re: 4.1 SSL Password Prompt
Date Tue, 26 Feb 2013 02:59:26 GMT

No windows here -- Mac OS X and Ubuntu.  The issue is not that I don't have sudo available,
it's that a daemon is interactively prompting a user.  Under no circumstances should a daemon
block for user input.  In addition to this issue, I see the following issues with auto-generating
an SSL key in this manner:

If this script successfully executes in a production environment, it will create a SSL certificate
with known default credentials 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.
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
It assumes/mandates the presence of an optional package on some distributions.  RHEL/CentOS
does not require sudo, and some administrators elect not to use it.  While I personally don't
agree with such an approach, I do not think that we should impose our opinions on CloudStack

In summary, the current behavior violates normal daemon operations, creates a potential security
vulnerabilities, and removes choice from the administrator.  As such, I have opened a defect,
CLOUDSTACK-1389 [1], to track further discussion/address these issues.  To my mind, the solution
should to extract the script into the bin directory for manual execution (e.g.
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.  



On Feb 25, 2013, at 6:52 PM, Sheng Yang <> wrote:

> You mean Windows? I don't think we would recommend CS on windows, many
> people already got enough trouble with it.
> The generated result used for SSL communication. For deployment, it
> would be needed to generate different key for different mgmt servers.
> For developer it's not necessary.
> If we want to disable it, we need to tell if it's developer who
> running the mgmt server or not.
> --Sheng
> On Mon, Feb 25, 2013 at 2:19 PM, Chiradeep Vittal
> <> wrote:
>> Agree that this is not cross-platform-friendly.
>> On 2/25/13 7:19 AM, "John Burwell" <> wrote:
>>> All,
>>> When running "mvn -pl :cloud-client-ui jetty:run", I prompted
>>> interactively for the password to the cloud.keystore.  It appears that
>>> the server is generating a key if none is present based on the following
>>> output:
>>> INFO  [cloud.server.ConfigurationServerImpl] (Timer-2:) SSL keystore
>>> located at
>>> /Users/jburwell/Documents/projects/cloudstack/src/cloudstack-basho/client/
>>> target/cloud-client-ui-4.1.0-SNAPSHOT/WEB-INF/classes/cloud.keystore
>>> Password:WARN  [utils.script.Script] (Script-1:) Interrupting script.
>>> WARN  [utils.script.Script] (Timer-2:) Timed out: sudo keytool -genkey
>>> -keystore
>>> /Users/jburwell/Documents/projects/cloudstack/src/cloudstack-basho/client/
>>> target/cloud-client-ui-4.1.0-SNAPSHOT/WEB-INF/classes/cloud.keystore
>>> -storepass -keypass -keyalg RSA -validity 3650 -dname
>>> cn="Cloudstack User",ou="0.8.31",o="0.8.31",c="Unknown" .  Output is:
>>> dyld: DYLD_ environment variables being ignored because main executable
>>> (/usr/bin/sudo) is setuid or setgid
>>> WARN  [cloud.server.ConfigurationServerImpl] (Timer-2:) Would use
>>> fail-safe keystore to continue.
>>> Fail to generate certificate!: timeout
>>> My first question is can this default behavior be disabled so that I can
>>> get the server to start properly?  My second question is why are we
>>> generating a key in the first place?  The shell script code is platform
>>> specific (in particular using sudo), and makes many assumptions that may
>>> not be acceptable to a user.  Why not error out with a message informing
>>> the user that they need to generate an SSL key?
>>> Thanks,
>>> -John

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message