I might have a general problem understanding the security concept in Linux.
So the situation is that I have set up a password for redis in the redis config file and in the nginx config so that not everyone can read the db. Now the redis config file has permissions allowing everyone to read it. So that seems kind of useless. Now I can not reboot because redis won’t stop unless I pass it the password in the init.d script which again has the permissions for others to read. In general I do not like the idea having passwords unencrypted in config files. This might be less of a problem for the nextcloud config file because only root can read it (still feels awkward) but the other config files which need to be read by others totally irritate me.
So how is having passwords in clear text being able to be read by everyone supposed to be secure and if it is not, how can I configure it to be secure?
Also I would really appreciate an extension of the docs to describe how to secure the infrastructure around nextcloud (like redis).
I’m curious what you mean by, Linux? Generally speaking PHP software software such as Nextcloud is web server and PHP dependent. The underlying operating system has little impact.
Nextcloud is a PHP application. None of it should be owned by root. The files should be owned by the PHP user. Sometimes depending on the setup, this may be the web server user instead.
It’s not. The configuration files should not be readable by everybody. In general, the ownership and permissions should be set so that only the user Redis is running under can read it.
You have mentioned Redis, but not how you have configured the web server (Nginx, Apache?), the php processing (PHP-FPM, Mod_PHP, Other FastCGI?), or any other aspects of your system.
Securing the infrastructure around Nextcloud, or any PHP application is very dependent on how you set things up, and how you plan to manage it.
That means nginx, php-fpm, apcu, fastcgi, redis, letsencrypt, mariadb
But if I want to be able to reboot my system, I have to make it readable for… No idea. The system has to be able to shut down redis and for this it has to access the init.d script with the password, which is o+r by default.
Here is why I need to have a password in the init.d script:
I think your security concerns are valid, but the issues you listed seem to be specific to how Ubuntu is setup to do things. My knowledge of Ubuntu is quite limited, so I’m afraid my advice would lead you in the wrong direction.
Hopefully somebody with more pertinent experience can step in here.
I prefer to have passwords in extra files with root user and 600 access rights. But I don’t know anything about your redis situation. In general I would try to make the init script only readable by root, I don’t see the harm (and it is easily changed back)
About unencrypted passwords: how would you want to encrypt it so that it can start automatically? With an encryption key that you have lying around in the file system unencrypted? To make stuff happen automatically, you need the passwords. Just make sure they aren’t readable by unauthorized accounts.
Well, user passwords in Linux for example are usually salted and hashed. I tried changing the init.d script permissions to be read by root only but that didn’t work.
The first step would be to connect to redis through a socket that no direct connection via network is possible (or bind it to localhost). If you use a cluster of servers and you share a redis-cache, the password could make sense, however it doesn’t use encrypted connections. So it’s probably only recommended if the servers have a private network for an interconnect. http://redis.io/topics/security
Sure user passwords can be hashed. But think about what the system needs them for: It only needs to check if the supplied password is correct. Never could your Linux use the data in passwd (or rather shadow) to login into another system with the password.