The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: torek@torek.net (Chris Torek)
Subject: [TUHS] The evolution of Unix facilities and architecture
Date: Fri, 12 May 2017 18:17:02 -0700	[thread overview]
Message-ID: <201705130117.v4D1H26I087121@elf.torek.net> (raw)
In-Reply-To: Your message of "Fri, 12 May 2017 20:51:43 -0400." <1494636703.1615694.975085000.13626EAC@webmail.messagingengine.com>

>Ah.  There's the other piece.  You start the SUID program under
>the debugger, and rather than kicking off the debugger, it simply
>starts it non-suid.  *However*, in the presence of shared text
>(either of the two cases being checked for in the other place),
>you can make changes to the text image (e.g.  put whatever code
>you want at the entry point), which will be reused the *next*
>time it is started *without* the debugger.

Right.  Some of this was not a problem with demand-paged files
(4.xBSD) since you would not share swap images.  But there's more,
or rather, *was* more, once people added PT_ATTACH and new system
calls or behavior ... specifically, the setreuid / setregid calls
from 4.2BSD or the saved setuid behavior in System V.  This is one
I personally touched.

Suppose a process starts out setuid or setgid.  This means it has
alternative privileges (maybe super-user, maybe not).  With these
it can do things like open some files or transit some directories.
Afterward, using setreuid() and setregid() in 4.2BSD, the process
can swap its real and effective IDs, or give up its effective UID
or GID entirely, to give up its privileges.  So some program
could, for instance, chdir past a "lock" directory -- this was the
MDQS trick -- and now exist in a tree that it had no access to, or
open a file with secrets, that it no longer has permission to
open.

Once a process had given up any special privileges, though, it
could be ptraced again (via PT_ATTACH).  Now you can swap file
descriptor variables around in it, or otherwise make it do bad
things with the privileges it gained while it was setuid.  On
SysV, with "saved setuid", it is even worse: you can make the
process *regain* privileges and do whatever you want.

The fix we used was an extra bit in the process flags: "process
has had or used privileges". Once set (cleared only on exec()),
the process could no longer be ptraced except by root.  Processes
did -- and still do -- have to be careful about files they may
leave open, or other entities that survive exec().  (One should
also consider mmap() and shared regions.)

Chris


  parent reply	other threads:[~2017-05-13  1:17 UTC|newest]

Thread overview: 77+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-13  0:44 Noel Chiappa
2017-05-13  0:51 ` Random832
2017-05-13  0:55   ` Dave Horsfall
2017-05-13  1:17   ` Chris Torek [this message]
2017-05-13 15:25   ` Steve Simon
2017-05-13 16:55     ` Clem Cole
2017-05-13 17:19       ` William Pechter
2017-05-14 12:55         ` Derek Fawcus
2017-05-14 22:12           ` Dave Horsfall
2017-05-15  1:24             ` Nemo
2017-05-15 18:00               ` Steve Johnson
2017-05-16 22:33                 ` Ron Natalie
2017-05-16 23:13                   ` Arthur Krewat
2017-05-16 23:18                     ` Ron Natalie
2017-05-13 23:01     ` Dave Horsfall
     [not found] <mailman.1.1494986402.2329.tuhs@minnie.tuhs.org>
2017-05-19 14:31 ` David
  -- strict thread matches above, loose matches on Subject: below --
2017-05-16 13:20 Noel Chiappa
2017-05-16 13:46 ` Clem Cole
2017-05-14 21:44 Noel Chiappa
2017-05-13  1:25 Noel Chiappa
2017-05-12 23:30 Noel Chiappa
2017-05-12 23:38 ` Dave Horsfall
2017-05-12 23:52   ` Random832
2017-05-13  0:26     ` Dave Horsfall
2017-05-13  0:48       ` Random832
2017-05-13  0:22 ` Clem Cole
2017-05-13  0:23   ` Clem Cole
2017-05-12 18:43 Doug McIlroy
2017-05-12 18:56 ` Dan Cross
2017-05-12 19:43   ` Clem Cole
2017-05-12 20:06     ` Clem Cole
2017-05-12 20:40       ` Jeremy C. Reed
2017-05-12 21:29         ` Clem Cole
2017-05-12 21:29   ` Ron Natalie
2017-05-12 15:12 Noel Chiappa
2017-05-12 15:17 ` Clem Cole
2017-05-12 15:18   ` Clem Cole
2017-05-12 15:46     ` Clem Cole
2017-05-11 17:08 Noel Chiappa
2017-05-11 21:34 ` Dave Horsfall
2017-05-11 14:07 Noel Chiappa
2017-05-11 14:21 ` Larry McVoy
2017-05-11 16:17   ` Clem Cole
2017-05-11 17:11     ` Michael Kjörling
2017-05-11 21:44       ` Dave Horsfall
2017-05-11 22:06         ` Warner Losh
2017-05-12  6:24         ` Hellwig Geisse
2017-05-12 21:12           ` Dave Horsfall
2017-05-12 23:25             ` Hellwig Geisse
2017-05-11 16:15 ` Clem Cole
2017-05-11 16:52   ` Warner Losh
2017-05-11 17:12     ` Clem Cole
2017-05-11 20:37       ` Ron Natalie
2017-05-11 22:25         ` Larry McVoy
2017-05-11 22:30           ` Ron Natalie
2017-05-11 23:47           ` Dave Horsfall
2017-05-11 23:48             ` Ron Natalie
2017-05-12  0:21               ` Larry McVoy
2017-05-12  2:42                 ` Warner Losh
2017-05-12  0:16             ` Larry McVoy
2017-05-12  1:41               ` Wesley Parish
2017-05-12  1:05             ` Toby Thain
2017-05-12  8:17               ` Michael Kjörling
2017-05-12 13:56                 ` Tim Bradshaw
2017-05-12 14:22                   ` Michael Kjörling
2017-05-12 14:30                   ` Larry McVoy
2017-05-12 15:11                     ` Tim Bradshaw
2017-05-12 15:52                     ` Chet Ramey
2017-05-12 16:21                       ` Warner Losh
2017-05-12  8:15             ` Harald Arnesen
2017-05-14  4:30           ` Theodore Ts'o
2017-05-14 17:40             ` Clem Cole
2017-05-10 14:08 Diomidis Spinellis
2017-05-10 14:38 ` Steffen Nurpmeso
2017-05-10 23:09   ` Erik Berls
2017-05-11 12:40     ` Steffen Nurpmeso
2017-05-11  0:49 ` Clem Cole

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201705130117.v4D1H26I087121@elf.torek.net \
    --to=torek@torek.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).