I've uploaded suidscript.c with updates:
http://suidscript.sply.org/suidscript/suidscript.c
http://suidscript.sply.org/suidscript.tgz
Current implementation checks the safety of an interpreter path and of a script
path - all nodes required to be owned by root or script owner and writable only
On Thu, 2006-Apr-06 00:29:27 +0400, Sply Splyeff wrote:
There are some security problems with kernel-level script
setuid execution which discourage from using it.
The biggest problem is a race condition between the kernel setting up
the set[gu]id() environment and opening the script to find the
The biggest problem is its failure to check the sanity of the input
parameters - that a particular argument actually exists before
referencing it.
Do you mean that evil Bob can substitue Alice's script between stat() and
execve() calls?
Yes, I've missed this point.
We can use realpath and
On Thu, 2006-Apr-06 14:49:25 +0400, Sply Splyeff wrote:
The biggest problem is its failure to check the sanity of the input
parameters - that a particular argument actually exists before
referencing it.
Do you mean that evil Bob can substitue Alice's script between stat() and
execve() calls?
You should be able to get around this by opening the script
first, using fstatfs() and fstat() and passing the script as /dev/fd/N to
the interpreter.
Great idea. Thank you very much.
What I was actually referring to was your use of argv[1], argv[2], argv[3]
and argv[4] without checking
There are some security problems with kernel-level script
setuid execution which discourage from using it. The standard
recommendation is to write a binary setuid wrapper for
each script needed. But maybe it's better to use one simple,
well reviewed and verified setuid wrapper for all common
6 matches
Mail list logo
