Edgewall Software

Ticket #5566 (new defect)

Opened 19 months ago

Last modified 10 months ago

Postgresql admin security issue

Reported by: dannys@… Owned by: cmlenz
Priority: normal Milestone: 0.13
Component: admin/console Version: 0.10.3
Severity: normal Keywords: postgresql permissions
Cc:

Description

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

Attachments

Change History

  Changed 16 months ago by sid

  • keywords needinfo added

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?

  Changed 16 months ago by nkantrowitz

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.

  Changed 16 months ago by 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.

follow-up: ↓ 5   Changed 16 months ago by 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. =)

in reply to: ↑ 4   Changed 10 months ago by cboos

  • keywords permissions added; mysql needinfo removed
  • milestone set to 0.12

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.

Add/Change #5566 (Postgresql admin security issue)

Author



Change Properties
<Author field>
Action
as new
as The resolution will be set. Next status will be 'closed'
to The owner will change from cmlenz. Next status will be 'new'
The owner will change from cmlenz to anonymous. Next status will be 'assigned'
 
Note: See TracTickets for help on using tickets.