: We argued long about SUID scripts.  I think the reason we made the switch
: entirely disable SUID scripts is that we didn't want existing programs to
: fail mysteriously.  Anyone who has an existing SUID program would be
: unhappy if it failed mysteriously, without any error indications.  I think
: the big arguements were whether to just set errno, or to do a kernel
: printf().  (Consider the consequences of the latter.)  Once you decide that
: you are not going to implement the FD device in the release currently being
: developed, so that the hole is not immediately fixable, you have to
: consider irritable customers who care about incompatibilities.  BSD has no
: such problem with their customers.

Why not make it customizable?  This need not be painful.  A kernel
variable that can be set with adb would do.

On the other hand, the kernel already has the info from the #! line, so
it could conceivably determine if the interpreter in question is
willing to do setuid emulation.

: I think I see how perl might emulate suid perl scripts, if perl is itself
: SUID and if you trust perl to have no holes of its own.

I don't even trust C to have no holes in it...  :-)

Actually, the ordinary Perl interpreter isn't setuid.  If it wants to emulate
the setuid bit, it executes another copy of the interpreter that IS setuid.
Otherwise, the ordinary interpreter could never know the effective uid that
the script was invoked under.  And this is important, as we'll see below...

: Unfortunately,
: most SUID scripts are not written in perl.  What is more, I can't imagine
: much enthusiasm for the task of ensuring that any shell interpretor has no
: holes, not to mention one as powerful as perl.

Shells will have more difficulty because of the multiple-levels-of-substitution
semantics.  Perl is a bit more straightforward in that there's generally
only one level of semantics, so that there is little divergence between
what you think you see happening, and what's really happening.

On top of this, when Perl detects that its effective uid doesn't match
its real uid, it does dataflow analysis at run-time to detect when
insecure data is going to be used to do something dangerous.  Not even
C will do this for you.  It's certainly possible to get around the
mechanism, but it will catch almost all the common blunders.

For this reason, I'd much rather write a setuid program in Perl than in C.
It gripes me to have to put a C wrapper around the script, because the
script itself is architecture independent, and the wrapper isn't.  Which
means that I can't just plonk the script into my architecture-independent,
NFS-mounted bin directory, but I have to go out on every architecture, find
a place to put the wrapper, write it, compile it and chmod it.

Bleah, I say.  System administration is already hard enough.

Larry Wall

Is it possible you haven't had the pleasure of perusing the switches in
/usr/sysgen/master.d/* on an IRIS?  Besides the SUID-script on/off switch,
there are switches for various POSIX behaviors, mbuf allocation policies,
max numbers of proc's, and about everything else but the number of kitchen
sinks.  Switches for finer control on SUID scripts seem unappetizing.

Speaking of POSIX switches, one of my peeves is that the NIST POSIX test
suite requires a behavior that opens a bad security hole.  It's the one
that allows any process to decide to ignore the fact that the phone line
has been hung up.

: > : We argued long about SUID scripts.  I think the reason we made the switch
: > : entirely disable SUID scripts is that we didn't want existing programs to
: > : fail mysteriously.  Anyone who has an existing SUID program would be
: > : unhappy if it failed mysteriously, without any error indications.  I think
: > : the big arguements were whether to just set errno, or to do a kernel
: > : printf().  (Consider the consequences of the latter.)  Once you decide that
: > : you are not going to implement the FD device in the release currently being
: > : developed, so that the hole is not immediately fixable, you have to
: > : consider irritable customers who care about incompatibilities.  BSD has no
: > : such problem with their customers.
: >
: > Why not make it customizable?  This need not be painful.  A kernel
: > variable that can be set with adb would do.
: >  ....
:
:
: Is it possible you haven't had the pleasure of perusing the switches in
: /usr/sysgen/master.d/* on an IRIS?  Besides the SUID-script on/off switch,
: there are switches for various POSIX behaviors, mbuf allocation policies,
: max numbers of proc's, and about everything else but the number of kitchen
: sinks.  Switches for finer control on SUID scripts seem unappetizing.

Nevertheless, that's what I'm asking for.  Me and a bunch of
other people.

Or you could do the /dev/fd trick instead.  But simply ignoring the bit
would let you have setuid Perl scripts while disallowing setuid shell
scripts, since Perl can emulate setuid automatically if the bit is set.

Actually, you really ought to be able to set some kind of permission bit
on an interpreter saying whether it will accept setuid scripts.  A lot
of people would turn it on only for Perl, and leave the shells disabled.
Pity we're running low on bits...

Still, there are ways to do it.  Disallow set-id scripts if the
interpreter has the owner's write bit on, for instance.  That almost
seems like a virtue anyway.  Or only allow setuid interpreters in a
specific directory (since the #! line always gives you a full
pathname).  Or whatever...

Setuid Perl scripts are safer than setuid C programs.  This is an important
issue to us.

Larry Wall