On 27-7-2011 14:45, Alex Peshkoff 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. Could be a good to eliminate casual problems, but IIRC, FreePascal (and Delphi) have direct memory management access (getmem etc) and you can write array logic that overflows the array buffer - but there are range checks for that which you can enforce in the compiler - as Firebird controls compilation anyway....
Yes, this does seem like a step in the right direction - but I'm probably overlooking lots of security holes.... "Of course, an alternative, as Alex Peshkoff mentioned: If we vote for speed, the best choice will be use of precompiled libraries - like with UDFs. And like UDFs we leave it to sysadmin - not DBA." ... we could just trust sysadmins to only upload proper code - seems like a signed code approach might be a good first step... I should be possible to provide an adapted FPC compiler or some other parser that warns about unsafe constructs (procedures/units), and refine that based on user feedback. Admins could review whether the constructs in question are safe for that particular deployment... I know the FPC/Lazarus guys have a parser built into the compiler and another one for syntax checking source, so there are already 2 options to choose from ;) -- Regards, jb ------------------------------------------------------------------------------ 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
