Postgresql admin security issue

[dannys@…]

Trac accepts postgres as a database backend using a string such as: postgres://user:password@localhost:port/database

The problem is anyone with read access to this trac directory basically has full administrator priveleges, because they can just issue the command "trac-admin trac_project permission myself TRAC_ADMIN"

Ideally I'd like to grant project administrators with the ability to customize their trac environment and delegate permissions to other users as necessary. (I keep a master authz file to share amongst various projects) But it seems like 'trac-admin' should really be using the local users authentication credentials. And there should be a seperate set of credentials (that I can keep in a protected file) for the trac web interface.

This problem most likely extends to mysql and any other database connection type. SQLite is one of the few exceptions since it's entirely file based.

I'm using trac-0.10.3.1-2.fc6 and subversion-1.4.3-2.fc6 (on Fedora Core 6, obviously).

[sid]

When you refer to permissions, do you mean the ability to add users and set their permissions? If so, then WebAdmin is the right tool for the job. What type of customizations would you like to be able to do that are not available using that tool?

[Noah Kantrowitz]

It should also be noted that this isn't a problem for Postgres if you use local ident authentication with an appropriate map file. My PG user for Trac doesn't even have a password set.

[dannys@…]

To both sid and nkantrowitz:

The trac.ini file contains the user/password credentials for tracadmin to talk to the database. This credential by necessity has full administrator privileges to the database. This, btw, is trac-to-database authentication.

However, trac has it's own role-based authorization system in the "permission" table. Ideally, when you run tracadmin as a user, you should have to authenticate yourself to trac (user-to-trac authentication). Tracadmin can then use the permissions table to determine what you're allowed to do.

In the current scheme, anyone who can read the trac.ini file has full access to the database.

nkantrowitz is correct with the ident issue. But that seems more complicated to manage and a bit of a hack. I'm not sure, but it also seems like all someone has to do is write a wrapper in their public_html file to get around the issue.

[dannys@…]

addendum:

I do admit that my solution still is not a secure solution, as it just takes someone to recompile tracadmin without those checks to fix the problem. But it seems like the way tracadmin should behave. =)

[Christian Boos]

Replying to dannys@mail.com:

addendum:

I do admit that my solution still is not a secure solution,

Not necessarily. If the trac-admin script is installed the appropriate way (owned by the user owning the trac environment and with the setuid bit set), asking for credentials could effectively prevent unauthorized users to access the environment.

From that point, the usual permission checks could be performed (e.g. a user having only WIKI_ADMIN could do a wiki dump, but not a full backup, for example).

Of course, your original observation still stands: "anyone with read access to this trac directory basically has full administrator priveleges", and that seems OK for me given that what you wanted to achieve ("… to grant project administrators with the ability to customize their trac environment and delegate permissions to other users as necessary") is possible if they're logged in with a different user account and trac-admin behaves as described above.

As in that scheme, the trac.ini file would be only readable by some special user (e.g. nobody), the PostgreSQL admin security issue is also handled.

[Christian Boos]

Replying to cboos:

Replying to dannys@mail.com: … If the trac-admin script is installed the appropriate way (owned by the user owning the trac environment and with the setuid bit set)

Ok, so having the setuid bit set for a script won't work, a dedicated binary wrapper would be needed (e.g. ​http://opensource.dazoot.ro/member/catalin/vmgrucheck/python-setuid.c). That might be a bit too complex to setup.

Still, I agree with dannys (in comment:4) that it'd be better if trac-admin would act on behalf of some real Trac user anyway. Not only for "security", but also for getting more meaningful author information on changes than just 'trac' (e.g. for wiki upgrade currently).

This is also consistent with the idea of moving permission checks down to the model layer.

[grant@…]

I have my Trac directories owned by the user that the web server runs as (www-data) and took away read to "other" (chmod o-rwx -R *) in my Trac projects directory. The problem is solved at this point, as no one would need to directly read the files, unless they are the Trac admin. Actual admin tasks can be handled now through the web admin interface, and trac-admin can be just for those special cases when doing initial setup.

[anonymous]

Isn't this ticket just nonsense? It has nothing to do with trac-admin, but in general with Unix permissions and how you configured everything.

E.g. it is the same as doing chmod -R 777 /etc and then complaining why everyone can read all the passwords and mess around with your services. Simply don't give access to password files to users that don't need them, but afaik trac-admin needs access and therefore needs passwords. Also it has nothing to do with PgSQL, because it is even worse with e.g. SQLite, where users that have access to trac-admin must also have all permissions on db/trac.db files, and can therefore user any sqlite to mess around in Trac database even without a password.

[dannys@…]

It's not nonsense. I was identifying a use case that trac currently does not allow for: a project administrator. I'd like project admins to be able to make changes specific to their environment, but not be given full access to everything.

The reason why SQLite is less of an issue is actually /because/ you can protect it with file permissions. I can't protect a passworded system this way if the password is encoded in the same file I want to give others permission to.

I believe a good deal of the problem is solved if the database connect string is simply placed in a separate file.

If you still don't understand the security issues of this, then I don't think you understand the problem or use-case. If however, Trac just doesn't want to deal with this use-case, that's another story entirely. I raise it here so that you are aware of this use-case.

[Christian Boos]

Replying to anonymous:

Isn't this ticket just nonsense? It has nothing to do with trac-admin, but in general with Unix permissions and how you configured everything.

Not just that. See comment:6.