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

Re: [Sheflug] running as root





> I'm still not sure that there's anything obvious there, but then that's
> probably down to me. I'm afraid I treat shell scripts equivilent to other
> executables, and I would imagine anything you can do with a shell script you
> can replicate with a binary? Seems that way to me, anyway.
> 

The problem with shell scripts is that it uses a whole host of other programs 
which you do not know the security of. Every executable in a shell script is 
a potential security hole - manage to get the script to pass a long enough 
string to a program the shell script uses, and hey bingo you have a root 
shell via a buffer overrun. You have no control over the programs (cat, sed, 
awk, cut, tr, adduser, rpm, ls, &c ...) unless you're going to go through the 
source of each utility and audit it for security. Note that this also means 
that if someone manages to stick a trojan command on that does something it 
shouldn't as well as summat it should (say someone manages to replace "cut" 
with a trojan that does something nasty). Bang.

With a C program, and similarly Perl, there is only ever one interpreter. C 
is built and its all down to the programmer to make sure its secure against 
buffer overruns. Perl scripts are handeled purely by perl unless you spawn a 
external program (ditto C in this case). You don't have any uncontrollable 
external influences. C is very secure unless someone manages to stick a 
trojan compiler on (slim, really, mostly due to the complexity of the task). 
Perl could be easy to trojan, but again its a large task. Taking summat 
simple like "cut", is much easier.

> 
> Seems this is what I have been doing. To be honest, I find this a bit
> strange. Unless there's something implicit in interpretation than make it
> unsafe (and then, why not ban other interpreters?), I don't see why the
> kernel shouldn't honour suid. Other Unixes do, which is probably why I
> thought it would work. I'm going to try it on IRIX and Sunos tomorrow....

See above...

> > This is how I write small one line C things. Longer stuff tends to get the
> > full treatment, so "gcc -Wall" creates no warnings :)
> 
> Yes, that's usually worthwhile. I tried using -ansi and -pedantic once, but
> it complained about good code and passed bad. At least, what I consider to
> be good and bad. Unfortunately I'm not a K&R devotee, so perhaps I'm at a
> disadvantage.... although I agree about tabs and braces ;)
> 

Yep - I do like the K&R tab/brace style. What I hate is what we have to use 
at work...along the lines of:

if (fish)
   {
   puts ("raaa...");
   .
   .
   .
   }
/* rest of code */


> > However, I have read that system() won't work for suid stuff if /bin/sh
> > points to bash greater than version 2...from the man page for system(3):
> 
> What a load of rubbish.....  IMHO ;)) Usually, security stuff doesn't go
> into the kernel when it's patently obvious that it's false security (stack
> traps/trampolines come to mind...), I think I probably must have missed some
> key corner case somewhere...
> 

In this case, this isn't the kernel - system(3) is a libc call, bash is bash 
:) Neither are kernel related. But I don't think ksh and csh do the same 
checks though, and they both don't work.

I can check a Digital UNIX 4.0F box at work tomoz see what that does :) i'll 
also see what my OpenBSD box does, but I'm predicting that will *not* do SUID 
shell scripts.

Chris...




-- 
@}-,'--------------------------------------------------  Chris Johnson --'-{ [at] 
    / "(it is) crucial that we learn the difference / sixie [at] nccnet.co.uk  \
   / between Sex and Gender. Therein lies the key  /                       \ 
  / to our freedom" -- LB                         / www.nccnet.co.uk/~sixie \ 


---------------------------------------------------------------------
Sheffield Linux User's Group - http://www.sheflug.co.uk
To unsubscribe from this list send mail to
- <sheflug-request [at] vuw.ac.nz> - with the word 
 "unsubscribe" in the body of the message. 

  GNU the choice of a complete generation.