cloudstack-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ian Duffy (JIRA)" <>
Subject [jira] [Commented] (CLOUDSTACK-1389) Interactive Password Prompts during Management Server Startup
Date Wed, 19 Jun 2013 21:46:20 GMT


Ian Duffy commented on CLOUDSTACK-1389:

Any progress or workaround for this?
> Interactive Password Prompts during Management Server Startup
> -------------------------------------------------------------
>                 Key: CLOUDSTACK-1389
>                 URL:
>             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, 4.2.0
>         Environment: devcloud
>            Reporter: John Burwell
>            Assignee: Abhinandan Prateek
>              Labels: security
>             Fix For: 4.2.0
> When starting the management with no SSL certificate present, the system attempts to
run a shell script that requires interactive password entry.  Executing the following steps
with a user that is either non-sudoer or a sudoer that requires a password authentication
to perform sudo actions (and who has not already authenticated to sudo), execute the following
commands from root directory of a cloudstack/4.1 checkout:
>    1. mvn -P developer clean install
>    2. mvn -pl :cloud-client-ui jetty:run
> During the startup process, the management server will not find the cloud.keystore in
the the client/target/cloud-client-ui-4.1-SNAPSHOT/WEB-INF/classes directory, and attempt
to generate an SSL certificate using the following shell scripts: 
>    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
> pass -keypass -keyalg RSA -validity 3650 -dname cn="Cloudstack User",ou="0.8.31",o="0.8.31",c="Unknown"
> The following is a capture of the script timeout error from the vmops.log:
>    2013-02-27 09:52:17,157 INFO  [cloud.server.ConfigurationServerImpl] (Timer-2:null)
SSL keystore located at /Users/jburwell/Docum
> ents/projects/cloudstack/src/cloudstack-basho/client/target/cloud-client-ui-4.1.0-SNAPSHOT/WEB-INF/classes/cloud.keystore
> 2013-02-27 09:52:17,176 DEBUG [utils.script.Script] (Timer-2:null) Executing: sudo keytool
-genkey -keystore /Users/jburwell/Docu
> ments/projects/cloudstack/src/cloudstack-basho/client/target/cloud-client-ui-4.1.0-SNAPSHOT/WEB-INF/classes/cloud.keystore
> pass -keypass -keyalg RSA -validity 3650 -dname cn="Cloudstack User",ou="0.8.31",o="0.8.31",c="Unknown"

> 2013-02-27 09:52:22,188 WARN  [utils.script.Script] (Script-1:null) Interrupting script.
> 2013-02-27 09:52:22,190 WARN  [utils.script.Script] (Timer-2:null) Timed out: sudo keytool
-genkey -keystore /Users/jburwell/Docu
> ments/projects/cloudstack/src/cloudstack-basho/client/target/cloud-client-ui-4.1.0-SNAPSHOT/WEB-INF/classes/cloud.keystore
> pass -keypass -keyalg RSA -validity 3650 -dname cn="Cloudstack User",ou="0.8.31",o="0.8.31",c="Unknown"
.  Ou
> tput is: dyld: DYLD_ environment variables being ignored because main executable (/usr/bin/sudo)
is setuid or setgid
> 2013-02-27 09:52:22,191 WARN  [cloud.server.ConfigurationServerImpl] (Timer-2:null) Would
use fail-safe keystore to continue.
> Fail to generate certificate!: timeout
>         at
>         at
>         at
>         at
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at sun.reflect.NativeMethodAccessorImpl.invoke(
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(
>         at java.lang.reflect.Method.invoke(
>         at
>         at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(
>         at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(
>         at org.springframework.aop.aspectj.MethodInvocationProceedingJoinPoint.proceed(
> 0)
>         at
>         at sun.reflect.GeneratedMethodAccessor35.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(
>         at java.lang.reflect.Method.invoke(
>         at org.springframework.aop.aspectj.AbstractAspectJAdvice.invokeAdviceMethodWithGivenArgs(
>         at org.springframework.aop.aspectj.AbstractAspectJAdvice.invokeAdviceMethod(
>         at org.springframework.aop.aspectj.AspectJAroundAdvice.invoke(
>         at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(
>         at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(
>         at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(
>         at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(
>         at com.sun.proxy.$Proxy387.configure(Unknown Source)
>         at
>         at$
>         at java.util.TimerThread.mainLoop(
>         at
> This shell script requires that sudo be installed and that the daemon user have password-less
sudo access to successfully execute.  If the daemon user does not have password-less sudo
access, sudo interactively 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,, 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
>    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.
that accepts the password, algorithm, and key length as command line parameters, and places
the resulting keys in the appropriate locations.  Furthermore, the script should remove the
use of sudo, and leave the determination of sudo's necessity to the administrator executing
the script.  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:

View raw message