0

I've locked down my CentOS web server so root can't SSH in. My website directories, and files are owned by root. So when I upload files, it's a two step process. I upload them with WinSCP to my /home directory. Then I SSH in and move the files to where they need to be.

Is there a better way to do this? Should website files be owned by a non-root user?

In looking at other questions, this one seems to indicate that I should make my user part of a webusers group, and that group own all the website files. Is this the typical situation? Are there any issues with this securitywise?

1

tl;dr: root:root rwxr-xr-x, unless you need write access to the directory, in which case root:www-data rwxrwxr-x, unless you need to protect secrets (e.g. database passwords) in the web directory, in which case root:www-data rwxr-x---, unless you need write access and you need to protect secrets, in which case root:www-data rwxrwx---.

Yes, ideally, your website files should be owned by root. This is because of the principal of least privilege: with regards to permissions, root can do anything anyway, so having something owned by root doesn't really confer any additional privileges on root - it merely takes away privileges from other accounts. This is a Good Thing™.

In case you don't know what the principal of least privilege is, it's basically: give processes the bare minimum permissions they need, and no more, because you want to limit the damage if and when the process gets pwd and the attacker gets to play with whatever shiny new permissions he's just inherited from the pwd process. This is the motivation for SELinux, daemons having the ability to drop privileges, Linux capabilities, chroot jails1 - all of these things are designed to limit the damage a process can do should it get taken over by an attacker.

In the typical scenario, you want everyone to have read privileges and give only root write privileges. In this scenario, whether or not you set your web directory to be owned by the www-data2 group doesn't actually matter, because it's going to get r-x permissions either way.

There are more complicated scenarios, though, that require you to differentiate what Apache gets access to, and what the mere humans poking around the directory tree get access to. This is where the www-data-as-group thing comes in. It lets you e.g. grant write permission for Apache, but not for regular users. Or if you e.g. need to protect database passwords, then you can deny everyone read permissions, but still let Apache see the contents.

1: this is a slight misrepresentation. The chroot() system call was actually never designed as a security feature, and chroot jails were invented after chroot() originally appeared. Because of this, they have some limitations - e.g., if you're root, you can break out of a chroot jail. Same thing applies to Linux containers (Docker, systemd-nspawn, I'm looking at you). Things like BSD jails and Solaris Zones basically took the concept of chroot jails and made them actually work securely - so that barring kernel security vulnerabilities, you e.g. cannot break out of a BSD jail, even if you are root inside it.

2: the webserver's group name may vary distribution-to-distribution. It's www-data on Debian and derivatives, but I don't know about what the RHEL family does.

0

I can quickly think of at least two reasons to not have your website's content owned by root:

  • Some tools like suexec are designed to run scripts and the like under the user that owns the file. If you're not using that then you should not have it turned on, and furthermore I believe suexec refuses to run things under the privileges of special users like root, but as a defense in depth, you should not have the files owned by root in the first place.
  • You need root access in order to maintain the web site. There is no need to make maintaining the web site require any more privileges than you have to. Becoming root every time you maintain the web site increases the exposure of the root account and increases the potential for accidental damage you can inflict by making a mistake while you are maintaining the web site.
  • anyone who is enough of an expert to use suexec should know not to run stuff as root. – strugee Jan 19 '15 at 7:50
0

Denying root login is a good decision, root is a popular target in brute-force ssh attacks.

Root seems an ususual choice for owner of the web content, I use an ordinary user account. Where the development work is shared a webdeveloper group makes sense, where there is only a single developer, or the developer account is shared among several developers there is no need for a special group. .

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.