in rbash try: echo `
you can chgrp binaries and remove a user's permission to run them. Of course they can install their own binaries.
This can be prevented by disallowing write access to the $PATH and protecting $PATH via rbash (same as bash --restricted)
Mounting /home noexec won't work either.
at least as long as the dyna linker is runnable :)
You can try something like restricted shell, just make sure the user can't chsh to something else. As for bash and --restricted that's kind of useless (as someone mentioned you just need to spawn another bash).
No, this can be prevented. The rbash is designed to work, those people are not such silly :) But it's non-trivial to set up. If the user is not allowed to launch /bin/bash, then take of that path of the $PATH. Use /home/bin or so. Of course drop rbash to /home/bin only. Be really carefull with the tools. Do not allow any complex thing (no ftp and so). Only cat and such things. No perl, no awk and so on. Well, finally you must ask if there are tools left to work with :) * Ray Dillinger wrote on Mon, Oct 01, 2001 at 11:01 -0700:
That works, but it only stops honest users. A dishonest user will just put equivalent commands in his/her own /bin directory
See bash man page. The user cannot launch own binaries: steffen@dx:~ > rbash steffen@dx:~ > ./x.pl rbash: ./x.pl: restricted: cannot specify `/' in command names steffen@dx:~ > export PATH=. rbash: PATH: readonly variable steffen@dx:~ > cd .. rbash: cd: restricted But of course, you have to set up it correctly like all other things. I set up such an environment, but users cannot do much useful things... :)
and ignore the fact that s/he is denied access to the ones everyone else uses.
But not with rbash :) oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel. -- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com