• Re: Running Web Servers In A Chroot Jail

    From The Natural Philosopher@21:1/5 to Mark Hobley on Sun Jan 9 15:23:13 2022
    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)