Acme.sh: Security: Account credentials and private keys are saved world-readable

[nh2]

acme.sh saves all security credentials, such as AWS secret tokens, in ~/.acme.sh/account.conf.

Unfortunately, it creates that file world-readable, so that any user of the same machine can get your secret tokens.

Same thing with certificate private keys.

That's a security risk; the file should have chmod 600, or the ~/.acme.sh dir should have chmod 700.

[Neilpang]

It saves in your $HOME dir, nobody else can read your home dir.

[nh2]

It saves in your $HOME dir, nobody else can ready your home dir.

@Neilpang that depends a lot on the system, on many systems your home dir has chmod +x.

[nh2]

Also note that other ACME clients take care of this, e.g. https://github.com/lukas2511/dehydrated ensures that any created dirs have chmod 700.

[Neilpang]

you should change your home dir to 700

[nh2]

@Neilpang Yes, but there are lots of setups that require your home dir itself to have chmod +x, e.g. when a mail daemon running as a non-root user drops mail into the home dir, or when a non-root webserver is supposed to serve contents out of your home dir.

For the same reason, ~/.ssh is chmod 700, and openssh checks this thoroughly.

[nh2]

As are config dirs for ~/.gnupg, ~/.thunderbird, and lots of other security/privacy-relevant software.

[Neilpang]

You can manually change ~/.acme.sh to 700

[nh2]

You can manually change ~/.acme.sh to 700

Of course, but it would be better for acme.sh to create the dir with the correct permissions, as most users would expect it to do this, just like ssh, gnupg, aws etc. do this correctly by themselves.

[nh2]

To check how dehydrated does it: https://github.com/lukas2511/dehydrated/blob/aed4272e973bb691b66ffa59fb9b90b952803c01/dehydrated#L12

umask 077 # paranoid umask, we're creating private keys

This is the best approach in my opinion.

[Neilpang]

I knew that, but I don't want to use umask.

There were a lot of the discussions before:
https://github.com/Neilpang/acme.sh/issues/172

https://github.com/Neilpang/acme.sh/issues/174

And it seems that we already have 700: https://github.com/Neilpang/acme.sh/commit/762978f8d8a7fcc7308e4b8c6e5b1cf3747014e6

Please take a look.

[nh2]

Why don't you want to use umask?

And it seems that we already have 700: 762978f

Unless I'm misunderstanding, a chmod 700 on the $LE_WORKING_DIR is not enough because not all security relevant files are stored in there.

[Neilpang]

@nh2

No, all the files are saved in LE_WORKING_DIR

[nh2]

@Neilpang This seems to be because that chmod is in the install functionality, which doesn't get executed e.g. when you run acme.sh straight from the git repository or when you wipe ~/.acme.sh and run acme.sh again. Could this be the explanation?

[Neilpang]

@nh2

Calling install command to install acme.sh is the recommended way. We don't have guarantee if you clone and run the code directly.

Otherwise, when should we call chmod ? everytime you run any command ? No, that's not reasonable. That would override the user's choice. for example: after you install acme.sh, the mod is initialized as 700, but the user may use chmod to set a customized mode, like 755 or whatever, to meet his requirement. he don't want anyone to override his choice.

[Neilpang]

@nh2 Doing more doesn't mean doing better.

[nh2]

That would override the user's choice. for example

I agree, that's why I think that umask is a good idea because it will only apply for new files, not the ones that the user chmod'ed manually.

Calling install command to install acme.sh is the recommended way

The problem with that is that it also sets up that cron job, which in some cases is not desired doesn't make sense (e.g. when the machine you're running acme.sh on is not the machien that runs e.g. the webserver). Can that be turned off?

Otherwise, when should we call chmod ? everytime you run any command ?

No, I propose the following simple logic: If ~/.acme.sh doesn't exist and acme.sh creates it in any way (with installer or without), then it should chmod 700 it. If it does exist, acme.sh should keep the permissions that the user has set.

[Neilpang]

Install without cronjob:

./acme.sh --install  --nocron

or remove the existing cronjob:

acme.sh --uninstallcronjob