Restrict a Linux user to the files he owns
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.
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.
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
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.
Linux Containers (LXC) could be the best combination of chroot and separate system.
They are more like an advanced chroot, not virtualization, but you could combine different operating systems in one server.
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.