Complete.Org: Mailing Lists: Archives: freeciv-dev: May 2005:
[Freeciv-Dev] (PR#11851) Hack request should verify userid in addition t
Home

[Freeciv-Dev] (PR#11851) Hack request should verify userid in addition t

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
Cc: reinpost@xxxxxxxxxx
Subject: [Freeciv-Dev] (PR#11851) Hack request should verify userid in addition to random string
From: "Ed Overton" <edoverton@xxxxxxxxxx>
Date: Sun, 29 May 2005 16:48:19 -0700
Reply-to: bugs@xxxxxxxxxxx

<URL: http://bugs.freeciv.org/Ticket/Display.html?id=11851 >

> [rp - Sun May 29 19:38:29 2005]:
> 
> > [ednotover - Tue May 24 17:16:10 2005]:
> >
> > > [rp - Tue May 24 16:57:11 2005]:
> >
> > > My question: it seems a lot cleaner and more secure to do away
> > > with all the special code and instead just let the client write
> > > a temporary startup file containing the /cmdlevel hack command,
> > > then make it invoke the server as
> > >
> > >   civserver -r mygenerated.rc
> >
> > > Let me know if there's something I'm missing.
> >
> > That introduces two race conditions.  First, the .rc file might be
> > altered prior to the server reading it.  Second, and much more
> > significant, a startup .rc file must specify /cmdlevel hack first
> > (or refer to a connection name).  However, the "right" client
> > might not be the first to contact the server - so the "wrong"
> > client has a window of opportunity to claim first (or to claim
> > that connection name) prior to the "right" one.
> 
> I just take the Unix attitude here: file permissions define
> authorization.

I follow what you're saying, but there are two problems there.  First,
Freeciv runs on other platforms.  We can't just approach it from the
unix mindset.  Second, realize that the authorization we're discussing
is authorization to overwrite any file owned by the userid that launched
the server process.  (Unless this has been altered since I last looked
at it) under hack, one may save a game to any file whatsoever.

So if you allow me hack - either by explicit grant, or by allowing me to
work the server .rc prior to server invocation - you have just given me
the ability to overwrite all of your files.  It's for this reason that I
think it's wise to err on the side of caution.

> If someone can read or write a file I gave them read
> permissions to, then it's because I want them to.

The assumption here is that you made a concious decision to allow those
permissions.  But even more so, realize there are implications past the
file where you give permissions.  If you give me write authority to some
random file in your account, I can't really do much damage to your
account.  If you grant me authority to alter your .profile, then there's
a lot of damage I can do on your account.  If you grant me authority to
alter a civserver .rc file, then I can set things up so that I can do a
lot of damage to your account via a civserver process that you run off
that rc file.  So it's more than a permissions issue - it's also an
awareness issue that the person granting permissions knows the
implications of how that particular file is used.

> Put another way, if different Freeciv instantiations or
> client/server pairs should not have access to each other's
> environment, make them run as different users.  That's what
> users are for.  This takes away your first concern.  An
> option would be to allow commands to be entered on the
> command line, e.g.
> 
>   civserver -o 'cmdlevel first hack'
> 
> Your second objection is more serious.

Agreed.

> I don't see how to resolve it in a way that improves over
> what is happening now.

I disagree - right now, the reliance is on a file, which may (or may
not) be properly controlled by user permissions.  If it is not
controlled properly, then there's the file overwrite exposure I noted above.

> However I maintain that putting in kludges to make it appear
> that Freeciv separates users when run under the same user is
> the wrong approach.

I'm not clear what you're saying here.  Will you explain further?  What
do you think is the right approach?

> Windows also has a Run As command.

True, but that doesn't really have use when we're talking about the
server instance that is launched from the client.

Ed



[Prev in Thread] Current Thread [Next in Thread]