The Unix Heritage Society mailing list
 help / Atom feed
* [TUHS] Set-uid shell scripts
@ 2019-08-04  7:36 Dave Horsfall
  2019-08-04  7:43 ` Alec Muffett
  2019-08-04  7:46 ` arnold
  0 siblings, 2 replies; 27+ messages in thread
From: Dave Horsfall @ 2019-08-04  7:36 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

Is it just me, or did someone actually implement set-uid scripts?  I've 
proposed some silly things over the decades (my favourite is stty() 
working on things other than terminals, and guess what, we got ioctl() 
etc) but I have a vague recollection of this...

The trouble is, I've worked with dozens of Unix-based vendors over the 
years (some good, some not so much) and so I've lost track of all the 
stupidity that I've seen.

ObAnecdote: Just about every Unix vendor went belly-up shortly after I 
left them (under various circumstances), because the waste-of-space middle 
managers simply did not appreciate the importance of having a Unix guru 
on board if you're in the game of selling Unix boxen.

I'd happily name them, but I think the principals are still alive :-)

-- Dave

^ permalink raw reply	[flat|nested] 27+ messages in thread
* Re: [TUHS] Set-uid shell scripts
@ 2019-08-04 20:18 jnc
  2019-08-04 20:29 ` Clem Cole
  2019-08-04 23:58 ` Dave Horsfall
  0 siblings, 2 replies; 27+ messages in thread
From: jnc @ 2019-08-04 20:18 UTC (permalink / raw)
  To: tuhs; +Cc: jnc

    > From: Alec Muffett

    >>>  ln -s /bin/scriptname ./-i
    >>>  "-i" # assuming that "." is already in your path

'scriptname' (above) would have to be a shell script which was SETUID root?
That was part of what I was missing, along with the below.

    > The cited filename is passed as argv[1]

I wonder why it passed the link name, instead of the actual filename of the
target (script)? Perhaps to allow one script to have multiple functions,
depending on the name it was called with? But that could have been done with
hard links? (Adding a hard link must require write access, because the link
count in the inode has to be updated? So it would be equally secure as not
having an SUID program with write access.)

Part of the problem is having the kernel involved in starting shell scripts;
convenient in some ways, but V6 etc worked fine without that 'feature'.

       Noel

^ permalink raw reply	[flat|nested] 27+ messages in thread
* Re: [TUHS] Set-uid shell scripts
@ 2019-08-04 21:18 Norman Wilson
  0 siblings, 0 replies; 27+ messages in thread
From: Norman Wilson @ 2019-08-04 21:18 UTC (permalink / raw)
  To: tuhs

Noel Chiappa:

  I wonder why it passed the link name, instead of the actual filename of the
  target (script)? Perhaps to allow one script to have multiple functions,
  depending on the name it was called with?

====

In fact the latter is still used here and there in standard
system distributions.

But from a security viewpoint it doesn't matter.  For

	ln -s /bin/scriptname ./-i

substitute

	execl("/bin/scriptname", "-i", (char *)0);

If you can execute a program, you can fake its arguments,
including argv[0].  There is no defence.

Norman Wilson
Toronto ON

^ permalink raw reply	[flat|nested] 27+ messages in thread
* Re: [TUHS] Set-uid shell scripts
@ 2019-08-04 21:27 Norman Wilson
  2019-08-06  8:28 ` jason-tuhs
  0 siblings, 1 reply; 27+ messages in thread
From: Norman Wilson @ 2019-08-04 21:27 UTC (permalink / raw)
  To: tuhs

Oops.  Didn't think it through: the problem is argv[1],
passed as the name of the script being executed, not
argv[0].  Disregard my previous execl(...).

A related problem is the inherent race condition:
If you do
	ln -s /bin/setuidscript .
	./setuidscript
./setuidscript is opened twice: once when the kernel
reads it and finds #! as magic number and execs the
interpreter, a second time when the interpreter opens
./setuidscript.  If you meanwhile run something that
swoops in in the background and replaces ./setuidscript
with malicious instructions for the interpreter, you
win.

I remember managing to do this myself at one point in
the latter part of the 1980s.  That was when I fell
out of love with setuid interpreter scripts.

It looks like we didn't disable the danger in the
Research kernel, though.  I don't remember why not.

Norman Wilson
Toronto ON

^ permalink raw reply	[flat|nested] 27+ messages in thread
* Re: [TUHS] Set-uid shell scripts
@ 2019-08-05  0:13 jnc
  0 siblings, 0 replies; 27+ messages in thread
From: jnc @ 2019-08-05  0:13 UTC (permalink / raw)
  To: tuhs; +Cc: jnc

    > From: Dave Horsfall

    > Well, it's in the Subject: line :-)

That was my _assumption_, but you know the old line about assumptions.

     Noel

^ permalink raw reply	[flat|nested] 27+ messages in thread

end of thread, back to index

Thread overview: 27+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-08-04  7:36 [TUHS] Set-uid shell scripts Dave Horsfall
2019-08-04  7:43 ` Alec Muffett
2019-08-04 15:58   ` jnc
2019-08-04 16:30     ` Michael Kjörling
2019-08-04 16:48       ` Alec Muffett
2019-08-04 17:48         ` Michael Kjörling
2019-08-04 19:45           ` Alec Muffett
2019-08-04 16:50     ` Rico Pajarola
2019-08-04  7:46 ` arnold
2019-08-04 20:18 jnc
2019-08-04 20:29 ` Clem Cole
2019-08-04 20:42   ` Richard Salz
2019-08-04 23:58 ` Dave Horsfall
2019-08-04 21:18 Norman Wilson
2019-08-04 21:27 Norman Wilson
2019-08-06  8:28 ` jason-tuhs
2019-08-06  9:55   ` arnold
2019-08-06 22:48   ` Dave Horsfall
2019-08-06 22:56     ` ron minnich
2019-08-07  1:21     ` Dave Horsfall
     [not found]       ` <40c92e85142fe7e3@orthanc.ca>
2019-08-07 21:33         ` Dave Horsfall
2019-08-08  6:39           ` Peter Jeremy
2019-08-07 12:56     ` Chet Ramey
2019-08-07 21:40       ` Dave Horsfall
2019-08-08  5:16         ` Adam Thornton
2019-08-14  5:41           ` Efton Collins
2019-08-05  0:13 jnc

The Unix Heritage Society mailing list

Archives are clonable: git clone --mirror http://inbox.vuxu.org/tuhs

Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.tuhs


AGPL code for this site: git clone https://public-inbox.org/ public-inbox