public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Rob Landley <landley@webofficenow.com>
To: Hua Zhong <huaz@cs.columbia.edu>, Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Andries.Brouwer@cwi.nl, andrewm@uow.edu.au,
	torvalds@transmeta.com, tytso@mit.edu,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] more SAK stuff
Date: Tue, 3 Jul 2001 18:00:50 -0400	[thread overview]
Message-ID: <01070318005005.06999@localhost.localdomain> (raw)
In-Reply-To: <200107021910.PAA27951@razor.cs.columbia.edu>
In-Reply-To: <200107021910.PAA27951@razor.cs.columbia.edu>

On Monday 02 July 2001 15:10, Hua Zhong wrote:
> -> From Alan Cox <alan@lxorguk.ukuu.org.uk> :
> > > (a) It does less, namely will not kill processes with uid 0.
> > > Ted, any objections?
> >
> > That breaks the security guarantee. Suppose I use a setuid app to confuse
> > you into doing something ?
>
> a setuid app only changes euid, doesn't it?

Yup.  And you'd be amazed how many fun little user mode things were either 
never tested with the suid bit or obstinately refuse to run for no good 
reason.  (Okay, I made something like a sudo script.  It's in a directory 
that non-root users can't access and I'm being as careful as I know how to 
be, but I've got a cgi that needs root access to query/set system and network 
configuration.)

Off the top of my head, fun things you can't do suid root:

The samba adduser command.  (But I CAN edit the smb.passwd file directly, 
which got me around this.)

su without password (understandable, implementation detail.  It's always 
suid, being run by somebody other than root is how it knows when it NEEDS to 
ask for a password.  But when I want to DROP root privelidges...  Wound up 
making "suid-to" to do it.)

ps  (What the...?  Worked in Red Hat 7, but not in suse 7.1.  Huh?  "suid-to 
apache ps ax" works fine, though...)

dhcpcd (I patched it and yelled at the maintainer of this months ago, should 
be fixed now.  But a clear case of checking uid when he meant euid, which is 
outright PERVASIVE...).

I keep bumping into more of these all the time.  Often it's fun little 
warnings "you shouldn't have the suid bit on this executable", which is 
frustrating 'cause I haven't GOT the suid bit on that executable, it 
inherited it from its parent process, which DOES explicitly set the $PATH and 
blank most of the environment variables and other fun stuff...)

By the way, anybody who knows why samba goes postal if you change the 
hostname of the box while it's running, please explain it to me.  It's happy 
once HUPed, then again it execs itself.  (Not nmbd.  smbd.  Why does it CARE? 
 And sshd has the most amazing timeouts if it can't do a reverse dns lookup 
on the incoming IP, even if I tell it not to log!)

Apache has a similar problem, and HUP-ing it interrupts in-progress 
transfers, which could be very large files, 'cause it execs itself.  I made 
that happy by telling it its host name was a dot notation IP address, 
although that does mean that logging into a password protected web page using 
the host name forces you to log in twice (again when it switches you to 
http://1.2.3.4/blah...)

Fun, isn't it? :)

Alan's right.  We DO need a rant tag.

Rob

  reply	other threads:[~2001-07-05 20:43 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-07-02 12:16 [PATCH] more SAK stuff Andries.Brouwer
2001-07-02 12:33 ` Alan Cox
2001-07-02 19:10   ` Hua Zhong
2001-07-03 22:00     ` Rob Landley [this message]
2001-07-06  1:45       ` Albert D. Cahalan
2001-07-06 10:04         ` The SUID bit (was Re: [PATCH] more SAK stuff) Rob Landley
2001-07-06 15:17           ` Doug McNaught
2001-07-06 15:44             ` Rob Landley
2001-07-02 18:57 ` [PATCH] more SAK stuff Kain
2001-07-06 22:02 ` David Wagner
  -- strict thread matches above, loose matches on Subject: below --
2001-07-02 12:49 Andries.Brouwer
2001-07-02 13:03 Andries.Brouwer

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=01070318005005.06999@localhost.localdomain \
    --to=landley@webofficenow.com \
    --cc=Andries.Brouwer@cwi.nl \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=andrewm@uow.edu.au \
    --cc=huaz@cs.columbia.edu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@transmeta.com \
    --cc=tytso@mit.edu \
    /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