Hi,
Is it in any (reasonable) way possible to make Linux support executable
shell scripts? Perhaps through binfmt_misc?
On Sat, 2006-05-13 at 12:38 +0200, Mark Rosenstand wrote:
> Hi,
>
> Is it in any (reasonable) way possible to make Linux support executable
> shell scripts? Perhaps through binfmt_misc?
ehhhhhh this is already supposed to work.
On Sat, May 13, 2006 at 12:38:41PM +0200, Mark Rosenstand wrote:
> Hi,
>
> Is it in any (reasonable) way possible to make Linux support executable
> shell scripts? Perhaps through binfmt_misc?
Huh ?
man chmod
Willy
Arjan van de Ven <[email protected]> wrote:
> On Sat, 2006-05-13 at 12:38 +0200, Mark Rosenstand wrote:
> > Hi,
> >
> > Is it in any (reasonable) way possible to make Linux support executable
> > shell scripts? Perhaps through binfmt_misc?
>
> ehhhhhh this is already supposed to work.
It doesn't:
bash-3.00$ cat << EOF > test
> #!/bin/sh
> echo "yay, I'm executing!"
> EOF
bash-3.00$ chmod 111 test
bash-3.00$ ./test
/bin/sh: ./test: Permission denied
A more useful case is when you setuid the script (and no, this doesn't
need to be running as root and/or executable by all.)
On Sat, 2006-05-13 at 13:03 +0200, Mark Rosenstand wrote:
> Arjan van de Ven <[email protected]> wrote:
> > On Sat, 2006-05-13 at 12:38 +0200, Mark Rosenstand wrote:
> > > Hi,
> > >
> > > Is it in any (reasonable) way possible to make Linux support executable
> > > shell scripts? Perhaps through binfmt_misc?
> >
> > ehhhhhh this is already supposed to work.
>
> It doesn't:
>
> bash-3.00$ cat << EOF > test
> > #!/bin/sh
> > echo "yay, I'm executing!"
> > EOF
> bash-3.00$ chmod 111 test
> bash-3.00$ ./test
> /bin/sh: ./test: Permission denied
is your script readable as well? 111 is just weird/odd.
On Sat, May 13, 2006 at 01:07:12PM +0200, Arjan van de Ven wrote:
> On Sat, 2006-05-13 at 13:03 +0200, Mark Rosenstand wrote:
> > Arjan van de Ven <[email protected]> wrote:
> > > On Sat, 2006-05-13 at 12:38 +0200, Mark Rosenstand wrote:
> > > > Hi,
> > > >
> > > > Is it in any (reasonable) way possible to make Linux support executable
> > > > shell scripts? Perhaps through binfmt_misc?
> > >
> > > ehhhhhh this is already supposed to work.
> >
> > It doesn't:
> >
> > bash-3.00$ cat << EOF > test
> > > #!/bin/sh
> > > echo "yay, I'm executing!"
> > > EOF
> > bash-3.00$ chmod 111 test
> > bash-3.00$ ./test
> > /bin/sh: ./test: Permission denied
^^^^^^^
> is your script readable as well? 111 is just weird/odd.
BTW, Mark, you should have noticed that you script was executed and that
it's /bin/sh which cannot read it. At the risk of repeating myself, please
do a 'man chmod'.
Willy
Arjan van de Ven <[email protected]> wrote:
> On Sat, 2006-05-13 at 13:03 +0200, Mark Rosenstand wrote:
> > Arjan van de Ven <[email protected]> wrote:
> > > On Sat, 2006-05-13 at 12:38 +0200, Mark Rosenstand wrote:
> > > > Hi,
> > > >
> > > > Is it in any (reasonable) way possible to make Linux support executable
> > > > shell scripts? Perhaps through binfmt_misc?
> > >
> > > ehhhhhh this is already supposed to work.
> >
> > It doesn't:
> >
> > bash-3.00$ cat << EOF > test
> > > #!/bin/sh
> > > echo "yay, I'm executing!"
> > > EOF
> > bash-3.00$ chmod 111 test
> > bash-3.00$ ./test
> > /bin/sh: ./test: Permission denied
>
> is your script readable as well? 111 is just weird/odd.
No, it's executable. This is what makes executable shell scripts
distinct from feeding the file to an interpreter.
>From http://www.faqs.org/faqs/unix-faq/faq/part4/section-7.html:
The script is called `executable' because just like a real
(binary) executable it starts with a so-called `magic number'
indicating the type of the executable. In our case this number is
`#!' and the OS takes the rest of the first line as the
interpreter for the script, possibly followed by 1 initial option
like:
#!/bin/sed -f
Suppose this script is called `foo' and is found in /bin,
then if you type:
foo arg1 arg2 arg3
the OS will rearrange things as though you had typed:
/bin/sed -f /bin/foo arg1 arg2 arg3
There is one difference though: if the setuid permission bit for
`foo' is set, it will be honored in the first form of the
command; if you really type the second form, the OS will honor
the permission bits of /bin/sed, which is not setuid, of course.
On Sat, 13 May 2006 13:03:24 +0200 (CEST), Mark Rosenstand <[email protected]> wrote:
> Arjan van de Ven <[email protected]> wrote:
> > On Sat, 2006-05-13 at 12:38 +0200, Mark Rosenstand wrote:
> > > Hi,
> > >
> > > Is it in any (reasonable) way possible to make Linux support executable
> > > shell scripts? Perhaps through binfmt_misc?
> >
> > ehhhhhh this is already supposed to work.
>
> It doesn't:
>
> bash-3.00$ cat << EOF > test
> > #!/bin/sh
> > echo "yay, I'm executing!"
> > EOF
> bash-3.00$ chmod 111 test
So you could execute the script if you ever could read it :)
Try with 755...
--
J.A. Magallon <jamagallon()ono!com> \ Software is like sex:
\ It's better when it's free
Mandriva Linux release 2006.1 (Cooker) for i586
Linux 2.6.16-jam11 (gcc 4.1.1 20060330 (prerelease)) #2 SMP PREEMPT Fri
Arjan van de Ven <[email protected]> writes:
> On Sat, 2006-05-13 at 13:03 +0200, Mark Rosenstand wrote:
>> bash-3.00$ cat << EOF > test
>> > #!/bin/sh
>> > echo "yay, I'm executing!"
>> > EOF
>> bash-3.00$ chmod 111 test
>> bash-3.00$ ./test
>> /bin/sh: ./test: Permission denied
>
> is your script readable as well? 111 is just weird/odd.
It needs to be readable as well. What ends up happening is that the
kernel sees the execute bit, looks at the shebang line and then does:
/bin/sh test
Since read permission is off, the shell's open() call fails. It will
work fine if you use 755 as the permissions.
Every Unix I've ever seen works this way. It'd be nice to have
unreadable executable scripts, but no one's ever done it.
-Doug
On Sat, May 13, 2006 at 01:03:24PM +0200, Mark Rosenstand wrote:
> It doesn't:
>
> bash-3.00$ cat << EOF > test
> > #!/bin/sh
> > echo "yay, I'm executing!"
> > EOF
> bash-3.00$ chmod 111 test
> bash-3.00$ ./test
> /bin/sh: ./test: Permission denied
Obviously.
It executes the script, finds that it needs an interpreter and runs /bin/sh
as specified telling it to run the script. /bin/sh though needs to read
the script in and since the script has no read permissions it fails.
Hence permission denied.
--
"To the extent that we overreact, we proffer the terrorists the
greatest tribute."
- High Court Judge Michael Kirby
Douglas McNaught <[email protected]> wrote:
> It needs to be readable as well. What ends up happening is that the
> kernel sees the execute bit, looks at the shebang line and then does:
>
> /bin/sh test
>
> Since read permission is off, the shell's open() call fails. It will
> work fine if you use 755 as the permissions.
>
> Every Unix I've ever seen works this way. It'd be nice to have
> unreadable executable scripts, but no one's ever done it.
According to
http://www.faqs.org/faqs/unix-faq/faq/part4/section-7.html both 4.3BSD
and SunOS have. I can confirm that it works on current BSD's as
well.
Douglas McNaught wrote:
> Arjan van de Ven <[email protected]> writes:
>
>
>>On Sat, 2006-05-13 at 13:03 +0200, Mark Rosenstand wrote:
>
>
>>>bash-3.00$ cat << EOF > test
>>>
>>>>#!/bin/sh
>>>>echo "yay, I'm executing!"
>>>>EOF
>>>
>>>bash-3.00$ chmod 111 test
>>>bash-3.00$ ./test
>>>/bin/sh: ./test: Permission denied
>>
>>is your script readable as well? 111 is just weird/odd.
>
>
> It needs to be readable as well. What ends up happening is that the
> kernel sees the execute bit, looks at the shebang line and then does:
>
> /bin/sh test
>
> Since read permission is off, the shell's open() call fails. It will
> work fine if you use 755 as the permissions.
>
> Every Unix I've ever seen works this way. It'd be nice to have
> unreadable executable scripts, but no one's ever done it.
The solution would be to either stick bash in the kernel (YUCK!)
or to have the kernel basically copy the read-only script to /tmp
or somewhere else, set permissions to sane values and
/bin/sh /tmp/foo.a12345.
Now why on earth would one want the kernel to jump all those hoops
instead of just requiring read access on anything with a shebang?
Naturally, bash has to be supplemented by any other gorramn shell
out there and naturally perl and anything at all that can be invoked
using a shebang, since bash doesn't know how to execute perl
and perl doesn't know how to execute shell and .. and .. and...
So either copy it and set sane values or require read-access
on the file.
// Stefan
On Sat, 2006-05-13 at 13:03 +0200, Mark Rosenstand wrote:
[...]
> A more useful case is when you setuid the script (and no, this doesn't
> need to be running as root and/or executable by all.)
Apart from the permission bug: This has been purposely disabled since it
is way to easy to write exploitable shell or other scripts.
Use a real programming languages, sudo or a trivial wrapper in C ....
Bernd
--
Firmix Software GmbH http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
Embedded Linux Development and Services
Mark Rosenstand wrote:
> Douglas McNaught <[email protected]> wrote:
>> It needs to be readable as well. What ends up happening is that the
>> kernel sees the execute bit, looks at the shebang line and then does:
>>
>> /bin/sh test
>>
>> Since read permission is off, the shell's open() call fails. It will
>> work fine if you use 755 as the permissions.
>>
>> Every Unix I've ever seen works this way. It'd be nice to have
>> unreadable executable scripts, but no one's ever done it.
>
> According to
> http://www.faqs.org/faqs/unix-faq/faq/part4/section-7.html both 4.3BSD
> and SunOS have. I can confirm that it works on current BSD's as
> well.
The faq you're refering to is 10-12 years old. 4.3BSD isn't relevant to
anyone beyond historians at this point.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
-------------------------------------------------
Joel Jaeggli ([email protected])
GPG Key Fingerprint:
5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F 56B2
On Saturday May 13, [email protected] wrote:
> >
> > Every Unix I've ever seen works this way. It'd be nice to have
> > unreadable executable scripts, but no one's ever done it.
>
> The solution would be to either stick bash in the kernel (YUCK!)
> or to have the kernel basically copy the read-only script to /tmp
> or somewhere else, set permissions to sane values and
> /bin/sh /tmp/foo.a12345.
... or open the script file (which there kernel has to do anyway),
attach it to some unused fd (e.g. fd3) and pass "/dev/fd/3" to the
interpreter rather than "/the/shell/script".
Then the interpreter doesn't need to be able to open the file for
read.
However it isn't clear that this is really a gain, as the person
running the script could use ptrace or similar to take a copy of the
script, the bypassing the missing 'r' permission.
Mind you, with ptrace, it isn't too hard to get a copy of a normal
executable that is mode '111'....
The whole concept of having files that are executable but not readable
is completely broken - it gives the appearance of protection without
the reality.
NeilBrown
Bernd Petrovitsch <[email protected]> wrote:
> On Sat, 2006-05-13 at 13:03 +0200, Mark Rosenstand wrote:
> [...]
> > A more useful case is when you setuid the script (and no, this doesn't
> > need to be running as root and/or executable by all.)
>
> Apart from the permission bug: This has been purposely disabled since it
> is way to easy to write exploitable shell or other scripts.
> Use a real programming languages, sudo or a trivial wrapper in C ....
It isn't a bug on systems that support executable shell scripts.
Doing security policy based on programming language seems weird at
best, especially when the only user able to make those decisions is the
superuser.
Obviously the security-unaware people over at the OpenBSD camp must be
completely clueless when they don't disallow the superuser to do this.
I'm looking forward to the day where I'm no longer allowed to make
changes to /etc/ld.so.conf because it's a system file.
Anyway, is it possible to enable this functionality?
On Sat, 2006-05-13 at 13:45 +0200, Mark Rosenstand wrote:
> Bernd Petrovitsch <[email protected]> wrote:
> > On Sat, 2006-05-13 at 13:03 +0200, Mark Rosenstand wrote:
> > [...]
> > > A more useful case is when you setuid the script (and no, this doesn't
> > > need to be running as root and/or executable by all.)
> >
> > Apart from the permission bug: This has been purposely disabled since it
> > is way to easy to write exploitable shell or other scripts.
> > Use a real programming languages, sudo or a trivial wrapper in C ....
s/languages/language/
And I forgot to mention that a kernel patch is another possibility.
> It isn't a bug on systems that support executable shell scripts.
I never wrote that (or anything which implies that directly).
> Doing security policy based on programming language seems weird at
> best, especially when the only user able to make those decisions is the
> superuser.
It boils down to "how easy is it for root to shoot in the foot"?
And the workarounds are somewhere between trivial and simple.
> Obviously the security-unaware people over at the OpenBSD camp must be
> completely clueless when they don't disallow the superuser to do this.
Of course this doesn't change the level of security but it plays with
the risk ....
> I'm looking forward to the day where I'm no longer allowed to make
> changes to /etc/ld.so.conf because it's a system file.
>
> Anyway, is it possible to enable this functionality?
Yes.
Bernd
--
Firmix Software GmbH http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
Embedded Linux Development and Services
(Cutting Arjan off the CC list, he's been bugged enough for his attempt
to help.)
Bernd Petrovitsch <[email protected]> wrote:
> On Sat, 2006-05-13 at 13:45 +0200, Mark Rosenstand wrote:
> > Bernd Petrovitsch <[email protected]> wrote:
> > > On Sat, 2006-05-13 at 13:03 +0200, Mark Rosenstand wrote:
> > > [...]
> > > > A more useful case is when you setuid the script (and no, this doesn't
> > > > need to be running as root and/or executable by all.)
> > >
> > > Apart from the permission bug: This has been purposely disabled since it
> > > is way to easy to write exploitable shell or other scripts.
> > > Use a real programming languages, sudo or a trivial wrapper in C ....
> s/languages/language/
>
> And I forgot to mention that a kernel patch is another possibility.
I'm too stupid to provide such myself, but I'd sure enable the Kconfig
option if it was there :)
> > It isn't a bug on systems that support executable shell scripts.
>
> I never wrote that (or anything which implies that directly).
I was commenting on the "Apart from the permission bug" part.
> > Doing security policy based on programming language seems weird at
> > best, especially when the only user able to make those decisions is the
> > superuser.
>
> It boils down to "how easy is it for root to shoot in the foot"?
> And the workarounds are somewhere between trivial and simple.
Or "dare we handle root a gun, it's a powerful weapon but can be used
to shoot at feet." It's obvious what the answer have been for that in
other operating systems, and probably one of the reasons we're here.
On Sat, May 13, 2006 at 09:37:45PM +1000, Neil Brown wrote:
> On Saturday May 13, [email protected] wrote:
> > >
> > > Every Unix I've ever seen works this way. It'd be nice to have
> > > unreadable executable scripts, but no one's ever done it.
> >
> > The solution would be to either stick bash in the kernel (YUCK!)
> > or to have the kernel basically copy the read-only script to /tmp
> > or somewhere else, set permissions to sane values and
> > /bin/sh /tmp/foo.a12345.
>
> ... or open the script file (which there kernel has to do anyway),
> attach it to some unused fd (e.g. fd3) and pass "/dev/fd/3" to the
> interpreter rather than "/the/shell/script".
>
> Then the interpreter doesn't need to be able to open the file for
> read.
Not exactly, because people who would like to set their scripts to 111
will also set the shell to 111, which makes the process non-dumpable,
with /dev/fd/3 unreachable (it's a link to /proc/self/fd).
> However it isn't clear that this is really a gain, as the person
> running the script could use ptrace or similar to take a copy of the
> script, the bypassing the missing 'r' permission.
>
> Mind you, with ptrace, it isn't too hard to get a copy of a normal
> executable that is mode '111'....
>
> The whole concept of having files that are executable but not readable
> is completely broken - it gives the appearance of protection without
> the reality.
>
> NeilBrown
Cheers,
Willy
On Sat, May 13, 2006 at 02:23:30PM +0200, Mark Rosenstand wrote:
> (Cutting Arjan off the CC list, he's been bugged enough for his attempt
> to help.)
>
> Bernd Petrovitsch <[email protected]> wrote:
> > On Sat, 2006-05-13 at 13:45 +0200, Mark Rosenstand wrote:
> > > Bernd Petrovitsch <[email protected]> wrote:
> > > > On Sat, 2006-05-13 at 13:03 +0200, Mark Rosenstand wrote:
> > > > [...]
> > > > > A more useful case is when you setuid the script (and no, this doesn't
> > > > > need to be running as root and/or executable by all.)
> > > >
> > > > Apart from the permission bug: This has been purposely disabled since it
> > > > is way to easy to write exploitable shell or other scripts.
> > > > Use a real programming languages, sudo or a trivial wrapper in C ....
> > s/languages/language/
> >
> > And I forgot to mention that a kernel patch is another possibility.
>
> I'm too stupid to provide such myself, but I'd sure enable the Kconfig
> option if it was there :)
>
> > > It isn't a bug on systems that support executable shell scripts.
> >
> > I never wrote that (or anything which implies that directly).
>
> I was commenting on the "Apart from the permission bug" part.
>
> > > Doing security policy based on programming language seems weird at
> > > best, especially when the only user able to make those decisions is the
> > > superuser.
> >
> > It boils down to "how easy is it for root to shoot in the foot"?
> > And the workarounds are somewhere between trivial and simple.
>
> Or "dare we handle root a gun, it's a powerful weapon but can be used
> to shoot at feet." It's obvious what the answer have been for that in
> other operating systems, and probably one of the reasons we're here.
Well, at first I thought you did not understand how permissions work. I
apologize for this, but your question was not clear at all. I've checked
on OpenBSD and can confirm that it works. However, it does not exactly
work, it passes /dev/fd/3 to the shell as Neil suggested it. Moreover,
argv[0] gets changed to /dev/fd/3 when the script is not readable, not
very useful :
$ cat > foo
#!/bin/sh
echo \$0=$0 \$1=$1 ...
$ chmod 755 foo
$ ./foo bar
$0=./foo $1=bar ...
$ chmod 111 foo
$ ./foo bar
$0=/dev/fd/3 $1=bar ...
So the very common dirname or ${0%/*} tricks used to get the execution
directory from the running script will not work. Worse, behaviour will
have to be validated both with AND without read permissions since it
works differently in both cases.
At least, feeding the script to stdin and renaming argv[0] to point to
it would have been better.
Regards,
Willy
On Sat, May 13, 2006 at 01:27:54PM +0200, Mark Rosenstand wrote:
> > Every Unix I've ever seen works this way. It'd be nice to have
> > unreadable executable scripts, but no one's ever done it.
>
> According to
> http://www.faqs.org/faqs/unix-faq/faq/part4/section-7.html both
> 4.3BSD and SunOS have. I can confirm that it works on current BSD's
> as well.
Incorrect. The FAQ stated that BSD4.3 and SunOS support executable
shell scripts, but both BSD 4.3 and SunOS required that the shell
scripts be readable. I know, I've personally worked on BSD 4.3
systems and worked on BSD 4.3 source. Read the FAQ more carefully....
Let's try this on Solaris:
1% uname -a
SunOS all-night-tool.mit.edu 5.10 Generic_118822-26 sun4u sparc
2% cat > test-exe
#!/bin/sh
echo "This is a test of a non-readable shell script"
3% chmod 111 test-exe
4% ls -l test-exe
2 ---x--x--x 1 tytso mit 63 May 13 08:56 test-exe*
5% ./test-exe
./test-exe: ./test-exe: cannot open
6% chmod 755 test-exe
7% ./test-exe
This is a test of a non-readable shell script
Any other questions?
- Ted
Theodore Tso <[email protected]> wrote:
> On Sat, May 13, 2006 at 01:27:54PM +0200, Mark Rosenstand wrote:
> > > Every Unix I've ever seen works this way. It'd be nice to have
> > > unreadable executable scripts, but no one's ever done it.
> >
> > According to
> > http://www.faqs.org/faqs/unix-faq/faq/part4/section-7.html both
> > 4.3BSD and SunOS have. I can confirm that it works on current BSD's
> > as well.
>
> Incorrect. The FAQ stated that BSD4.3 and SunOS support executable
> shell scripts, but both BSD 4.3 and SunOS required that the shell
> scripts be readable. I know, I've personally worked on BSD 4.3
> systems and worked on BSD 4.3 source. Read the FAQ more carefully....
I only confirmed that it works on current BSD's, not that it used to
work that way on 4.3BSD (although that was my impression.)
Anyhow, I don't really mind the 111 mode, the point was to show shell
scripts being treated as executables. What I do want this feature for
is the "more useful case" that somehow got stripped off in the replies,
namely setuid and setgid scripts.
> Every Unix I've ever seen works this way. It'd be nice to have
> unreadable executable scripts, but no one's ever done it.
hmm I'm less convinced of what that would bring anyone. Just like you
can get to the content of elf files anyway, you can get to the content
of the script (just attach a debugger for example)
execute == read + action
On Sat, 2006-05-13 at 14:23 +0200, Mark Rosenstand wrote:
> (Cutting Arjan off the CC list, he's been bugged enough for his attempt
> to help.)
>
> Bernd Petrovitsch <[email protected]> wrote:
> > On Sat, 2006-05-13 at 13:45 +0200, Mark Rosenstand wrote:
> > > Bernd Petrovitsch <[email protected]> wrote:
> > > > On Sat, 2006-05-13 at 13:03 +0200, Mark Rosenstand wrote:
> > > > [...]
> > > > > A more useful case is when you setuid the script (and no, this doesn't
> > > > > need to be running as root and/or executable by all.)
What just now comes into my mind is: Do you really want to execute a
program (be it a script or a binary) which you aren't allowed to read
before?
> > > > Apart from the permission bug: This has been purposely disabled since it
> > > > is way to easy to write exploitable shell or other scripts.
> > > > Use a real programming languages, sudo or a trivial wrapper in C ....
> > s/languages/language/
> >
> > And I forgot to mention that a kernel patch is another possibility.
>
> I'm too stupid to provide such myself, but I'd sure enable the Kconfig
> option if it was there :)
Yes, is probably the best "solution" if someone creates such a patch.
> > > It isn't a bug on systems that support executable shell scripts.
> >
> > I never wrote that (or anything which implies that directly).
>
> I was commenting on the "Apart from the permission bug" part.
Sorry, that was not clear to me.
> > > Doing security policy based on programming language seems weird at
> > > best, especially when the only user able to make those decisions is the
> > > superuser.
> >
> > It boils down to "how easy is it for root to shoot in the foot"?
> > And the workarounds are somewhere between trivial and simple.
>
> Or "dare we handle root a gun, it's a powerful weapon but can be used
> to shoot at feet." It's obvious what the answer have been for that in
> other operating systems, and probably one of the reasons we're here.
I'm also a "root knows per definition what s/he is doing" person but
more the problem is that root must give sensitive permsisions to scripts
written by God-knows-who. So either
-) root trusts completely some project/persons/... to quote everything
prefectly and rules injections completely out or
-) root has to check all the SUID scripts (including some of the stuff
called from there).
Yes, we have more than enough bugs in compiled programs but it is far
more easy to get buggy scripts together.
Bernd
--
Firmix Software GmbH http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
Embedded Linux Development and Services
Arjan van de Ven <[email protected]> writes:
>> Every Unix I've ever seen works this way. It'd be nice to have
>> unreadable executable scripts, but no one's ever done it.
>
>
> hmm I'm less convinced of what that would bring anyone. Just like you
> can get to the content of elf files anyway, you can get to the content
> of the script (just attach a debugger for example)
>
> execute == read + action
Good point.
-Doug
On Saturday May 13, [email protected] wrote:
>
> Anyhow, I don't really mind the 111 mode, the point was to show shell
> scripts being treated as executables. What I do want this feature for
> is the "more useful case" that somehow got stripped off in the replies,
> namely setuid and setgid scripts.
> -
setXid scripts are trivially exploitable unless the "/dev/fd/X"
approach is used to pass the file to the interpreter.
A classic approach is
ln -s /bin/setuid-script ~/bin/-i
-i
This will run the interpreter with a first argument of
-i
which (if it is the shell) will just run an interactive shell for
you!!!
Now several shells have hacks to try to detect that case and reject it,
but there are other approaches..
Create a symlink to the script, and just at the right time between the
interpreter starting setuid and the interpreter opening the script,
you redirect the symlink somewhere else. You might have to try a few
times to win the race, but it is sure to be possible.
Again, several shells have hacks in place to detect and avoid that
condition.
But it has turned into an arms race - Can you be sure that the
interpreter you are using correctly detects and avoids all possible
subversion attempts? It seems unlikely.
It is much safer to have a compiled program be the setuid bit, and it
does appropriate checks and runs a script in a highly controlled
manner. I have a program called 'priv' which runs scripts out of
/usr/local/priv after doing some access checks listed at the top of
the script. It makes it quite easy and fairly safe (you still need to
check all command line args carefully) to write setuid-root script.
NeilBrown