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

Collins Richey crichey at gmail.com
Wed Dec 29 11:10:56 MST 2004


On Wed, 29 Dec 2004 10:06:23 -0700, David Anselmi <anselmi at anselmi.us> wrote:
> Jed S. Baer wrote:
> [...]
> > Unless there's a real need for member accounts to have more access, I
> > think they should get the minimum privs they need to update their
> > websites, and, I suppose maybe read e-mail using pine or mutt (I don't
> > recall what's on the box now for CLI e-mail reading). And that means
> > restricted shell, done properly. Since I've never set up chroot jails, I
> > don't know if that's going to far, or easily automated once we know how,
> > or what.
> 
> The first step in this discussion should be to identify what users can
> and can't do (programmers call those requirements, don't they Jeff?).

I agree.

> We want to give members web pages, so a way to upload pages seems
> necessary.  If that's all that's promised, I'd not give them a shell at all.

Good point. That would eliminate a lot of the security exposure. What
about email as a requirement?

> 
> Next is to identify risks and apply countermeasures until the risks are
> acceptible.  For example:
> 
> 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.

> 
> 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.

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

> 
> So let's get some requirements, design a solution, and get it reviewed
> by the gurus.
> 

Excellent suggestion. 

First question: requirements?

Next question: do we need shell accounts?

-- 
 Collins



More information about the clue-admin mailing list