All of lore.kernel.org
 help / color / mirror / Atom feed
From: Albert Cahalan <albert@users.sf.net>
To: "Peter Wächtler" <pwaechtler@mac.com>
Cc: Albert Cahalan <albert@users.sourceforge.net>,
	linux-kernel mailing list <linux-kernel@vger.kernel.org>,
	Andrew Morton OSDL <akpm@osdl.org>,
	Linus Torvalds <torvalds@osdl.org>
Subject: Re: [PATCH] coredump - as root not only if euid switched
Date: 23 Apr 2004 13:22:23 -0400	[thread overview]
Message-ID: <1082740942.3450.699.camel@cube> (raw)
In-Reply-To: <1082747589.2710.100.camel@picklock.adams.family>

On Fri, 2004-04-23 at 15:14, Peter Wächtler wrote:
> Am Fr, 2004-04-23 um 17.35 schrieb Albert Cahalan:
> > > While it's more secure to not dump core at all if the
> > > program has switched euid, it's also very unpractical.
> > > Since only programs started from root, being setuid
> > > root or have CAP_SETUID it's far more practical to
> > > dump as root.root mode 600. This is the bahavior 
> > > of Solaris.
> > 
> > Solaris can keep their security holes.
> > 
> 
> I checked (older) versions on
> 
> HP-UX, True64, AiX, MacOsX
> 
> HP-UX didn't dump core on a seteuid 0->n prog
> Aix,MacOsX and True64 dumped core with ownership of user
> I could check Irix

It would be nice of you to do so, then issue some
sort of security alert.

> > Consider a setuid core dump on removable media which
> > is user-controlled.
> 
> boot into rescue system...

If you're suggesting that user-controlled media implies
the ability to boot via that media, you're very wrong.

a. LinuxBIOS
b. OpenFirmware (Mac or Sun) with boot password
c. no floppy, and a Zip drive on BIOS-disabled SCSI
d. parallel port Zip drive
e. FireWire w/o BIOS support

(the "rip computer open" option is either physically
blocked or there is a human nearby that would notice)

> > Also consider filesystems that don't store full security
> > data, like vfat and smb/cifs.
> > 
> > Core dumps to remote filesystems are a problem in
> > general, because the server might not implement the
> > type of security you expect it to implement.
> > 
> 
> mkdir /var/cores
> chmod a+rwx,o+t /var/cores
> echo /var/cores/%e.core.%p > /proc/sys/kernel/core_pattern

Sure, but you shouldn't assume that all admins know
to do this. The default must be secure.

> > Here's a better idea: add a sysctl for insecure core
> > dumps. When set, dump all cores as root.root mode 444.
> > Ignore directory permissions when doing so, so that
> > forcing dumps into a MacOS-style /cores directory does
> > not require that users be able to access it normally.
> > This lets appropriately authorized users debug setuid
> > apps and get support for them without adding security
> > holes like Solaris has.
> 
> It's tunable via coreadm
> 
> troll, troll

You said "This is the bahavior of Solaris." and I took
that for the truth. Now you say it's tunable. Well, OK
then, so Solaris _doesn't_ have an insecure config as
it comes from Sun? I have no problem with supporting an
insecure config, but you were suggesting that it would
be the new default (and only) behavior.





  reply	other threads:[~2004-04-23 19:44 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-04-23 15:35 [PATCH] coredump - as root not only if euid switched Albert Cahalan
2004-04-23 19:14 ` Peter Wächtler
2004-04-23 17:22   ` Albert Cahalan [this message]
  -- strict thread matches above, loose matches on Subject: below --
2004-04-23  7:46 Peter Waechtler
2004-04-23  7:16 Peter Waechtler
2004-04-23 17:10 ` Chris Wright
2004-04-23 19:05   ` Peter Wächtler
2004-04-23  7:14 Peter Waechtler
2004-04-22  9:40 Peter Waechtler
2004-04-22  9:56 ` Andrew Morton
2004-04-22 19:43   ` Peter Wächtler
2004-04-22 19:53     ` Chris Wright
2004-04-22 20:05     ` Linus Torvalds
2004-04-22  8:51 Peter Waechtler
2004-04-22  8:55 ` Andrew Morton
2004-04-21 19:20 Peter Wächtler
2004-04-22  1:18 ` Andrew Morton

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=1082740942.3450.699.camel@cube \
    --to=albert@users.sf.net \
    --cc=akpm@osdl.org \
    --cc=albert@users.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pwaechtler@mac.com \
    --cc=torvalds@osdl.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.