Controlling Shells
 

I want to limit what a authenticated user can do on my Linux server. I've set the default shell to rbash, but I know a knowledgeable user can switch shells. Can I use file permissions to deny execution rights to /bin/bash to anyone who is not in a particular group?

And if that works, how do I find out what other shells are installed on my server (Ubuntu 9.10)? Any suggestions?

Type "man bash" then search for "RESTRICTED SHELL".

That controls a lot of things including not letting the SHELL variable change.

Unfortunately, that doesn't seem to be adequate:

-- Anton Chuvakin, Restricting UNIX Users

Does anyone know if his concerns (from 2002) have since been addressed in bash?

Hi,

It is not clear from your original post which limitations you want to put in place. What are these user allowed to do, or what are they not allowed to do?

If the authenticated user is going to be limited to a few specific tasks like: have access to a specific [log-]file(s), start (and/or stop) specific process(es), you could decide to give the user a menu with static options as a login shell.

The menu is "just" a shell script, but all the commands are restrictive/hardened. You open the specific file for him/her with rvim instead of vim for example.

But this is only relevant if the user has very restrictive and specific access.

Anyway, hope this helps.

I'm helping some high school kids prepare for a cyberdefense conmpetition. I already know the red team will crack the green team's passwords, and I want to hamstring them as much as possible. I'm using rbash as the default shell, but I know that they can break out of it. That Restricting UNIX Users article suggested using a menu-based shell such as Pdmenu, which limits the user to just the options he can pick off the menu. The article goes further to recommend combining that with a chroot. I'll play with that this weekend, but I'm running out of time...and I have to teach the kids how to manage this for the competition.

The particular server I'm concerned about will be an email server/file server, running Postfix and Samba. The Green Team users won't need to run tools on the server...just retrieve their email and use SCP/SFTP to store/retrieve their (and ONLY their) files.

I wonder if you're viewing restricting users as an afterthought instead of setting up your Ubuntu 9.10 server with the basic security features available to you. As you've seen from your previous threads on the subject security shouldn't be bolted on but incorporated as you set the system up. So while I would understand avoiding to do so for reasons of available time to you, circumventing or opting out of using basic security features available to you on an exposed system would be a mistake. As far as I'm concerned the problem starts with the question why users need a shell in the first place. If you're sure they do then the problem becomes what they can do on or to the system. Having a compiler on your exposed system is not good. Having some form of unprotected web panel around is not good. Not putting user-writable areas on a partition with mount restrictions isn't good.

Since you're running out of time I suggest you first run an assessment on the server using Tiger locally and OpenVAS from remote (add information gathering, vulnerability identification and privilege escalation from Backtrack if you've got the time) to point out quick wins, correct those, (run the test again) and only then move on to more elaborate stuff using http://www.debian.org/doc/manuals/se.../index.en.html as checklist. For Samba for instance you could block off its ports and force every user to tunnel access over SSH using public key auth(!).

unSpawn, I respect your knowledge and value your advice, but with all due respect I am not making security an afterthought. To a large degree I have very little ability to control my environment...it's set by the competition managers. For example, they sent us a list of users we need to support, and their passwords. To nobody's great surprise, every one of the passwords, when sent through a basic password quality checker, they ALL came back as "weak".

The contest rules forbid us from changing the passwords "without the permission of the White Team", so we sent a letter to the White Team asking for that permission. It was denied. To be fair, the Red Team has only 8 hours to hack over 30 different teams, and if we were able to properly secure the passwords the Red Team just wouldn't have enough time to do their job. So we have to assume the Red Team will gain access to our network via a cracked user password, and secure the network from the inside out, as well as from the outside in.

We are taking steps to do that (ipTables firewalls on all application servers, chrooting (and/or using AppArmor) on all applications, locking down the application accounts, etc. Per your question about shells, I have to assume a Red Team member will try to launch a shell. I tried setting the accounts up with noshell, but then the user account couldn't log onto the server. Since I don't think I can prevent the Red Team from logging onto a server, I want to minimize what they can do by giving them a hamstrung shell to work in.

Hence this thread.

I see. Pity you didn't drop the question earlier. Maybe then we could have helped you secure the area well enough using Apparmor profiles. Enough of the hindsight stuff though, let's see.


See PAM, /etc/pam.d/chsh, use a custom pam_listfile line: "auth required pam_listfile.so onerr=fail item=user sense=allow file=/etc/security/pam_listfile_chsh". Echo into it, one user per line, all the users account names that are allowed to change their shell.


Yes but that would be questionable in terms of access (as you've proven later on) and would be a non standard way in terms of management (and defeated by updates). As chroot and rbash are mentioned maybe see rbash+apparmor (http://blog.bodhizazen.net/linux/sha...ty-ubuntu-904/, https://apparmor.wiki.kernel.org/ind...am_apparmor.so, http://blog.bodhizazen.net/linux/how...ss-with-rbash/, http://www.symantec.com/connect/arti...ing-unix-users, http://www.linuxtopia.org/online_boo...r_bx5bml4.html, http://bodhizazen.net/aa-profiles/).


Try 'cat /etc/shells'.


Services may require a user to have an account on the machine but having a shell does not necessary mean you can't curb remote access to the shell (I mean before talking about what they do when they get in):
- You could force users to only SSH into the host and run service or shell access over a SSH tunnel. Additional benefits could be running fail2ban to pick up login failures and ban users based on that.
- In /etc/security you have some standard options to restrict for instance the amount of processes a user may run (ulimit) in limit.conf and memory to consume. (You could also restrict users to be only able to log in during the hours your crew is on site.) While setting ulimits may be tricky if lots of resources are required it would be a good way to restrict users to only run one or two processes at a time.
- Setting a shell timeout isn't going to do much in terms of security but it's annoying anyway ;-p
- Make rootsh their fixed shell (chsh) instead of /bin/sh, make it log to syslog then let fail2ban logout and ban users based on regexes (compilers n stuff)?
- Remove compilers or change DAC rights on compiler and related packages to one group they can't su to.
- Use pam_apparmor.so to restrict user access by custom profile. Probably the best way but requires time to profile, tweak away LINUX_CAPABILITIES ('man capabilities').


Not much else wrt standard features I think. HTH somehow.