[redirecting mail back to the dev list]
On Fri, 21 Oct 2005, Carl Karsten wrote:
> >This has come up repeatedly for numerous commands and APIs. The root cause
> >of this problem is that the potentially sensitive information is
> >appropriate
> >for display by some callers, and thus must be propogated from the lowest
> >levels by the core libraries.
> >
> >A while back, I attempted design of a solution which allowed error
> >information
> >to be marked as possibly sensitive. We determined that application of such
> >an API was difficult at best, due to the fact that it is the caller's
> >context
> >which actually determines what error information to display. For example,
> >a system administrator working with svn or svnadmin on the repository host
> >itself might very well want to see full paths to the repository, whereas
> >users of the same repository over ra_dav or ra_svn should not have these
> >paths
> >exposed to them. The underlying core libraries which access the repository
> >must provide the local file system path when generating an error, but
> >since all binaries eventually use the same libraries, that sensitive path
> >information must be suppressed by some callers.
> >
> >As of yet, we punt and leave it up to every caller to filter out possibly
> >sensitive information at the appropriate level. In many places, we are
> >still
> >not yet doing this filtering of sensitive info.
>
> If the "possibly sensitive information" is being passed to the client, is
> it really worth trying to filter it there? That sounds like such an easy
> hack: patch the client to display the info.
The information should not be being passed to the client. That it
sometimes is being passed all the way to the client a bug.
> I can imagine that making it "more" secure may be "much harder", (quotes
> point out un-quantifiable amounts that get "hard" to compare) - my point is
> just: why spend any time trying to secure something if the result is still
> "very" un-secure?
What is unsecure about filtering the possibly sensitive information
out at the appropriate layer (e.g. in libsvn_repos or mod_dav_svn or
svnserve)?
> > The full path to the repositorty is a
> >>>minor security bug that we should fix.
>
> Now for some left field ideas:
>
> Can the client pass in what it knows (in the aboove case, the client passes
> in what it knows the first half of the path to be) and the server can use
> it if it is correct? Example: client passes WCPATH='c:\projects\src\',
> server sees 'C:/Daten/svnroot/myrepo/db', the two arn't the same, so no
> point passing back 'C:/Daten/svnroot/myrepo/db'.
...
The client doesn't pass working copy information to the "server". It
uses the WC path to extract the repository URL from the WC. When the
"server" is accessed over the network, it maps the URL used to access
it to the appropriate local path and RA backend; this mapping is an
example of information which should not be exposed to the client.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Nov 1 00:18:24 2005