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
Comments
Commented by: Alice F. Bird (firebirds) Date: 2005-09-01 12:31 Rather hard to comment, when initial link leads to the site, 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 - all installed files should be owned by that user that's not good idea. Most of files should better not be - through 'gsec', add an entry in isc4.gdb for that's all completely bad. And for SS will not work in 1.5.3 - fix 666 (or 777) modes on some files. done - 1.5 install sets appropriate access rights to all - create directory /var/interbase (or something like This may be the most interesting. If we: Somewhere deep in server code: - check which will prevent InterBase daemon from as root Not good. I strongly dislike such hard-coded restrictions. I close this entry right now. And add new feature request |
Commented by: Alice F. Bird (firebirds) Date: 2005-08-31 19:31 Alex, please comment regarding 1.5.3 and 2.0. |
Modified by: @dyemanovstatus: Reopened [ 4 ] => Resolved [ 5 ] resolution: Fixed [ 1 ] SF_ID: 807866 => |
Modified by: @pcisarWorkflow: jira [ 10693 ] => Firebird [ 15081 ] |
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.
The text was updated successfully, but these errors were encountered: