LinuxQuestions.org
Help answer threads with 0 replies.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Server
User Name
Password
Linux - Server This forum is for the discussion of Linux Software used in a server related context.

Notices

Reply
 
Search this Thread
Old 10-19-2007, 10:43 AM   #1
helptonewbie
Member
 
Registered: Aug 2006
Location: England Somewhere
Distribution: Mandriva, PCLinuxOS, Karoshi, Suse, Redhat, Ubuntu
Posts: 518

Rep: Reputation: 39
Question How can i lock down the console to a user??


hi All,
Is it possible to lock down the console ie. a user can remote login to a server and i want to allow them to only be able to run commands i specify, i dont know if this requires the use of a jail or acl's and if it did i don't know enough about them yet to do this, so is that whats required or are there other much more simpler methods
cheers
mark
 
Old 10-19-2007, 02:04 PM   #2
unknownmosquito
Member
 
Registered: Dec 2005
Distribution: Fedora 8
Posts: 57

Rep: Reputation: 15
I did this because I wanted users to be able to run no commands -- only for port forwarding.

You could in theory write your own (very simple) shell that only has a few commands, especially if you want to limit them to just a few commands. Then just make it their default in /etc/passwd and there isn't much they can do about it, especially if it doesnt let them run other shells.

Another option is putting the user in a group that cannot access /bin/ or /usr/bin (as necessary), except for those few commands you want, which you could copy into a separate folder with read privileges for the user. (/usr/unlucky/bin)

Either way it seems tricky and like a lot of work.. I'm sure there are better ways but those are the two that come to mind. I wrote a shell that basically told them to go fly a kite if they typed anything. And it let them exit. Took about an hour to write in Python.
 
Old 10-19-2007, 02:30 PM   #3
helptonewbie
Member
 
Registered: Aug 2006
Location: England Somewhere
Distribution: Mandriva, PCLinuxOS, Karoshi, Suse, Redhat, Ubuntu
Posts: 518

Original Poster
Rep: Reputation: 39
Yes i basically want to do the same thing, no way i can write my own shell wouldn't know where to start nice idea though. Still i would have thought there is a simpler way, but maybe not? Yea the other method you talk about is something i looked into but i think its just easier if you didn't need to start changing system files permissions i don't see that as a great thing.

Thanks for the reply, any other ideas peeps?
 
Old 10-19-2007, 02:56 PM   #4
unknownmosquito
Member
 
Registered: Dec 2005
Distribution: Fedora 8
Posts: 57

Rep: Reputation: 15
Not to be over-persistent, but writing your own shell is simply an infinite while loop waiting for user input ; )

This is mine:

Code:
#!/usr/bin/python

print "Welcome!\n
This is a dummy shell. Do not expect it to do anything useful.\n
Type exit to quit."

command = ""

while (command != "exit"):
 command = raw_input("[username@localhost]$ ")
 if (command != "") and (command != "exit") :
  print "I "+command+"ed your mother last night."
then just chmod +x filename.py

and then change their default shell to it.
Pretty simple really : P

If nothing else pans out, give it a shot.

Last edited by unknownmosquito; 10-19-2007 at 02:59 PM.
 
Old 10-19-2007, 04:53 PM   #5
helptonewbie
Member
 
Registered: Aug 2006
Location: England Somewhere
Distribution: Mandriva, PCLinuxOS, Karoshi, Suse, Redhat, Ubuntu
Posts: 518

Original Poster
Rep: Reputation: 39
hey that looks good to me, i've tried it and tried to add in
import commands
commands.getoutput

or something similar not totally sure found a website to try and help me, so i want to say type in cat /file and get the output and allow no other command apart from the command != "" and command != "exit"

Can you help me out on that if you know it?
 
Old 10-21-2007, 05:45 AM   #6
Nihil
LQ Newbie
 
Registered: Mar 2007
Location: Israel
Distribution: Gentoo,FC,CenOS,BackTrack2,DSL
Posts: 10

Rep: Reputation: 0
Wait a sec.. I think writing your own shell is a bit extreme...

Perhaps a simpler solution will be to delete commands you dont want the user to run from
/usr/bin ..

just login as the user you weant to block and find the executable of the command you want to block, like `which ifconfig` , then delete the file..

and don't forget to deny his permissions to /sbin /usr/sbin.
 
Old 10-21-2007, 05:58 AM   #7
helptonewbie
Member
 
Registered: Aug 2006
Location: England Somewhere
Distribution: Mandriva, PCLinuxOS, Karoshi, Suse, Redhat, Ubuntu
Posts: 518

Original Poster
Rep: Reputation: 39
Not a great idea, other users should be allowed to run the commands, is there a way i can say instead just copy the commands i want the user to be able to run put them in their home directory or something then make it so they can only access commands inside their home directory? nope i dont think thats possible, i never knew this would be such a difficult task thought people would be doing it all the time???

I'd rather not be deleting commands just stopping what commands people can access, then when the user types a command to look into the list of allowed commands or something and then if ok run it if not stop it and perhaps log it as well, a new shell seems like a good idea but i sure can't make one
 
Old 10-21-2007, 10:32 AM   #8
tkharris
LQ Newbie
 
Registered: Oct 2007
Location: The State Of Nuts and Fruits
Distribution: Debian
Posts: 5

Rep: Reputation: 0
Problems With Writing Your Own Shell

I just wanted to bring up that there are a lot of problems with using a shell as a lock down.

Here are a few examples:

Connecting to your server I use `ssh user@host /bin/bash` - I've bypassed your shell.

Connecting to your server I use `ssh user@host chsh` - I've just overwritten your changes to /etc/passwd and now have the shell of my choice.

If you allow me to run vim I can !command, irssi I can /exec command. Writing your own shell is only an option if you're preventing users from doing stupid things; it's not a viable security solution.

You're better off looking into chrooting the user, and that's project within itself. Bottom line: If you think a user is going to abuse his or her shell they shouldn't have been given one.
 
Old 10-21-2007, 11:39 AM   #9
helptonewbie
Member
 
Registered: Aug 2006
Location: England Somewhere
Distribution: Mandriva, PCLinuxOS, Karoshi, Suse, Redhat, Ubuntu
Posts: 518

Original Poster
Rep: Reputation: 39
thanks, TKHARRIS, that is some great information you've provided there i didn't know you could ssh and pick your own shell etc, so good to know
thanks
 
Old 10-21-2007, 01:05 PM   #10
anomie
Senior Member
 
Registered: Nov 2004
Location: Texas
Distribution: RHEL, Scientific Linux, Debian, Fedora, Lubuntu, FreeBSD
Posts: 3,930
Blog Entries: 5

Rep: Reputation: Disabled
Quote:
Originally Posted by tkharris
You're better off looking into chrooting the user, and that's project within itself. Bottom line: If you think a user is going to abuse his or her shell they shouldn't have been given one.
Agree 100%. But I'll see your 'chroot' and raise you 'FBSD jail'. I believe in the GNU/Linux world, functionally equivalent capabilities exist in the form of a Linux-VServer.

And, yes, that's a complex topic in of itself.
 
Old 10-22-2007, 08:41 AM   #11
helptonewbie
Member
 
Registered: Aug 2006
Location: England Somewhere
Distribution: Mandriva, PCLinuxOS, Karoshi, Suse, Redhat, Ubuntu
Posts: 518

Original Poster
Rep: Reputation: 39
hello, at least we're getting somewhere as there doesn't seem to be any real sources on the internet anywhere not that i could find anyway, and still looking. Hows about maybe locking down the /usr/bin /sbin etc etc etc to alow the onwer and group, then allow in others only via acl's? seems like a reasonable alternative, but would require extra administration anytime a change needed to be made, or could set-up several groups gives users the selected groups that in turn locks access down to the bin's and executables they could run as well. Is that a feasiable possibility?
 
Old 10-22-2007, 01:21 PM   #12
anomie
Senior Member
 
Registered: Nov 2004
Location: Texas
Distribution: RHEL, Scientific Linux, Debian, Fedora, Lubuntu, FreeBSD
Posts: 3,930
Blog Entries: 5

Rep: Reputation: Disabled
If I were tasked with this, I think what I would do is:
  1. Create a VServer instance or virtualized (Xen?) guest; this is the only "OS" the users will have shell access to.
  2. Within the virtualized instance only, recursively change filesystem permissions on all binaries in: /bin, /lib, /sbin, /usr, /usr/bin, /usr/sbin, /usr/lib, /usr/local/bin, /usr/local/lib, and /usr/local/sbin such that root owns them and has the needed r(w)x access, and no one else has any access.
  3. Within the virtualized instance, create all the required shell accounts. Add them to a group 'shellusers'. Modify group ownership/permissions for only the required binaries in the paths listed above that they should have access to (i.e. give 'shellusers' access). You'll need to use ldd to determine which shared objects to include with your permissions changes.
  4. Test with a shell account in the 'shellusers' group and confirm that things are working as you'd expect. Once this is done, take a backup from the host OS of your virtualized instance. (This backup will come in handy when some clever user runs amok and finds a way to exploit the situation in spite of your best efforts. Joke's on him when you can blow it all away, patch it, and start fresh.)

But that's just me. There are probably several ways to solve this problem - some lousy solutions, and some reasonably secure solutions. Any way you slice it, a solution in the latter category is going to require a non-trivial amount of work and testing.

Last edited by anomie; 10-22-2007 at 01:24 PM.
 
Old 10-22-2007, 07:45 PM   #13
tkharris
LQ Newbie
 
Registered: Oct 2007
Location: The State Of Nuts and Fruits
Distribution: Debian
Posts: 5

Rep: Reputation: 0
anomie:

That's pretty much along the lines of the same thing I'd do. I don't think I'd be disabling the various applications and scripts in /bin/ and /usr/bin, simply because the user's now can't mess the server up, only their little part of it. I must admit that outside webhosting's resource reasons for VPSs the only reason I'd set one up would be in a hostile environment where the user's may try to use local exploits.

I see your FreeBSD Jail, and pull out my ace in the hole - OpenBSD Jails!

On that note chroot's/jails are a pain in the ass and I'd rather just deluser instead of setting all that crap up.
 
  


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


Similar Threads
Thread Thread Starter Forum Replies Last Post
Virtual Console/X Lock. SticklerThe1st Linux - Hardware 4 07-05-2010 11:50 AM
screen lock for virtual console cad Linux - General 2 02-18-2007 11:13 AM
Console problems, RPM cannot create due to transaction lock??? fueldistributa Linux - Newbie 3 12-20-2005 05:35 PM
Lock console? KaktusKnight Linux - General 30 12-20-2002 04:20 AM
How to lock Vritual Console ?? hitesh_linux Linux - General 4 12-07-2002 12:53 AM


All times are GMT -5. The time now is 11:31 PM.

Main Menu
Advertisement
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