On Wed, Jul 27, 2011 at 3:45 PM, Alex Peshkoff <[email protected]> wrote: > On 07/27/11 16:05, Roman Rokytskyy wrote: >>>> 6. Just in time compilation of the embedded procedure on first use >>>> (after create/alter) into a shared library/DLL which is then >>>> effectively >>>> a dynamically generated UDF library. A JIT approach is important >>>> because >>>> the database can be moved between processor architectures/platforms >>>> and >>>> it is important to be able to recompile automatically for the new >>>> platform. >>> Before doing JIT, we must think about related security issues. How >>> can >>> we prevent pascal procedure from doing bad things with firebird >>> runuser >>> access rights? >> I see two possibilities: >> >> 1. do not include modules that provide "dangerous" functions in the >> "uses" section. In this case people would be able to write only "simple" >> procedures, but most likely that would be more than enough to keep the >> business logic in the database procedures. The "dangerous" functions >> would be file and network in the first place, but also loading shared >> libraries as well as protection from including direct assembly >> instructions as well as filling some memory with malware code and the >> performing a jump to that memory region. >> > > If we can provide such restrictions (probably the best will be to have > fixed list of acceptable "uses"), this can be enough. > >> 2. execute them in separate process which would be executed under >> different user, which in turn should somehow correspond to the database >> user. In ideal case one would log into the database with his current >> user, which will be propagated further. I guess Firebird is not ready >> for such scenario at the moment. As a workaround one could extend CREATE >> USER to specify the OS-level user under which the external procedures >> and UDFs would be executed. One need to consider the IPC overhead here, >> though. >> > > I see some tech problems with that approach... For example, > setuid()/chroot() can't be done by firebird runuser. > >> There is one more scenario - generate Java or CLR byte code from FPC >> and use their sandbox model to apply the restrictions. Somehow that >> should work - as far as I know, Morfik is able to translate C# into FP >> and then compile with FPC, so the reverse translation should be possible >> as well. >> >> So, maybe deploying the binaries (if needed, signed ones) might the >> easiest way for the first integration. > > Yes. I see the option of running in two modes like in the postgresql case trusted and untrusted with one case of lua
http://pllua.projects.postgresql.org/ in trusted mode you can do anything in lua in untrusted only the basic functions no net .... ------------------------------------------------------------------------------ Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
