Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Poor ib security in unix installed version [CORE669] #1035

Closed
firebird-automations opened this issue Sep 17, 2003 · 6 comments
Closed

Poor ib security in unix installed version [CORE669] #1035

firebird-automations opened this issue Sep 17, 2003 · 6 comments

Comments

@firebird-automations
Copy link
Collaborator

Submitted by: @pcisar

SFID: 807866#⁠
Submitted By: pcisar

Put here from mers newslist post :

From: mailto: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 mailto: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.

@firebird-automations
Copy link
Collaborator Author

Commented by: Alice F. Bird (firebirds)

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.

@firebird-automations
Copy link
Collaborator Author

Commented by: Alice F. Bird (firebirds)

Date: 2005-08-31 19:31
Sender: dimitr
Logged In: YES
user_id=61270

Alex, please comment regarding 1.5.3 and 2.0.

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

status: Closed [ 6 ] => Reopened [ 4 ]

SF_ID: 807866 =>

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

status: Reopened [ 4 ] => Resolved [ 5 ]

resolution: Fixed [ 1 ]

SF_ID: 807866 =>

@firebird-automations
Copy link
Collaborator Author

Modified by: @pcisar

status: Resolved [ 5 ] => Closed [ 6 ]

SF_ID: 807866 =>

@firebird-automations
Copy link
Collaborator Author

Modified by: @pcisar

Workflow: jira [ 10693 ] => Firebird [ 15081 ]

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants