Linux - ServerThis forum is for the discussion of Linux Software used in a server related context.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
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
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.
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.
Not to be over-persistent, but writing your own shell is simply an infinite while loop waiting for user input ; )
This is mine:
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 01:59 PM.
hey that looks good to me, i've tried it and tried to add in
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"
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
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?
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.
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.