LinuxQuestions.org
Visit the LQ Articles and Editorials section
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Security
User Name
Password
Linux - Security This forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.

Notices

Reply
 
LinkBack Search this Thread
Old 04-16-2010, 11:34 AM   #1
Jim Bengtson
Member
 
Registered: Feb 2009
Location: Iowa
Distribution: Ubuntu 9.10
Posts: 164

Rep: Reputation: 38
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?
 
Old 04-16-2010, 12:13 PM   #2
MensaWater
Guru
 
Registered: May 2005
Location: Atlanta Georgia USA
Distribution: Redhat (RHEL), CentOS, Fedora, Debian, FreeBSD, HP-UX, Solaris, SCO
Posts: 5,770
Blog Entries: 4

Rep: Reputation: 697Reputation: 697Reputation: 697Reputation: 697Reputation: 697Reputation: 697
Type "man bash" then search for "RESTRICTED SHELL".

That controls a lot of things including not letting the SHELL variable change.
 
Old 04-16-2010, 01:18 PM   #3
Jim Bengtson
Member
 
Registered: Feb 2009
Location: Iowa
Distribution: Ubuntu 9.10
Posts: 164

Original Poster
Rep: Reputation: 38
Quote:
Originally Posted by MensaWater View Post
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:

Quote:
"First, letís look at the restricted shell. There are simply too many ways things can go wrong: modifying environment variables (such as EDITOR, VISUAL, and others unlocked by rbash), starting applications with shell escapes, changing user's shell, simply running the downloaded shell binary and numerous other methods can let the bird fly out of the cage."
-- Anton Chuvakin, Restricting UNIX Users

Does anyone know if his concerns (from 2002) have since been addressed in bash?
 
Old 04-16-2010, 01:42 PM   #4
druuna
LQ Veteran
 
Registered: Sep 2003
Posts: 10,532
Blog Entries: 7

Rep: Reputation: 2371Reputation: 2371Reputation: 2371Reputation: 2371Reputation: 2371Reputation: 2371Reputation: 2371Reputation: 2371Reputation: 2371Reputation: 2371Reputation: 2371
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.
 
Old 04-16-2010, 02:54 PM   #5
Jim Bengtson
Member
 
Registered: Feb 2009
Location: Iowa
Distribution: Ubuntu 9.10
Posts: 164

Original Poster
Rep: Reputation: 38
Quote:
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?
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.

Last edited by Jim Bengtson; 04-16-2010 at 03:15 PM. Reason: Forgot to mention purpose of server
 
Old 04-17-2010, 04:02 AM   #6
unSpawn
Moderator
 
Registered: May 2001
Posts: 26,534
Blog Entries: 51

Rep: Reputation: 2604Reputation: 2604Reputation: 2604Reputation: 2604Reputation: 2604Reputation: 2604Reputation: 2604Reputation: 2604Reputation: 2604Reputation: 2604Reputation: 2604
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(!).
 
1 members found this post helpful.
Old 04-19-2010, 09:25 AM   #7
Jim Bengtson
Member
 
Registered: Feb 2009
Location: Iowa
Distribution: Ubuntu 9.10
Posts: 164

Original Poster
Rep: Reputation: 38
Quote:
Originally Posted by unSpawn View Post
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.
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.
 
Old 04-20-2010, 05:23 PM   #8
unSpawn
Moderator
 
Registered: May 2001
Posts: 26,534
Blog Entries: 51

Rep: Reputation: 2604Reputation: 2604Reputation: 2604Reputation: 2604Reputation: 2604Reputation: 2604Reputation: 2604Reputation: 2604Reputation: 2604Reputation: 2604Reputation: 2604
Quote:
Originally Posted by Jim Bengtson View Post
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".
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.


Quote:
Originally Posted by Jim Bengtson View Post
I've set the default shell to rbash, but I know a knowledgeable user can switch shells.
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.


Quote:
Originally Posted by Jim Bengtson View Post
Can I use file permissions to deny execution rights to /bin/bash to anyone who is not in a particular group?
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/).


Quote:
Originally Posted by Jim Bengtson View Post
And if that works, how do I find out what other shells are installed on my server (Ubuntu 9.10)? Any suggestions?
Try 'cat /etc/shells'.


Quote:
Originally Posted by Jim Bengtson View Post
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 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.
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.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Trackbacks are Off
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
shells? sycamorex Linux - Software 3 11-14-2008 01:15 AM
help on the different shells... JoannesX Programming 2 02-06-2005 11:07 AM
do I need all the shells? helpme0904 Fedora 6 10-01-2004 02:03 PM
Why so many shells? linuxzouk Linux - Newbie 5 06-10-2004 07:36 AM
Shells andrewtc Linux - Newbie 3 05-01-2003 03:52 PM


All times are GMT -5. The time now is 11:32 AM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration