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

[Jed S. Baer]

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

"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?

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.

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.


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

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