XPost: alt.comp.software.issuetracking.cvstrac
On 20/03/2010 14:08, Mark Hobley wrote:
By mentioning sql though, you have raised a question in my mind. Can sql run external programs or cause damage outside of the database, or is the
scope for damage by sql limited to the sql database itself?
In nearly all cases damage is limited to the SQL database itself
IN particular the ability of SQL to invoke other programs is now limited
by design to 'safe spaces' directories. E.g. there is an 'INTO OUTFILE'
command that will let you dump data into a (text/CSV) file, but latest iterations have constrained this to be inside of the Var/Lib/Myslql tree
IIRC. By default anyway.
In short in order to dump data to an external file, (or read it from an uploaded file) the user that e.g,. the web server is using to connect to
mysql, must have file privileges...you normally don't do this...even for uploaded files, it is better to turn them into hexadecimal and INSERT
them in the database that way rather than use LOAD DATA.
So that's one layer of protection. The other is that you can 'set secure_file_priv'
"this variable is used to limit the effect of data import and export operations, such as those performed by the LOAD DATA and SELECT ... INTO OUTFILE statements and the LOAD_FILE() function. These operations are
permitted only to users who have the FILE privilege.
secure_file_priv may be set as follows:
If empty, the variable has no effect. This is not a secure setting.
If set to the name of a directory, the server limits import and
export operations to work only with files in that directory. The
directory must exist; the server does not create it.
If set to NULL, the server disables import and export operations.
The default value is platform specific "
(In this case the sql engine is sqlite, but I do have packages that use postgresql and mysql, that also require auditing.)
Well I can only speak for Mysql
http://markhobley.yi.org/policy/publicinterface.html#scope
A chrooted environment seems pointless to me.
Security by design is a good thing, and we should not need the chroot. However
isn't what you get from third party code. A lot of packages need a code audit at this time.
People who use belts and braces do so because their braces are faulty.
I tend not to use presupplied tools on websites as far as possible. If
you use a tool you do not understand and have not written, you cannot
protect against bugs in it.
Its bad enough e.g. discovering the PHP often does not work as
adverstised, run out of memory when its should have lots, and so on.
These days the moment one of these turns up I grab the C compiler.
Mark.
--
"An intellectual is a person knowledgeable in one field who speaks out
only in others...”
Tom Wolfe
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)