[ 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