Sheng, No windows here -- Mac OS X and Ubuntu. The issue is not that I don't have sudo available, it's that a daemon is interactively prompting a user. Under no circumstances should a daemon block for user input. In addition to this issue, I see the following issues with auto-generating an SSL key in this manner:
If this script successfully executes in a production environment, it will create a SSL certificate with known default credentials 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. 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. It assumes/mandates the presence of an optional package on some distributions. RHEL/CentOS does not require sudo, and some administrators elect not to use it. While I personally don't agree with such an approach, I do not think that we should impose our opinions on CloudStack administrators. In summary, the current behavior violates normal daemon operations, creates a potential security vulnerabilities, and removes choice from the administrator. As such, I have opened a defect, CLOUDSTACK-1389 [1], to track further discussion/address these issues. To my mind, the solution should to extract 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. Thanks, -John [1]: https://issues.apache.org/jira/browse/CLOUDSTACK-1389 On Feb 25, 2013, at 6:52 PM, Sheng Yang <sh...@yasker.org> wrote: > You mean Windows? I don't think we would recommend CS on windows, many > people already got enough trouble with it. > > The generated result used for SSL communication. For deployment, it > would be needed to generate different key for different mgmt servers. > For developer it's not necessary. > > If we want to disable it, we need to tell if it's developer who > running the mgmt server or not. > > --Sheng > > On Mon, Feb 25, 2013 at 2:19 PM, Chiradeep Vittal > <chiradeep.vit...@citrix.com> wrote: >> Agree that this is not cross-platform-friendly. >> >> On 2/25/13 7:19 AM, "John Burwell" <jburw...@basho.com> wrote: >> >>> All, >>> >>> When running "mvn -pl :cloud-client-ui jetty:run", I prompted >>> interactively for the password to the cloud.keystore. It appears that >>> the server is generating a key if none is present based on the following >>> output: >>> >>> INFO [cloud.server.ConfigurationServerImpl] (Timer-2:) SSL keystore >>> located at >>> /Users/jburwell/Documents/projects/cloudstack/src/cloudstack-basho/client/ >>> target/cloud-client-ui-4.1.0-SNAPSHOT/WEB-INF/classes/cloud.keystore >>> Password:WARN [utils.script.Script] (Script-1:) Interrupting script. >>> WARN [utils.script.Script] (Timer-2:) Timed out: 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 >>> -storepass vmops.com -keypass vmops.com -keyalg RSA -validity 3650 -dname >>> cn="Cloudstack User",ou="0.8.31",o="0.8.31",c="Unknown" . Output is: >>> dyld: DYLD_ environment variables being ignored because main executable >>> (/usr/bin/sudo) is setuid or setgid >>> WARN [cloud.server.ConfigurationServerImpl] (Timer-2:) Would use >>> fail-safe keystore to continue. >>> java.io.IOException: Fail to generate certificate!: timeout >>> >>> My first question is can this default behavior be disabled so that I can >>> get the server to start properly? My second question is why are we >>> generating a key in the first place? The shell script code is platform >>> specific (in particular using sudo), and makes many assumptions that may >>> not be acceptable to a user. Why not error out with a message informing >>> the user that they need to generate an SSL key? >>> >>> Thanks, >>> -John >>
