[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