How can i lock down the console to a user??

helptonewbie · 10-19-2007, 09:43 AM

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

unknownmosquito · 10-19-2007, 01:04 PM

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.

helptonewbie · 10-19-2007, 01:30 PM

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?

unknownmosquito · 10-19-2007, 01:56 PM

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.

helptonewbie · 10-19-2007, 03:53 PM

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?

Nihil · 10-21-2007, 04:45 AM

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.

helptonewbie · 10-21-2007, 04:58 AM

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

tkharris · 10-21-2007, 09:32 AM

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.

helptonewbie · 10-21-2007, 10:39 AM

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

anomie · 10-21-2007, 12:05 PM

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.

helptonewbie · 10-22-2007, 07:41 AM

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?

anomie · 10-22-2007, 12:21 PM

If I were tasked with this, I think what I would do is:

Create a VServer instance or virtualized (Xen?) guest; this is the only "OS" the users will have shell access to.
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.
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.
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.

tkharris · 10-22-2007, 06:45 PM

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.