Subject | Re: [IB-Architect] UDF and null |
---|---|
Author | Randal Carpenter |
Post date | 2000-12-04T12:52:53Z |
Great idea,
Or simply (simple is good) a udf file checksum stored when you add a udf,
if the checksum don't match when a udf fuction is called, the SYSDBA must
do something (something as in drop/re-add the udf or update the checksum
via a new udf command line tool which requires being logged in as SYSDBA),
otherwise the udf is not usable and a crc match error is stuck in the log
and/or perhaps an exception is thrown. I dunno, just thowing stuff up
and seeing where it lands.
Randal
Or simply (simple is good) a udf file checksum stored when you add a udf,
if the checksum don't match when a udf fuction is called, the SYSDBA must
do something (something as in drop/re-add the udf or update the checksum
via a new udf command line tool which requires being logged in as SYSDBA),
otherwise the udf is not usable and a crc match error is stuck in the log
and/or perhaps an exception is thrown. I dunno, just thowing stuff up
and seeing where it lands.
Randal
On Sun, 3 Dec 2000, Adam Clarke wrote:
> Perhaps udf's need some form of code signing (storing the certs in system
> tables) to ensure that the udf in effect is the one that was originally
> installed and came from a trusted (or at least identified) source.
>
>
> ----- Original Message -----
> From: "Helen Borrie" <helebor@...>
> To: <IB-Architect@egroups.com>
> Sent: Saturday, December 02, 2000 9:50 PM
> Subject: Re: [IB-Architect] UDF and null
>
>
> At 11:39 AM 02-12-00 +0100, you wrote:
> > >Perhaps the security problem has more to do with the fact that currently
> > >only the declaration is compiled in the database (compiled? maybe just
> > >"stored"..). So a malevolent person could write a trojan horse
> ib_udf.dll
> > >or ib_udf.so with bona fide functions replaced by malicious ones with
> > >identical name and parameters, make it available as a bin download and
> > >catch a lot of eager SYSDBAs with their pants down.
> >
> >Udfs are stored into the dbf in system tables, we can by default allow
> >SYSDBA to add user defined functions to database by changing the privileges
> >to RDB$FUNCTIONS and RDB$FUNCTION_ARGUMENTS.
> >I think If a user can't declare a user defined function, and the defined
> >functions are well programmed and stable there is no security hole.
>
> Only the declarations of the UDFs are stored in the system tables.
> The UDFs themselves are completely external to the database. As things
> stand now, as long as the UDF exists in the library as declared and the
> declaration is correct, the database doesn't know nor care what the
> function does.
>
> >I think the best way is to allow the descriptor type, it's backguard
> >compatible and transparent to old udfs.
>
> I like the *idea* of the descriptor and I think it would be easier to
> debug. But as long as the execution is external, it is vulnerable to
> external interference.
>
> Helen
>
> All for Open and Open for All
> InterBase Developer Initiative ยท http://www.interbase2000.org
> _______________________________________________________
>
> To unsubscribe from this group, send an email to:
> IB-Architect-unsubscribe@onelist.com
>
>
>
>
>
>
> To unsubscribe from this group, send an email to:
> IB-Architect-unsubscribe@onelist.com
>
>
>