Re: users and security ibwebadmin
On 2 Jun 2004, Remco Seesink wrote:
> I tried the question below first on debian-mentors but harvested silence.
> Hopefully it is more on topic here.
In part, that is probably because you asked a very hard question. :)
[...]
>> I am packaging ibwebadmin, a web administration tool for firebird
>> and interbase databases.
>>
>> I ran into a problem with users and groups and wonder how to resolve it.
>>
>> The program runs some tools from the firebird packages (eg gbak, isql etc.)
>> These tools work locally on database files. All the database related files
>> are owned by the firebird user and group.
>>
>> The firebird tools run as the www-data user as they are invoked from the
>> apache process.
>>
>> Adding www-data to the firebird groups seems a security risk for the database
>> when it would be hit by a worm. New databases would still be created as the
>> www-data users instead of the firebird user.
Yes. This would also allow *any* user who had access to upload a CGI
script to your system to control your database server; not a desirable
state of affairs.
>> Must I do something with suid?
Not necessarily, but it is probably the easiest path to achieve the
result you want.
>> Make the firebird tools suid firebird?
No, not a great idea. This gives anyone who has shell access to your
system control over your database server; again, not really desirable.
>> I am not experienced with ins and outs of suid but I understand they
>> are often a source of security hazards.
Yes. If you suid an application to another user, and I run it, I
effectively just logged in as the other user to do that.
>> How could I set it up secure so ibwebadmin is still able to process
>> the database files?
This is the hard bit. To do this, I usually follow this process:
1. write out *exactly* what admin task I need to achieve
2. write out *exactly* what information I need to achieve it
3. work out what security risks exist when that information is "hostile"
4. write a tool that exposes the smallest interface possible, and that
actively defends against hostile information
5. try and work out if I can avoid using a suid tool anyway. ;)
For example, for database creation I worked out that I needed:
1. the name of the database
2. the username for the 'admin' user of that specific database
I was then able to write a script that, given that information, verified
that it was all valid, then created the database as appropriate.
That said, the other option is to use the Apache `suexec' functionality
to run your CGI script as the firebird user. That is probably less work,
but is correspondingly less secure.
>> If this questions are not basic and more appropriate for
>> debian-security tell me and I'll take them there.
>>
>> I have been playing around with the firebird packages and have a
>> version with some minor bugs fixes sitting on my harddrive. If it
>> needs a firebird fix I could do that. (It's orphaned)
The trick is to think of how any action could be exploited by a hostile
user, rather than a friendly one.
For example, the firebird admin tool you were thinking of making suid -
does that allow running shell commands? If so, making it suid is the
equivalent of granting all users shell access as the firebird user.
Daniel
--
A drug is neither moral nor immoral--it's a chemical compound. The compound
itself is not a menace to society until a human being treats it as if
consumption bestowed a temporary license to act like an asshole.
-- Frank Zappa
Reply to: