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. ------------------------------------------------------------------------------ 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
