Mailing-List: contact issues-help@cloudstack.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cloudstack.apache.org
Date: Thu, 19 Sep 2013 08:07:56 +0000 (UTC)
From: "Abhinandan Prateek (JIRA)" <jira@apache.org>
To: cloudstack-issues@incubator.apache.org
Message-ID: <JIRA.12634046.1361847523986.160732.1379578076707@arcas>
In-Reply-To: <JIRA.12634046.1361847523986@arcas>
References: <JIRA.12634046.1361847523986@arcas>
Subject: [jira] [Updated] (CLOUDSTACK-1389) Interactive Password Prompts
 during Management Server Startup
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Abhinandan Prateek updated CLOUDSTACK-1389:
-------------------------------------------

    Fix Version/s:     (was: 4.2.0)
                   4.2.1
    
> 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.2.1
>
>
> 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