[
https://issues.apache.org/jira/browse/CLOUDSTACK-1389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13587523#comment-13587523
]
ilya musayev commented on CLOUDSTACK-1389:
------------------------------------------
John,
Would you please describe how to reproduce this issue.
Thanks
ilya
> 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 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.
--
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
