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

John Burwell updated CLOUDSTACK-1389:
-------------------------------------

    Description: 
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.

  was:
When starting the management server with no SSL certificate present, the system 
attempts to run a shell script, 
/Users/jburwell/Documents/projects/cloudstack/src/cloudstack-basho/client/
target/cloud-client-ui-4.1.0-SNAPSHOT/WEB-INF/classes/cloud.keystore
-storepass vmops.com -keypass vmops.com -keyalg RSA -validity 3650 -dname
cn="Cloudstack User",ou="0.8.31",o="0.8.31",c="Unknown", to automatically 
generate the SSL certificate.  This shell script requires that sudo be 
installed and that the daemon user have password-less sudo access to 
successfully.  If the daemon user does not have password-less sudo access, sudo 
attempts to 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.  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.

    
> 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

Reply via email to