DEV Community

facilishz
facilishz

Posted on

An authz file is the only thing between an anonymous Subversion client and the whole repository

#security

An authz file is the only thing between an anonymous Subversion client and the whole repository

Subversion's access control has two halves, and the second one is easy to forget. Authentication decides who you are. Path-based authorization decides what you may read, and the svnbook documents it as a separate system, controlled by the authz-db setting, that applies to both svnserve and Apache httpd.

The default makes the gap concrete. In the svnserve chapter, the book shows a configuration with anon-access = read, auth-access = write and a password-db, and states that those example settings are the defaults. A repository served without further configuration therefore answers unauthenticated readers.

The authorization file decides per path

Path-based authorization grants or denies access to repository paths per user or group. The book's description of the file is direct: authenticated usernames are the option names within each section, and the value describes that user's level of access to the repository path, either r for read-only or rw for read and write. Two tokens carry special meaning: $authenticated matches anyone who has authenticated with a username, and $anonymous matches everyone who has not.

That design is expressive and good. It also means an empty or absent authorization file does nothing to restrict access, because the restriction was never authentication in the first place.

Three configurations that look fine

Consider the configurations that appear in real deployments.

The first disables anonymous access (anon-access = none) and relies on a password-db. Anyone with any account in that file can now read the whole repository, including the parts the account was never meant to see, because no authorization file was added.

The second keeps the documented defaults. Anonymous readers get read access to every path, and the repository is public in effect, whether or not that was intended.

The third has an authorization file, written once for the project that created the repository, and then reused for repositories added later. The paths in that file match the old layout. New paths fall outside every rule, and Subversion's behaviour for unmatched paths is the deciding detail in any review.

All three pass a check that only asks whether svnserve answers.

What the settings actually look like

In svnserve, the [general] section carries password-db, realm, authz-db, anon-access and auth-access. The book notes that authz-db is not mutually exclusive with anon-access and auth-access: if all are defined, all the rules must be satisfied before access is allowed. That sentence is the most useful part of the documentation for an auditor, because it says the two layers are cumulative and neither one is an override.

Over HTTP, the same authorization file is referenced by the Apache configuration, and anonymous read access comes from the usual HTTP authentication behaviour rather than from anon-access. The file format is shared, which is convenient and also invites the assumption that configuring one transport configures the other.

The review

Three questions, in order.

First, is anonymous access possible? On svnserve, read anon-access. Over HTTP, check whether the location requires authentication for read methods, not just for write methods.

Second, does an authorization file exist, and does it name the current repository layout? A file that lists the paths from three reorganisations ago is worse than none, because it creates the impression of a control.

Third, does the authorization file use $authenticated as a blanket read grant? That token is convenient for a shared internal repository and it collapses the per-path model, since every account with credentials gets read access everywhere.

Detection

Subversion access is visible in the server's own logs and in the client's expectations. The useful signal is a read operation from an unauthenticated session against the repository root, or a listing operation that returns more paths than the session should know about.

Over HTTP this appears as a 200 response to a PROPFIND with no Authorization header. On svnserve, it is a session that never authenticated and still received data. Both are visible if request logging exists, and both are invisible if it does not, so the review should establish whether logging is on before it starts asking why nothing appeared.

A note on scale

Subversion is old and unglamorous, which is exactly why it stays. Repositories accumulate over a decade, access rules get copied between projects, and the person who understood the authz file has left. The system is still doing what it was configured to do.

The risk is exactly that. A version control repository holds source, sometimes credentials in configuration examples, and the history of both. When the default posture is anonymous read and the authorization file is stale, the repository is a public archive with a private reputation.

References

Top comments (0)