I have a question about giving a shell account to somebody. How safe is it? He could read /etc. How can I give a secured shell account that will only restrict the user to some bins and his own home? Is the only way a chroot jail?
One of the most easy/efficient way to control what a user can do is lshell.
lshell is a shell coded in Python, that lets you restrict a user's environment to limited sets of commands, choose to enable/disable any command over SSH (e.g. SCP, SFTP, rsync, etc.), log user's commands, implement timing restriction, and more.
Keep in mind that parts of
/etc are required to be readable even by unprivileged users. If there are things in
/etc that shouldn't be readable but are, you have bigger issues and at minimum should run your distribution's permissions check/fix program.
A jail is the easiest way to set up draconian restrictions. There are other ways, such as setting up SElinux and arrange for the user to have a very limited security context.
If you give somebody a shell account, they can see all world-readable files. This includes many files in
/etc that are necessary for the system to work, including
/etc/passwd (which contains user names but not passwords).
If you allow the user only to log in inside a chroot, they can't see the files outside the chroot. That means you must put enough programs, libraries, etc, inside the chroot — everything the user must have access to and every dependency of these as well.
Note that a chroot only protects direct file access. The user can snoop on various things, including the names and arguments of running processes of all users (unless you set up additional protections such as SELinux). If the user isn't going to need to do much, you can set up tighter restrictions (including preventing the user from creating their own executables) with a restricted shell, but setting up a restricted shell right is very tricky, so I don't recommend it.
Nowadays, virtual machines are very cheap. You have many free implementations to choose from (User Mode Linux, VirtualBox, VMware, KVM, OpenVZ, VServer, …), and the disk space used by an extra system installation is minimal (and you might need it for chroot anyway). A virtual machine isolates pretty much everything: files, processes, networking, … Unless you have very unusual constraints, this is the way to go.
One option is to put them in a restricted shell session, such as rbash [bash -r].
It is a bit unclear at this point what, exactly, you wish to accomplish, however, on the surface posix acl's for 'other' will apply to the new account as well as any group acl's for groups to which the account belongs, such as 'users' for example.