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

[Jed S. Baer]

On Thu, 30 Dec 2004 07:33:02 -0700
Collins Richey wrote:

> Based on the requirements above, I recommend that we NOT provide login
> accounts for members. Obviously we are going to continue to provide
> login accounts for admins, and we need to take steps to secure those
> accounts (PK authentication, etc.), but removing member logins is a
> big step toward securing the server.

Agreed. Seems unnecessary.

> So, in my estimation,  we are down to the following:
> 
> 1. Maintaining email aliases. Just as we don't provide login accounts
> for members, I recomment that we NOT provide an external means to
> update the aliases file. We can provide an online form that submits a
> request to the appropriate admin (or group of admins).

Easily enough handled with the existing contact form. Request goes to the
sysadmin or membership e-mail, and I can even toss in a generated subject
line, but that's just frosting on the cake.

> 2. Setup non-login accounts for members (shell: /bin/false or
> equivalent).

The default in RH's "user admin" tool is /sbin/nologin, or maybe I should
say that's for the "nonuser" accounts, such as apache and mailman.

> 3. This leaves the method that users employ to update their
> ~/public_html up for grabs. Jed has suggested scp or sftp. There's
> also the possibility of including a member update function in the web
> site redesign. Your thoughts, please.

scp/sftp seems the easiest to implement, as they're already installed on
the box. Well, I think it currently supports sftp, but it's not
configured. Hmmm. Looks to be part of OpenSSH, and the sshd_config file
has it set up. I'll have to try it out.

sftp seems like what we'd need, as it supports deletion operations. The
default umask for member accounts should be set so no group write is
granted on files, otherwise, a member could use sftp to remove another
member's files. Or, we switch to putting each member in a private group.

> > While looking for stuff, I noticed this, which, in retrospect, seems
> > more ominous than it did at the time:
> > http://clue.denver.co.us/pipermail/clue-admin/2003-December/001335.html
> > 
> 
> IMO, providing incoming FTP on our server is a recipe for disaster. We
> should close any FTP ports immediately. Perhaps Jed can comment more
> about sftp.

Unless I had a major brain cramp, no ftp should be possible to the box --
note the date on the preceding. The firewall allows only http, smtp, and
ssh. And those are the only network-aware services that are running --
well, I shouldn't say "aware", but rather that nothing else, that I know
of, will accept an external socket request -- except for ping, etc. -- I
make no assurances regarding ICMP and UDP, except that obvious things like
finger and ident aren't running. I didn't configure xinetd, because it's
not running either, but if it's ever turned on (for example, to allow
anonymous CVS access via pserver) it'll need to get a good going-over.

jed
-- 
http://s88369986.onlinehome.us/freedomsight/
Key fingerprint = B027 FEFB 4281 CC72 67D1  4237 F2D0 D356 077A A30E
... it is poor civic hygiene to install technologies that could someday
facilitate a police state. -- Bruce Schneier