On Mon, 18 Jun 2007, Matt D. Harris wrote:
Some logic to check the underlying filesystem of a script before reading
it would be a very cool addition to perl from a security standpoint.
This is not necessarily a great idea: not only Perl is in no way special,
but like most interpreters, it can be invoked to read scripts from stdin
or any other "volatile" source, without the necessity to store them in a
file. Most interpreters also accept include file search paths and
various command-line switches that would make such restrictions
pointless anyway.
But, say we implement heavily-handed restricted mode for Perl. Should bash
refuse to read from stdin and implement the same check? Gdb? Awk? Sed?
Where do you draw the line?
If you don't want your users to use interpreters, make these programs not
executable by that user; there's really no other way without a major
ovehaul of how un*xes are built.
And even then, interpreters aside, "noexec" flag is *not* an effective
method to stop the user from running custom code, and never was:
- /lib/ld-linux.so.2 /tmp/myexec
- LD_PRELOAD=/tmp/foo.so ls
- etc, etc.
/mz
-------------------------------------------------------------------------
This list sponsored by: SPI Dynamics
ALERT: .How a Hacker Launches a SQL Injection Attack!.- White Paper
It's as simple as placing additional SQL commands into a Web Form input box
giving hackers complete access to all your backend systems! Firewalls and IDS
will not stop such attacks because SQL Injections are NOT seen as intruders.
Download this *FREE* white paper from SPI Dynamics for a complete guide to
protection!
https://download.spidynamics.com/1/ad/sql.asp?Campaign_ID=70160000000Cn8E
--------------------------------------------------------------------------
