[clue-admin] Please review Member Accounts Plan on the wiki

[Collins Richey]

On Thu, 06 Jan 2005 21:51:19 -0700, David Anselmi <anselmi at anselmi.us> wrote:
> Collins Richey wrote:
> > On Wed, 05 Jan 2005 18:48:01 -0700, David Anselmi <anselmi at anselmi.us> wrote:
> [...]
> >>What would it take to support rsync in addition to sftp?
> >
> > Hmm? I haven't found any limited shells with that capability, other
> > than the obvious "real" shells which we don't want to support. If you
> > know of such a beast, we could consider it. I'll do some
> > experimentation.
> >
> >> Could the command option in authorized_keys be used to restrict
> >> members to a small set of commands (rsync, sftp, scp)?
> >
> > I'm not familiar with this. Would this require an actual login shell?
> 
> Yes, but the command option limits the commands that ssh will run for
> that key.  The idea is to use the ssh config to limit people in a more
> flexible way than using sftp as the shell.
> 
> >> Will ssh work if the member doesn't have write permission on
> >> authorized_keys (which may mean he doesn't own it either)?
> [...]
> > But, after reading about the authorized_keys file, it would seem that
> > users with write access to this file could insert keys with almost any
> > command and thus subvert the security setup? Would you comment on
> > this, please. Could this be used to get a "real" shell on the account?
> 
> Yes, that's why the user can't have write access to the authorized_keys
> file (and probably the .ssh dir too).
> 

I'm still at sixes and sevens on the setup. 

1. I've found relatively good reports (or at least few negatives)
about using sftp-server as the "shell" for members. The only negatives
I've found have to do with using sftp in conjunction with some sort of
a coordinated rootkit invasion. It seems that segregating the /home
directory for members separate from admins and mounting the filesystem
"nosuid, noexec" would go a long ways towards securing the site if we
are using sftp only as the maintenance vehicle. In any case, we would
want to insure that the .ssh directory and its contents are not
writable by the members. sftp works quite nicely, and the members can
easily switch between limited internal commands on the server and
their own shell on their own system where they have more complete
tools to manage their webpage contents.

2. David has proposed that we utilize the "command" feature in the
~/.ssh/authorized_keys file in conjuction with an actual shell to
allow users more flexibility (rsync in particular) to manage their
webpages. I'm not familiar with this setup, and surely it introduces
more security risk than the sftp-only setup? I'm mindful of the
comment (It may have been from David as well) "give me shell access
and I'll find a way to crack your system." I need more help with this
concept. Does anyone know actual sites that are using this setup? What
are the pros and cons? Is this really what we want to do?

As I've recommended before, I believe we need an actual security guru
to look over our planned setup and comment on the "best practice" for
our site. I have no aversion to doing the work to implement the setup,
but I don't believe I am the best person to make the final decision
about the setup.

I've completed a skeleton script to add new members and a skeleton
script to enable automated updates to the members' email alias. I'm
working with Jed to implement setting up a separate partition for the
member /home directories. The simplest approach here is to abandon the
data on the /old drive (salvaging a few things like the member
pictures that Lynn has accumulated and other ??? stuff) and dedicate
that drive to the members area.

Keep those cards and letters coming in..

-- 
 Collins