You are not logged in.
Pages: 1
Recently I installed Arch Linux for (nearly) the first time in order to self-host a website. So far I’ve managed to get everything working: I now have a static nginx webserver set up, which does indeed respond to requests from outside with the correct HTML pages.
However, to add an extra layer of security, I decided to set up nginx within a chroot jail. After some hiccoughs this seems to be working now, but I’m still not quite sure how I will administer this webserver in the future. Specifically:
As per the documentation in the Wiki, whenever I update nginx, I need to manually copy the changed files back into the chroot jail. However, as far as I can see, pacman does not give me any convenient way of seeing precisely what has changed in an update. In that case, how do I know which files to copy over?
Logs currently go to a location within the chroot jail. However, when I installed Arch, I created a separate partition specifically for logs (mounted to /var/log, of course). Is there any way to place the logs from nginx in this dedicated partition, with the other log files, or would that be impossible without breaking the security of the jail?
The site itself (as in, the raw HTML files that are served) is currently located in a directory within the chroot jail, so that nginx can have easy access to it. Is this accepted practice? If not, what is recommended?
Offline
Chroot is not a security feature of Linux and not secure for such purposes (see e.g. https://www.redhat.com/en/blog/chroot-security-feature). There are proper container technologies like systemd-nspawn (https://wiki.archlinux.org/title/Systemd-nspawn) or lxc (https://wiki.archlinux.org/title/Linux_Containers) available.
1. If you update your applications in the container, you should get all new files in place.
2. With e.g. systemd-nspawn, you can just bind a directory to the container (https://www.freedesktop.org/software/sy … ml#--bind=). With chroot you can bind mount any folder manually.
3. As opposed to what? Your webserver usually needs access to the data it serves.
Last edited by null (2022-05-07 14:26:11)
Offline
Chroot is not a security feature of Linux and not secure for such purposes (see e.g. https://www.redhat.com/en/blog/chroot-security-feature). There are proper container technologies like systemd-nspawn (https://wiki.archlinux.org/title/Systemd-nspawn) or lxc (https://wiki.archlinux.org/title/Linux_Containers) available.
I am aware of this already. However, I assumed that by copying only the files required by nginx into the chroot (following the instructions in the Wiki), I could harden it somewhat, and make it just a bit more difficult for an attacker to get out of the jail.
1. If you update your applications in the container, you should get all new files in place.
Except that I followed the instructions linked above and manually copied everything over, so I can’t directly update the applications in the container — at least as far as I’m aware; I could easily be missing something here.
2. […] With chroot you can bind mount any folder manually.
Could you explain how to do this? I was under the impression that a chroot will include the contents of one specific directory, but nothing outside that directory.
3. As opposed to what? Your webserver usually needs access to the data it serves.
As opposed to, say, placing this data in my home directory, as I was doing previously. (I don’t even know if it makes a difference; it just intuitively seems to me that it should be ‘easier’ to manage files in my home directory than to manage files in /usr/srv/path/to/my/data/.)
Last edited by bradrn (2022-05-08 05:38:59)
Offline
I am aware of this already. However, I assumed that by copying only the files required by nginx into the chroot (following the instructions in the Wiki), I could harden it somewhat, and make it just a bit more difficult for an attacker to get out of the jail.
But then why use a security wise worse technology if a more secure, similarly lightweight and well documented solution is available. Using one of the mentioned container technologies instead shouldn't be much more difficult.
Except that I followed the instructions linked above and manually copied everything over, so I can’t directly update the applications in the container — at least as far as I’m aware; I could easily be missing something here.
You didn't link any instructions. I assume, you mean https://wiki.archlinux.org/title/Chroot ?
How did you set up the chroot? And how did you install nginx in there? The wiki article doesn't get into this.
Could you explain how to do this? I was under the impression that a chroot will include the contents of one specific directory, but nothing outside that directory.
You can do whatever you want from outside the chroot. So just use `mount --bind` (see mount(8)) to make more folders available.
As opposed to, say, placing this data in my home directory, as I was doing previously. (I don’t even know if it makes a difference; it just intuitively seems to me that it should be ‘easier’ to manage files in my home directory than to manage files in /usr/srv/path/to/my/data/.)
It doesn't really matter, where the data rests, but rather which permissions anyone has. An webserver should have the least necessary permissions on these files to do its job. `/srv/` is the somewhat default place to store server payload (see file-hierarchy(7)).
Offline
bradrn wrote:I am aware of this already. However, I assumed that by copying only the files required by nginx into the chroot (following the instructions in the Wiki), I could harden it somewhat, and make it just a bit more difficult for an attacker to get out of the jail.
But then why use a security wise worse technology if a more secure, similarly lightweight and well documented solution is available. Using one of the mentioned container technologies instead shouldn't be much more difficult.
Sorry, I was a bit unclear. What I was aware of was ‘that chroot is not a security feature of Linux’. However, I was not previously aware of the mentioned container technologies. Perhaps I should look into them.
Except that I followed the instructions linked above and manually copied everything over, so I can’t directly update the applications in the container — at least as far as I’m aware; I could easily be missing something here.
You didn't link any instructions. I assume, you mean https://wiki.archlinux.org/title/Chroot ?
How did you set up the chroot? And how did you install nginx in there? The wiki article doesn't get into this.
I meant these instructions, which I did link: https://wiki.archlinux.org/title/Nginx# … n_a_chroot
Could you explain how to do this? I was under the impression that a chroot will include the contents of one specific directory, but nothing outside that directory.
You can do whatever you want from outside the chroot. So just use `mount --bind` (see mount(8)) to make more folders available.
I’ll check it out, thanks!
EDIT: Yep, `mount --bind` looks like exactly what I was looking for. I was worried that it might be possible to do something clever with `..` to escape the chroot, but this doesn’t look like it’ll be an issue with `mount --bind`.
As opposed to, say, placing this data in my home directory, as I was doing previously. (I don’t even know if it makes a difference; it just intuitively seems to me that it should be ‘easier’ to manage files in my home directory than to manage files in /usr/srv/path/to/my/data/.)
It doesn't really matter, where the data rests, but rather which permissions anyone has. An webserver should have the least necessary permissions on these files to do its job. `/srv/` is the somewhat default place to store server payload (see file-hierarchy(7)).
OK, thanks for clarifying!
Last edited by bradrn (2022-05-09 11:30:54)
Offline
You didn't link any instructions. I assume, you mean https://wiki.archlinux.org/title/Chroot ?
How did you set up the chroot? And how did you install nginx in there? The wiki article doesn't get into this.I meant these instructions, which I did link: https://wiki.archlinux.org/title/Nginx# … n_a_chroot
Sorry, I was looking for the link in your first post.
If you want to do it like this, I would just create a pacman hook, copying all relevant files after each update. Should be fast enough.
Offline
If you want to do it like this, I would just create a pacman hook, copying all relevant files after each update. Should be fast enough.
Huh — I had no idea pacman could do this. I shall write such a hook as soon as I get time.
Last edited by bradrn (2022-05-09 11:49:35)
Offline
Pages: 1