Restrict a Linux user to the files he owns

Question

Imagine a server setup of a shared webhosting company where multiple (~100) customers have shell access to a single server.

A lot of web "software" recommends to chmod files 0777. I'm nervous about our customers unwisely following these tutorials, opening up their files to our other customers. (I'm certainly not using cmod 0777 needlessly myself!) Is there a method to make sure that customers can only access their own files and prevent them from accessing world readable files from other users?

I looked into AppArmor, but that is very tightly coupled to a process, which seems to fail in that environment.

Answer 1

Put a restricted and immutable directory between the outside world and the protected files, e.g.

/
 ├─ bin
 ├─ home
 │  └─ joe <===== restricted and immutable
 │     └─ joe <== regular home directory

or /home/joe/restricted/public_html.

Restricted means that only the user and perhaps the web server can read it (e.g. modes 0700/0750 or some ACLs).

Immutability can be done with chattr +i or by changing the ownership to something like root:joe.

An easy way to create that hierarchy on Ubuntu would be to edit /etc/adduser.conf and set GROUPHOMES to yes.

Answer 2

There is an option which you might want to consider (depending how much work you want to do for that).

As others already posted, "normally" you cannot prevent someone with shell access to read world-readable files.

However you could chroot them into their own home, basically limiting the shell access to, first, only the root directory you want (AKA the home directory) and, second, prevent the users from executing everything you do not want them to execute.

I did a similiar approach when I had one user to have access to the webfiles, but I did not want to have him seeing other files outside the webfolder.

This did have a lot of overhead, was a mess to setup, and every time I updated something, it broke.

But for today I think you could achieve it pretty easy with the OpenSSH chroot option:

WikiBooks OpenSSH

Answer 3

I have found POSIX Access Control Lists allow as you, as the system administrator, to protect your users from the worst of their own ignorance, by overriding the regular user-group-other file system permission, without much of a chance to break anything crucial.

They can be especially useful if you for instance (f.i.) needed home directories to be world accessible because webcontent needs to be accessible for apache in ~/public_html/. (Although with ACL's you can now do the reverse, remove access for all and use a specific effective ACL for the apache user. )

Yes, a knowledgeable user can remove/override them again, are just uncommon enough that that's unlikely, and those users that can are typically not the ones to conveniently chmod -R 777 ~/ anyway, right?

You need to mount the filesystem with the acl mount option:

 mount -o remount,acl /home

In many distributions the default is to create user groups, each user has their primary group, and I have set all users in a secondary group with the unimaginative name of users.

Using ACL's it is now trivial to prevent other users from accessing the home directories:

Before:

 chmod 0777 /home/user* 

 ls -l /home/user*
 drwxrwxrwx.  2 user1  user1  4096 Jul 11 15:40 user1
 drwxrwxrwx.  2 user2  user2  4096 Jul 11 15:24 user2

Now set the effective directory permissions for members of the users group to 0 no read, write or access:

 setfacl setfacl -m g:users:0 /home/user*

 ls -l 
 drwxrwxrwx+  2 user1  user1  4096 Jul 11 15:40 user1
 drwxrwxrwx+  2 user2  user2  4096 Jul 11 15:24 user2

The + sign denotes the presence of ACL settings there. And the getfacl can confirm that:

getfacl /home/user1
getfacl: Removing leading '/' from absolute path names
# file: home/user1
# owner: user1
# group: user1
user::rwx
group::rwx
group:users:---
mask::rwx
other::rwx

The group:users:--- show that group effectively having no access right, despite the regular permissions for other being other::rwx

And testing as user1 :

[user1@access ~]$ ls -la /home/user2
ls: cannot open directory /home/user2: Permission denied

---

A second common solution on shared systems is to have the automounter mount home directories on demand an a server dedicated to shell access. That's far from fool proof, but typically only a handful of users will be logged in concurrently meaning only the home directories of those users are visible and accessible.

Answer 4

For example, if you want user to have access only to his own home directory, you should do:

cd /home
sudo chmod 700 *

Now /home/username is only visible to its owner. To make this the default for all new users, edit /etc/adduser.conf and set DIR_MODE to 0700 instead of the 0755 default.

Of course if you want to alter the default DIR_MODE it depends on your distribution, the one I posted works on Ubuntu.

edit

As @Dani_l correctly mentioned, this answer is correct in making them NOT world readable.

Answer 5

Linux Containers (LXC) could be the best combination of chroot and separate system.

1. They are more like an advanced chroot, not virtualization, but you could combine different operating systems in one server.

2. You can give an user a complete operating system and chroot him there, so when the user logs in, he goes to his container. And you can also limit processor and memory usage there.

Stéphane Graber, the author of LXC, has a nice tutorial to help you get started.

Answer 6

Just to be pedantic - No, there isn't.
@Marek gave a correct answer, but your question is incorrect - you can't prevent anyone from accessing "world readable" files.
Either they are world readable, or they are not. @Marek's answer is correct in making them NOT world readable.

Answer 7

I see no mention of the 'restricted shell' in the answers given so far.

ln /bin/bash /bin/rbash

Set this as their login shell.

Answer 8

If the web server is running as the same user and group for every domain hosted, it is difficult (if not impossible) to make the setup secure.

You want certain files to be accessible to the user as well as the web server, but not to other users. But as soon as the web server can access them, another user could read them by putting a symlink to the file inside their own web site.

If you can get each web site to run as a separate user, then it becomes fairly simple. Each customer will now have two users on the system, one for the web server and one for shell access.

Create a group containing these two users. Now create a directory with that group and user root. That directory should have permissions 750, which means root has full access and group has read and execute access. Inside that directory you can create home directories for each of the two users. This means the user's home directory will no longer have the form /home/username, but rather something with at least one more directory component. This is not a problem, nothing requires home directories to be named according to that specific convention.

Getting web sites running with different user and group may be tricky, if you are using name based vhosts. Should it turn out that you can only make the separation work with IP based vhosts, and you don't have enough IPs for each site, you can host each web site on an IPv6 address and put a reverse proxy for all of them on an IPv4 address.