[
https://issues.apache.org/jira/browse/CLOUDSTACK-1389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13590830#comment-13590830
]
Sheng Yang commented on CLOUDSTACK-1389:
----------------------------------------
Fail to input on SSL keystore generation won't result in daemon failure to
start...
As long as you see:
2013-02-27 09:52:22,191 WARN [cloud.server.ConfigurationServerImpl]
(Timer-2:null) Would use fail-safe keystore to continue.
java.io.IOException: Fail to generate certificate!: timeout
It said "would use fail-safe keystore", then we're fine, at least on ssl
keystore generation.
I don't know much about later inject key script. That's probably a blocker.
> 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
> Labels: security
>
> 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
> -store
> pass vmops.com -keypass vmops.com -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
> -store
> pass vmops.com -keypass vmops.com -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
> -store
> pass vmops.com -keypass vmops.com -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.
> java.io.IOException: Fail to generate certificate!: timeout
> at
> com.cloud.server.ConfigurationServerImpl.generateDefaultKeystore(ConfigurationServerImpl.java:490)
> at
> com.cloud.server.ConfigurationServerImpl.updateSSLKeystore(ConfigurationServerImpl.java:511)
> at
> com.cloud.server.ConfigurationServerImpl.persistDefaultValues(ConfigurationServerImpl.java:272)
> at
> com.cloud.server.ConfigurationServerImpl.configure(ConfigurationServerImpl.java:144)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:319)
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
> at
> org.springframework.aop.aspectj.MethodInvocationProceedingJoinPoint.proceed(MethodInvocationProceedingJoinPoint.java:8
> 0)
> at
> com.cloud.utils.db.TransactionContextBuilder.AroundAnyMethod(TransactionContextBuilder.java:37)
> at sun.reflect.GeneratedMethodAccessor35.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.springframework.aop.aspectj.AbstractAspectJAdvice.invokeAdviceMethodWithGivenArgs(AbstractAspectJAdvice.java:621)
> at
> org.springframework.aop.aspectj.AbstractAspectJAdvice.invokeAdviceMethod(AbstractAspectJAdvice.java:610)
> at
> org.springframework.aop.aspectj.AspectJAroundAdvice.invoke(AspectJAroundAdvice.java:65)
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
> at
> org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:90)
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
> at
> org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:202)
> at com.sun.proxy.$Proxy387.configure(Unknown Source)
> at
> com.cloud.utils.component.ComponentContext.initComponentsLifeCycle(ComponentContext.java:110)
> at
> com.cloud.servlet.CloudStartupServlet$1.run(CloudStartupServlet.java:50)
> at java.util.TimerThread.mainLoop(Timer.java:512)
> at java.util.TimerThread.run(Timer.java:462)
> 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, 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. 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: http://www.atlassian.com/software/jira
