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

[Collins Richey]

On Tue, 4 Jan 2005 15:22:18 -0700, Jed S. Baer <thag at frii.com> wrote:
> On Tue, 4 Jan 2005 12:49:00 -0700
> Collins Richey wrote:
> 
> > On Tue, 4 Jan 2005 12:20:36 -0700, Jed S. Baer <thag at frii.com> wrote:
> > > On Tue, 4 Jan 2005 11:08:41 -0700
> > > Collins Richey wrote:
> > >
> > > > Here's the critical question. Do we care whether users can view
> > > > system directories and other users' directories?
> > >
> > > We can mitigate this quite a bit using umask and making sure file
> > > permissions are the most restrictive they can be.
> > >
> > > If we make the members' default umasks 0077, then there's no group
> > > access by default for files created. Only problem is, I don't see how
> > > (yet) to do that with sftp, since it seems to be something that's
> > > associated with shells. (But that can't be entirely true.)
> >
> > I don't have a problem (conceptually) with whether others can see my
> > work.
> 
> Well, let's at least get our intent well constructed. Earlier you wrote:
> 
> > > We prefer to allow sftp so that members can modify their own
> > > environment with ease, but only their own environment. sftp is ideal
> > > for this use, but unfortunately it will allow the use to cd to any
> > > visible directory (not what we want).
> 

Yeah, not very exact.  I back off from that statement.

> "Any visible directory", to me includes the directories of other users in
> the members group. Setting a umask other than the system default is the
> way to do that. The other way is to put each user into a private group.
> 
> So, do we need to do either of the above?

My opinion, no. The private group does nothing if we use the default umask 022.

> 
> If we want to set a umask, then the sftp-wrapper appears to be the only
> way to do that, without using a patched ssh distribution (yes, there is a
> patch available, and HP, for example -- their ssh distribution uses it).
> But using a patch means that everytime we update ssh, we have to patch it,
> until/unless the std. OpenSSH packages incorporate that patch.
> 
> And, based on the answer to the above, what then is the default permission
> mask for user accounts? (Still talking only about level of protection for
> member files.) And remember, anything in the public_html directory needs
> to be readable by the webserver, so non-read will defeat that. Hmmm, so it
> seems the default umask of 0022 is the most restrictive which still
> satisfies the member benefit of a having a website.
> 
> Easiest option is to just leave it the way it is. It's a umask of 0022,
> which results in rwxr-xr-x for directories, and rw-r--r-- for regular
> files. If that's OK, then let's just sftp-server as the login shell
> without any wrapper.

I vote for that option.

> 
> That leaves the question of other files which might be readable. Std.
> example is /etc/passwd. The real question is how much risk having some
> file readable is. What vulnerabilities are there in exposing these types
> of files? If the system is otherwise secure, I think very little.
> 
> 

It seems to me that anyone who can crack the system can get to passwd
anyway. Better have a security guru eyeball that (I decline to suggest
who should do this).

> > > What I am finding is a hack.
> > > http://wiki.gnuarch.org/moin.cgi/Centralized_20Development
> > >
> > > The trick is to make an sftp-wrapper file like so:
> > >
> > > [quote]
> > > #!/bin/sh
> > > umask 002
> > > exec /usr/lib/sftp-server $@
> > >
> > > Then you change the line in sshd_config to read:
> > >
> > > Subsystem       sftp    /usr/local/lib/sftp-wrapper
> > > [/quote]
> > >
> > > Obviously, we'd use a different umask value.
> > >
> > > I'd rather get to the root of controlling the umask without resorting
> > > to shell trickery. But I'm really striking out using Google to find a
> > > definitive answer not involving a typical login shell.
> > >
> > > I guess I'll experiment at home here a bit.
> > >
> >
> > I don't have a problem with using a wrapper script.
> 
> I tried this out. It's wrong. This had an effect on file permissions only
> when I set the wrapper script as the user's login shell. I'd experiment a
> bit more, but there seems, from the above, little point in it.
> 
> My only objection to a wrapper script is that it runs a shell. Even it's
> for only a few clock cycles, maybe there's a way to exploit that. I don't
> know, so I err on the side of caution.
> 
> If your searching on using the sftp-server as a login shell indicates that
> it's a tried-n-true method, it's likely as good as anything else we can
> come up with.
> 

Absence of negatives is what I found. scponly appears to be popular,
but I haven't been able to get ahold of the 4.0 version, so I can't
say whether that's any better.

Another question related to security. How do we scarf up the public
keys from the members? email or ???.

-- 
 Collins