cloudstack-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daan Hoogland (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CLOUDSTACK-1389) Interactive Password Prompts during Management Server Startup
Date Fri, 08 Aug 2014 09:33:13 GMT

    [ https://issues.apache.org/jira/browse/CLOUDSTACK-1389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14090529#comment-14090529
] 

Daan Hoogland commented on CLOUDSTACK-1389:
-------------------------------------------

b2efdf20c05ae5659965a872115745e5821dccc8 at your very wish

> 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)

Mime
View raw message