Cloudron makes it easy to run web apps like WordPress, Nextcloud, GitLab on your server. Find out more or install now.


    Cloudron Forum

    • Register
    • Login
    • Search
    • Categories
    • Recent
    • Tags
    • Popular

    Solved Add password for initial configuration

    Feature Requests
    4
    11
    332
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • mehdi
      mehdi App Dev last edited by

      Just went through a fresh cloudron install, and I must say I am not comfortable with the initial installation process : anyone connecting to the server's IP before the legitimate admin could basically "take over" the server in question. We could even imagine an advanced attacker taking full control of the server through this, then installing a "fake" installation page that mimics the original one, so the legitimate admin would not notice anything.

      The solution to this would be some sort of a password, or key, that the CLI would give you, or ask you for, upon install, that you would then have to enter into the web interface to authenticate to it. It could potentially be an optional parameter.

      1 Reply Last reply Reply Quote 0
      • girish
        girish Staff last edited by girish

        We actually implemented this a couple of releases ago. If you run cloudron-setup --generate-setup-token, it will create a setup token which is saved in /etc/cloudron/SETUP_TOKEN . At the end of setup script, it will also display the token.

        ruihildt 1 Reply Last reply Reply Quote 4
        • girish
          girish Staff last edited by

          I updated https://docs.cloudron.io/installation/

          1 Reply Last reply Reply Quote 4
          • ruihildt
            ruihildt @girish last edited by

            @girish Wouldn't it be better if this was the default for new installations, and then have the flag for disabling it?

            nebulon 1 Reply Last reply Reply Quote 3
            • nebulon
              nebulon Staff @ruihildt last edited by

              @ruihildt I guess that is a bit of a trade-off between usability and real threat. Generally an attacker would have to get the time window right, know the ip address and then will be able to setup the Cloudron. However to actually then also modify the code to let the normal user believe nothing the system is untampered with, he/she needs to have SSH access, which the dashboard does not give as such. So further an attacker would need to know a security hole in Cloudron components.

              Overall from my current perspective, that risk is quite low. Does anyone else have a different idea how to exploit this?

              mehdi 1 Reply Last reply Reply Quote 1
              • mehdi
                mehdi App Dev @nebulon last edited by

                @nebulon No SSH access needed, an attacker could just use the Volumes feature to get write access to the cloudron code folder, and be able to do whatever they want.

                nebulon 1 Reply Last reply Reply Quote 0
                • nebulon
                  nebulon Staff @mehdi last edited by

                  @mehdi interesting idea. The volumes however only allow to configure /mnt, /media, /opt or /srv for the filesystem type.

                  1 Reply Last reply Reply Quote 1
                  • girish
                    girish Staff last edited by

                    Yeah, the volumes logic specifically prevents mounting random things when using the "unmanaged" mounts (i.e things which Cloudron does not mount and manage itself) - https://git.cloudron.io/cloudron/box/-/blob/master/src/volumes.js#L52

                    1 Reply Last reply Reply Quote 0
                    • mehdi
                      mehdi App Dev last edited by

                      OK, my bad about volumes, but I believe the Cloudron dashboard was not designed with the goal of defending against an admin constantly in mind. So it is safe to assume that there are probably bypasses lurking somewhere, maybe in the docker addon, maybe in the backups stuff ... in any case, I believe that having this as default would be a minor inconvenience, with a non-negligible security benefit.

                      ruihildt 1 Reply Last reply Reply Quote 3
                      • ruihildt
                        ruihildt @mehdi last edited by

                        @mehdi This is exactly what I'm most worried about, the unknown unknowns, and it seems here the added friction is negligible: copying the token from the command line to the webbrowser.

                        ruihildt 1 Reply Last reply Reply Quote 1
                        • ruihildt
                          ruihildt @ruihildt last edited by

                          As you probably have access to the IP of the server, you could simply display a link once the setup is complete in the CLI:

                          https://<IP>?<token>
                          

                          So not even copy/paste needed for most.^^

                          1 Reply Last reply Reply Quote 3
                          • First post
                            Last post
                          Powered by NodeBB