Re: Running Web Servers In A Chroot Jail

The Natural Philosopher <[email protected]> Sun, 9 Jan 2022 15:23:13 +0000
Newsgroups comp.os.linux.setup,alt.comp.software.issuetracking.cvstrac
Organization A little, after lunch
Message-ID <[email protected]>
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