Re: chroot ssh and ftp
Dr Beco <rcb@beco.cc> wrote:
> It's weird though to have a student [...] see his files owned by him,
> and group professor, him being a student.
The group name is just a label. There's no real reason why you couldn't
call it something else. (Stay away from "staff", and be aware that on
many systems "users" already exists.)
> I wonder, can't a student simple give the command chown and make a
> mess with it all?
Someone can chgrp/chmod a file or directory that they own, yes. But you
could override that with a frequent cron job (or a script built around
inotify) if you needed to.
> The main point of the thread [1] is CHROOTing the users inside
> /home. Yes, Kelly, I do believe they can cause (non-sophisticated)
> problems, because I saw some history commands (like this one I can't
> explain: $explode professor's computer,
If you put an account inside chroot then you will need to ensure that
you've copied in all the commands that this account needs to use. I
really don't see that this buys you anything whatsoever for an interactive
account. An interactive account with a decent subset of commands will
let you create executables - and it's often all too easy to get around
r*shell restrictions on PATH, so effectively anyone can run any command
sooner or later anyway.
> Also, this server has a very fast link with a governmental institution
> that must be preserved by outsider's attacks
Simple answer here is to prevent access to the remote system by
unauthorised users. If your students shouldn't have access to it, then
put your students on a different system that doesn't have access. If
that's not possible then disconnect this system from the sensitive one
and put the appropriate subset of authorised users on another system
that does have access to it. Look at your policies and procedures -
a (signed) piece of paper telling people not to access unauthorised
systems can be extremely useful as part of a access protection system.
Chris
Reply to: