Mike Hernandez <[EMAIL PROTECTED]> wrote: > Work with means using various programs like vim or emacs or sed, etc > to manipulate the files. And yes you need the binaries and their > associated libraries for each program you want a jailed user to be > able to run. You don't need an entire OS made available to you in > order to have some sort of useful experience with a shell account. For > many people a shell account is just that... access to bash, or zsh, > etc. and basic system utils. Maybe lynx... maybe mutt.
And this protects you against what exactly? If you are worried about local exploits through setuid binaries, then change their permissions so users can't execute them. If you are worried about local exploits through kernel bugs, then you still need to worry anyways. > What it does is allow you to give users access to a shell where they > can experiment with their own files but not the files of the machine > running the shells. This is the point of chrooting any running > program. In the case of a shell it's just the shell binary running in > the chroot as opposed to httpd or mysqld, etc. Users already can't experiment with system files, that's what permissions are for. And the point of chrooting a program is not to hide files you don't want people to see, its to give an attacker who exploits the program an empty chroot where they can't do anything, like upload or create a binary to exploit a kernel vulnerability. If your chroot contains a shell and a way for me to upload or download files, then it doesn't serve any purpose at all. > It's a useful idea in some scenarios, in others it's not. Right, and "providing shell accounts" is in the not category. Adam
