[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-1389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rohit Yadav closed CLOUDSTACK-1389.
-----------------------------------


Daan, thanks you Sir!

> 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, 4.2.0
>         Environment: devcloud
>            Reporter: John Burwell
>              Labels: security
>             Fix For: 4.4.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
>  -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 was sent by Atlassian JIRA
(v6.2#6252)

Reply via email to