Issue Details (XML | Word | Printable)

Key: CORE-669
Type: New Feature New Feature
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Alexander Peshkov
Reporter: Pavel Cisar
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
Firebird Core

Poor ib security in unix installed version

Created: 17/Sep/03 12:00 AM   Updated: 16/Jun/06 09:22 AM
Component/s: None
Affects Version/s: None
Fix Version/s: 1.5.0

Time Tracking:
Not Specified

SF_ID: 807866


 Description  « Hide
SFID: 807866#
Submitted By: pcisar

Put here from mers newslist post :
 
 From: sskracic@lavsa.com (Sebastian Skracic)

Some time ago I found out that default Linux
installation of IB4.0 introduces Huge security holes.

I've put up some thoughts about it at
http://acs.lavsa.com/bboard/q-and-a-fetch-msg.tcl?msg_id=00000O

Pretty much all outlined above is still valid for
InterBase 6.0, at least SuperServer which I have just
(re)installed. This is not good.

The point here is that _default_ installation must be
reasonably secure.

Just to sum up what should necessarily be done in
installation process:

  - create 'interbas' (or some other) unix user
  - all installed files should be owned by that user
  - through 'gsec', add an entry in isc4.gdb for
'interbas' user
  - through 'isql', exec 'grant all on users to
interbas;' to
    /opt/interbase/isc4.gdb security database to which
you have
    attached as sysdba - the point here is that all
future db
    maintenance will be performed by 'interbas' user,
so this
    step is necessary to allow 'interbas' managing user
accounts
    through 'gsec'.
  - fix 666 (or 777) modes on some files.
  - create directory /var/interbase (or something like
that)
    where .gdb files will be stored (or somewhere in
~interbase)

  Somewhere deep in server code:

  - check which will prevent InterBase daemon from as root


  I'm sure there are even more things that should be
taken care of.


  Comments and flames welcome,

Seb.
----------------------
User: juliancooling
Although the actual bug is not described here, the
solution is very similar to one posted to a mers
newsgroup by jmc@dcbt.com.au about a year ago. If it
is the same bug (it wasn't described there either) then
it is limited to only single Interbase feature.

The bug applies equally to Windows NT.

Either system can be taken out/over in less than a
minute by a user with a valid Interbase account (I
timed myself on Unix typing commands at the command
prompt).

Borland had the Unix version of the bug listed but I
never bothered to check the status of the Windows bug -
I presumed it was known.

I notice that the poster does not recommend leaving the
lock manager running as suid root - which I had thought
was necessary (in the classic architecture) and safe.

If anyone would like further information or my ideas on
this bug and its solution feel free to contact me.

Julian Cooling
(mailto:julian@youramigo.com)

PS: I have been out of the Interbase development
environment for a while - it is interesting to see how
things have moved on.

 All   Comments   Work Log   Change History   Version Control   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Alice F. Bird added a comment - 14/Jun/06 09:41 AM
Date: 2005-09-01 12:31
Sender: alexpeshkoff
Logged In: YES
user_id=423445

Rather hard to comment, when initial link leads to the site,
suggesting airway tickets online.

I'll try to comment what I see in the letter.

- create 'interbas' (or some other) unix user

done in 1.5.0 - user firebird is created, all
firebird-related processes (except fb_lock_mgr in classic)
belong to that user

- all installed files should be owned by that user

that's not good idea. Most of files should better not be
completely accessible by server process. Therefore they are
owned now by root with read/execute permissions. Only files,
normally modifiable by server during it's operation (like
security database), are owned by user firebird

- through 'gsec', add an entry in isc4.gdb for
'interbas' user
- through 'isql', exec 'grant all on users to
interbas;' to
/opt/interbase/isc4.gdb security database to which
you have
attached as sysdba - the point here is that all
future db
maintenance will be performed by 'interbas' user,
so this
step is necessary to allow 'interbas' managing user
accounts
through 'gsec'.

that's all completely bad. And for SS will not work in 1.5.3
and 2.0

- fix 666 (or 777) modes on some files.

done - 1.5 install sets appropriate access rights to all
files. But mostly not word-writable :-)

- create directory /var/interbase (or something like
that)
where .gdb files will be stored (or somewhere in
~interbase)

This may be the most interesting. If we:
1. create such default directory,
2. put it into default firebird.conf: DatabaseAccess =
restrict /that/dir
3. Learn engine to use first path as default for databases
(like it was done for external tables)
result is quite smart and beautiful - user can type
CREATE DATABASE 'NEW.GDB';
and have it created in that default directory. I suggest to
add this as feature request.

Somewhere deep in server code:

- check which will prevent InterBase daemon from as root

Not good. I strongly dislike such hard-coded restrictions.
Many people are reasonably sure, that there server runs in
protected environment (well isolated LAN), and have no
reasons to waste time to change there installations to make
them non-root. We have safe default install, and that's enough.

I close this entry right now. And add new feature request
tomorrow, if noone has something against it.

Alice F. Bird added a comment - 14/Jun/06 09:41 AM
Date: 2005-08-31 19:31
Sender: dimitr
Logged In: YES
user_id=61270

Alex, please comment regarding 1.5.3 and 2.0.