[clue-admin] User setup for "member" accounts

[David Anselmi]

Collins Richey wrote:
[...]
> Good point. That would eliminate a lot of the security exposure. What
> about email as a requirement?

Email should just be an entry in the aliases file so the CLUE address 
automatically forwards to another account.  I don't think shell access 
is required for it.

>>If you want to prevent weak passwords, require public key authentication
>>(not that hard compared to managing passwords, and perhaps good training
>>for members who have never used ssh before).
> 
> Yes, I brought up this question also. This would go a long ways down
> the path to the exclusion of intruders. Of course, if the members' own
> systems aren't secure then the public keys they are using aren't that
> secure either.

I think using PK authentication is a good improvement.  Beyond that 
you're into user training and/or token based systems that are 
impractical.  Still, you'll need a HOWTO for users to generate their 
keys and provide the public one for their accounts (even if all they can 
do is maintain their web space).

>>If you allow a shell, are you worried about members exploiting it?  I
>>know a security guy who says if you give him a shell you've given him
>>root (i.e., there's sure to be a local root exploit).  So to prevent
>>members from getting root you have to limit the commands they use (seems
>>that to do that with rbash is equivalent to doing it with chroot though
>>it might be a little easier conceptually).
> 
> From my limited experience, rbash has too many holes, unless someone
> knows a way to plug them. For example 'rbash intermediate'.
> intermediate contains the text 'bash somedangerousscript'. Bam,
> restrictions overridden.

The way to plug them is to provide members a limited set of commands. 
That means their PATH does not include /bin et. al. it only contains 
/member/bin or whatever.  Then you don't include bash in /member/bin. 
Without a serious requirement for user shells I think this is too hard.

> I'm not as familiar with chroot jails, but this environment seems to
> be a little more bullet proof.

No, same deal.  You have to make an environment that limits what a user 
can do so theoretically they are the same.  In practice it might be 
harder to get out of a jail than rbash but it might also be harder to 
set up the jail correctly.

Dave