--- In ib-support@y..., "Claudio Valderrama C." <cvalde@u...> wrote:

> "Martijn Tonies" <martijn@b...> wrote in message
> news:D09B3AA2992AD611AA5200AA004126EEDE6A@SRV_BISIT...
> > Hi,
> > > >
> > > > The fact that any user can create external tables, and thus

has in

> fact
> > the
> > > > same file access privileges that the IB service has, I a huge

security

> > > > hole IMHO, unless anyone convinces me otherwise.
>
> > I wonder, with FB, does the single file handle causes this

problem to be

> > fixed?
>
> Originally it was fixed in Win32. Mike set up the flags so only the

engine

> would have exclusive access to the gdbs, but Ann relaxed the rule

so the

> engine has exclusive write access but allows shared reading. The

reason is

> that some tools insist in peeking at the gdb directly. Besides

that, it's

> not a total solution even if you deny anyone else R/W rights: the

intruder

> could map a db that's not currently in use.
>
> I think I pointed out a year ago that external files are a nice way

to

> rewrite the ibconfig file. Once done, the intruder could add a UDF

directory

> to the engine's authorized paths. After that, the intruder can

attempt to

> load a rogue UDF in that added directory where that person has R/W

rights to

> copy it. The temp dir, for example.
>
> C.
> --
> Claudio Valderrama C. - http://www.cvalde.com -

http://www.firebirdSql.org

> Independent developer
> Owner of the Interbase® WebRing

Claudio I think we are talking the same security hole? That is that
is the ability for any interbase user to copy any (regardless of OS
or Interbase permissions) file so long as the location is known. Why
would such a thing be be allowed and if it was allowed (assuming
someone does have rocks in their head) you should be able to turn it
off.


here's part of an earlier post could this solution be easily
implemented?

"I agree Martijn. The current security model is not the best but it
is workable except for this hole. So lets just plug the hole the
eaisest way we can and re-think the whole security model for FB2.

How to fill the hole? - maybe we can put a flag file in the external
file directory that will disable the external file access.
The flag file would have a list of Interbase users that are to be
given access.Those that use the feature from time to time for an
import ect can switch the access off and on. The only way into a
directory is if the flag file in that directory gives access.

Those that currently use the external file access will only have to
add the flag file to the directories they access it may just
contain "All Users" or provide a list of users.

The advantages of this solution is it's should be easy to implement.
Blocking external file access shouldn't be too hard. Until Firebird
2... (who knows it might work so well, we'll keep it!)."


Gary