Securing circumlunar.space with bind mounts

Lately I have been spending some time preparing for "opening up"

circumlunar.space a bit, by which I mean actively soliciting new users

from the general Gopher-using public. I will probably announce the

Zaibatsu's existence on the gopher-project mailing list in the near

future. So, I have been writing scripts to automate the task of

setting up accounts, setting quotas, etc.

The general plan is that people will be offered sftp-only access to

their gopherspace, with authentication via public key only, without

shell access. Disallowing password authentication means I don't have

to worry about weak passwords getting brute forced. OpenSSH has very

nice options for enforcing sftp only access. Modern versions of sshd

have an internally-implemented version of the sftp server, which means

you can chroot users into their home directory without having to

populate it with libraries and things. I trust the OpenSSH guys to

have got this right, so I feel safe granting this kind of access to

strangers and trusting that they won't be able to get shell access

until I explicitly grant it to them (and I do plan to offer shell

access to anybody who maintains their gopherspace regularly and gives

the impression of being somebody I would like to share a server with).

The one wrinkle on this is Gophernicus' extensive CGI support. I have

never used Gopher CGI myself and am not really interest in it, but I

know a lot of phloggers use it for various things, so I don't want to

just turn it off. However, offering sftp-only access rather than

shell access is kind of pointless if somebody can upload any shell

script they like to their gopher hole, point their gopher client at it

and get Gophernicus to execute it. It's kind of like a very

circuitous shell access of its own. And, okay, Gophernicus will run

it as a low-privilege user, but I'm still not happy about this loop

hole.

At first glance, this is easy to fix. General CGI executables have to

live in a "cgi_bin" directory inside a user's gopherspace for

Gophernicus to execute them, so when I set up a user account I can

create this directory myself, chown it to root and make sure the user

has no access. My "make new user" script does this, and this

straightforwardly means people can't upload anything in there. When

they prove trustworthy and I give them shell access, I can just chown

that directory back to them and we're all good. CGI problem solved,

right?

Well, not quite. Because Gophernicus also supports executable

gophermaps. Any file named "gophermap" with the executable bit set

will be treated as a CGI file. I can't stop people doing this with

simple file permissions, because I have to let them be able to

create their own directories in their gopherhole, and as soon as they

create a directory of their own, they can put a gophermap file in it.

This stumped me for a bit. All I could think was that if each user's

gopherspace was on its own partition, I could mount them with the

noexec option and then CGI would be totally useless for them. But

giving each user their own partition would be a nightmare, and

besides, the cheap-as-chips OpenVZ VPS technology doesn't give you the

freedom to partition your own dedicated virtual disk.

I did some searching and it turned out I was thinking along the right

lines, but I was just a little bit out of date. It turns out that

these days, on Linux at least, you don't need to put stuff in its own

partition to facilitate using mount options. There's this new-fangled

thing called a "bind mount" that I'd never heard of before. I am

really thrilled that this little project is teaching me new stuff

about system administration.

A bind mount is conceptually pretty simple, it just lets you re-mount

an existing part of your filesystem at a new mountpoint. Do:

mount -o bind /home/bob /home/alice

and the contents of /home/bob will be mirrored in /home/alice. It's

kind of like a symbolic link, except that it's more transient (it

won't survive a reboot, unless you put it in /etc/fstab) and a little

more powerful because you can apply all the standard mounting options

like ro, relatime, noexec, nosuid, nodev, etc. The following:

mount -o bind,ro /home/bob /home/alice

would make /home/alice a read-only mirror of /home/bob (/home/bob

remains writable as always). Most interestingly, for the current

application, is that you can bind mount some existing location *over

the top of itself*, which basically means that you can apply those

mounting options anywhere you like on your filesystem. This:

mount -o bind,ro /home/bob /home/bob

simply makes /home/bob read-only, until umount is used to reverse

this. So, even if your entire system is installed in one big

monolithic "/" partition, as is the style these days, you can still

make any individual directory read-only or no-exec or whatever you

like. That's pretty nice!

So not only do my scripts now mount new users' gopherspaces noexec

(and remount as such after reach reboot), but I can also do standard

server hardening tricks like mounting /tmp noexec or mounting /usr ro,

despite the fact that at first glance OpenVZ doesn't give me enough

control to facilitate this.