Subject | IB security <> FB security |
---|---|
Author | Martijn Tonies |
Post date | 2002-03-06T09:23:58Z |
Hi,
Someone read the thread in interbase.general in the Borland Newsgroups?
Here's a part of the thread:
=====
"Craig Stuntz" <cstuntz@no_spam.vertexsoftware.com> schrieb im Newsbeitrag
news:MPG.16eef25d6847dc67989a69@......
You can create an external table with the filename of the database itself,
containing only one single integer field.
Copying all the rows, you get a copy of the DB file.
It's not only that you can read random files (why do you say text files?)
-- sure, you can deny access to the IB service --
you CAN read the DB file... simple as this.
Thus, if there isn't anything I missed, any DB user can copy any DB file
-- cool, what is the whole security model about?
Sorry for my bad English that seems not to be able to express my concerns.
For example:
IB service has only read access to all IB folders and write access to all
files
it really needs to access. Naturally, it has read/write access to all DB
files.
Any DB user, without any privileges can log into DB
"C:\my_secure_dbs\db1.gdb".
Then execute:
create table T external file "C:\my_secure_dbs\db1.gdb" (I integer);
select I from T;
And has a copy of the whole DB file...
What's wrong with this scenario...???
The only solution I see is never to give a DB login to anyone,
but it's probably not that difficult to take over an existing connection
or extract username/password with a debugger from executable.
Hmm, please, try to understand what I have said,
I don't see it's anything as trivial as your concerns, but I hope that I'm
wrong.
=======
I wonder, with FB, does the single file handle causes this problem to be
fixed?
Martijn Tonies
InterBase Workbench - the developer tool for InterBase and Firebird
http://www.interbaseworkbench.com
[Non-text portions of this message have been removed]
Someone read the thread in interbase.general in the Borland Newsgroups?
Here's a part of the thread:
=====
"Craig Stuntz" <cstuntz@no_spam.vertexsoftware.com> schrieb im Newsbeitrag
news:MPG.16eef25d6847dc67989a69@......
> In article <3c851b07_1@dnews>, me@... says...the
> >
> > The fact that any user can create external tables, and thus has in fact
> > same file access privileges that the IB service has, I a huge securityI'm not sure who does not understand what the other one says.
> > hole IMHO, unless anyone convinces me otherwise.
>
> It's certainly a huge hole if you keep your DB in WinNT\System32 or
> if you give the account that runs IB administrative rights.
>
> Otherwise, all it gives you is the ability to create (but not run)
> text files. Not a great thing, but manageable.
You can create an external table with the filename of the database itself,
containing only one single integer field.
Copying all the rows, you get a copy of the DB file.
It's not only that you can read random files (why do you say text files?)
-- sure, you can deny access to the IB service --
you CAN read the DB file... simple as this.
Thus, if there isn't anything I missed, any DB user can copy any DB file
-- cool, what is the whole security model about?
Sorry for my bad English that seems not to be able to express my concerns.
For example:
IB service has only read access to all IB folders and write access to all
files
it really needs to access. Naturally, it has read/write access to all DB
files.
Any DB user, without any privileges can log into DB
"C:\my_secure_dbs\db1.gdb".
Then execute:
create table T external file "C:\my_secure_dbs\db1.gdb" (I integer);
select I from T;
And has a copy of the whole DB file...
What's wrong with this scenario...???
The only solution I see is never to give a DB login to anyone,
but it's probably not that difficult to take over an existing connection
or extract username/password with a debugger from executable.
Hmm, please, try to understand what I have said,
I don't see it's anything as trivial as your concerns, but I hope that I'm
wrong.
=======
I wonder, with FB, does the single file handle causes this problem to be
fixed?
Martijn Tonies
InterBase Workbench - the developer tool for InterBase and Firebird
http://www.interbaseworkbench.com
[Non-text portions of this message have been removed]