[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: setgid perl on UMCE Linux



Jason Sonnenschein <jsonn@xxxxxxxxx> writes:
> Date: Wed, 25 Aug 2004 11:02:54 -0400 (EDT)
> From: Jason Sonnenschein <jsonn@xxxxxxxxx>
> To: umce-linux@xxxxxxxxx
> Subject: setgid perl on UMCE Linux
> Message-ID: <Pine.SOL.4.58.0408251101071.2903@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
> 
> Hi all,
> 
> Does anyone know if umce linux perl was compiled with setuid/setgid
> disabled?  I'm trying to run a perl script setgid, and the setgid does not
> work.  The same setup works fine in Solaris.
> 
> thanks,
> 
> Jason

Actually, this isn't anything that's set in the perl build process.
Where this is actually handled is in the "#!" script binfmt modules
inside the linux kernel.  In the case of linux, for a.out, elf, and som
(hp-ux) executable formats, there is logic in the respective binfmt
modules to call "compute_creds", which is the logic that realizes the
potential for sgid that's first primed in "prepare_binprm".  For
#! scripts, there is no such call, and that's highly deliberate; the linux
people realize that most scripting languages aren't secure enough to
safely implement suid/sgid scripts.

Perl is certainly not a very safe scripting language -- there are way
too many "clever" ways to hijack it.  For instance, it recognizes a
whole host of environment variables that can wildly mutate its
behavior.  "PERL5LIB", for instance, can almost always be pointed to
alternate libraries that could contain arbitrary code.  Additionally,
it's almost universal in perl programming to find unsafe programming
constructs using ``, system, or exec, which invoke the shell and can
easily be abused with bad input.

For most of these cases, it's better practice to run a helper daemon
that does the actual dangerous function, and have a secure way
to connect to the helper daemon (using K5 for instance).  Some ways to
do this include kerberos 5, RX, DCE RPC (IDL), SASL, SSL, SOAP, etc.
On the local host (where the OS can be trusted), the OS may provide
additional facillities; for instance, Solaris implements "doors" which
can be used for local authentication, openbsd implements "getpeereid"
which can be used to get the euid and egid of an attached unix domain
socket, and darwin implements "mach ports" which contain some related
ideas.  For your amusement; MicroSoft has just obtained a patent which
may cover some or all of this functionality; NT does not have a SUID
concept so depends exclusively on these and other ways to exercise
privilege; apparently MicroSoft believes they invented this technology
(I believe they may have actually stole it from DEC along with the
original NT kernel.)

Having said all that, if you really need to do this, you can certainly
write a small C wrapper that is SUID/SGID, and invokes your particular
perl script.  You probably don't want to do this for anything
where security actually matters.

				-Marcus