Merge branch 'mathias-CRP-1974-add-umask-for-crypto-csp-process' into…

… 'master'

feat(crypto): CRP-1974: Add umask for crypto-csp process

Add a configuration value `UMask=066` to `ic-os/guestos/rootfs/etc/systemd/system/ic-crypto-csp.service` (similarly to what is currently done for `ic-replica.service` in the same directory). This would change the umask for all files subsequently created by the `ic-crypto-csp` vault service process.

The default `umask` value is `0o022`. The umask is taken, together with possible permissions specified at file (and directory) creation, to calculate the permissions of the new file (and directory). For files, the resulting permissions are the logical AND operation on the provided permissions and the negation of the umask. If no permissions are provided when creating a file, the resulting permissions based on the default umask are therefore `rw-r--r--`, meaning read&write permissions for the user, and read permissions for the group and other users.

Setting the umask value to `066` for the `ic-crypto-csp` process means that new files created by the process will have the permissions `(rw-------)`, i.e., read and write permissions for the user, and no permissions for the group or other users.

In practice, this change will apply to the permissions of the new versions of the secret key store file that will be written each time a new key is generated, or an old key is removed. Looking for files that belong to the user `ic-crypto-csp` reveal the following:
```
admin@zh1-spm02:~$ sudo find / -user ic-csp-vault 2>/dev/null | grep -v ^/proc
/home/ic-csp-vault
/run/ic-node/crypto-csp/socket
/var/lib/ic/crypto
/var/lib/ic/crypto/sks_data.pb
/var/lib/ic/crypto/lost+found
/var/lib/ic/crypto/canister_sks_data.pb
/var/lib/ic/crypto/public_keys.pb
```
Files under `/proc` were ignored. Out of the above, the only relevant files is `/run/ic-node/crypto-csp/socket` - this is the UNIX domain socket used to communicate between the replica and the vault. This is created ahead of time, and not re-created by the `ic-crypto-csp` vault process, so this will not be impacted by the umask change in this MR.

Tested on a testnet to verify that the `UMask=066` is added to `/etc/systemd/system/ic-crypto-csp.service`, and after enabling iDKG encryption key rotation and waiting for the SKS to be updated, the permissions are now as expected:
```
admin@zh1-spm02:~$ sudo ls -l /var/lib/ic/crypto/
total 864
drwxr-s---. 2 ic-csp-vault ic-csp-vault  16384 Apr  6 12:39 lost+found
-rw-r-----. 1 ic-csp-vault ic-csp-vault    829 Apr  6 12:39 public_keys.pb
-rw-------. 1 ic-csp-vault ic-csp-vault 861889 Apr  6 12:40 sks_data.pb
admin@zh1-spm02:~$ sudo ls -l /var/lib/ic/crypto/
total 864
drwxr-s---. 2 ic-csp-vault ic-csp-vault  16384 Apr  6 12:39 lost+found
-rw-------. 1 ic-csp-vault ic-csp-vault    877 Apr  6 12:49 public_keys.pb
-rw-------. 1 ic-csp-vault ic-csp-vault 862255 Apr  6 12:49 sks_data.pb
``` 

See merge request dfinity-lab/public/ic!11722

ic-os/guestos/rootfs/etc/systemd/system/ic-crypto-csp.service

@@ -11,6 +11,7 @@ Requires=ic-crypto-csp.socket
 StartLimitIntervalSec=0
 
 [Service]
+UMask=066
 User=ic-csp-vault
 Environment=RUST_BACKTRACE=1
 # When starting ic-crypto-csp, ideally --replica-config-file would directly point to