Bug 68905 - [patch] core dumps are assigned wrong ownership
Summary: [patch] core dumps are assigned wrong ownership
Status: In Progress
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: Unspecified
Hardware: Any Any
: Normal Affects Only Me
Assignee: Security Team
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-07-11 03:30 UTC by blake frantz
Modified: 2019-07-03 19:46 UTC (History)
3 users (show)

See Also:


Attachments
kern-sig.diff (844 bytes, patch)
2008-02-16 13:44 UTC, Antoine Brodin
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description blake frantz 2004-07-11 03:30:12 UTC
if a core file owned by a non root user exists and root runs a process
that drops core in the same location, the original core file owned by
the non root user is replaced with root's core dump, except the original
owner maintains ownership of the core.  linux 2.4, 2.6, and obsd operate
in the same manner.  i have not tested other platforms

i do understand that mitigating factors, such as configuring where and
how cores are created, but this doesn't seem right.

How-To-Repeat: trew:~/tmp/q$ ./t
Segmentation fault (core dumped)
trew:~/tmp/q$ md5sum core
90b29a1012aa00c34a18947d98f1b1fb  core
trew:~/tmp/q$ ls -l core
-rw-------    1 trew     users       61440 Jul 10 19:13 core
trew:~/tmp/q$ su
Password:
root:/home/trew/tmp/q# ./t
Segmentation fault (core dumped)
root:/home/trew/tmp/q# md5sum core
371c0748df009ed1da6f189cceff8aca  core
root:/home/trew/tmp/q# ls -l core
-rw-------    1 trew     users       61440 Jul 10 19:13 core
Comment 1 Volker 2008-02-15 18:48:06 UTC
Blake,

I just found your PR has never been touched by anybody. I'm sorry nobody
ever answered this.

If the root touches any file, which already existed before, the file
owner does not change. This is also the case when using `su' to get
superuser rights.

In your case, the file core has been created by user 'trew' and while
root also writes to that file, it doesn't change file ownership.

I'm seeing this as 'by design' and not a bug. Do you agree to have your
PR being closed?

Thanks!
Comment 2 Mark Linimon freebsd_committer freebsd_triage 2008-02-15 22:21:40 UTC
State Changed
From-To: open->feedback

Note that submitter has been asked for feedback.
Comment 3 Volker 2008-02-15 23:49:45 UTC
Sometimes it's good to have more than two eyes looking at something...

antoine@ pointed out, that this has already been figured out to be an
issue in the Linux kernel. I haven't seen that fact in the first place
but have checked current kernel sources and figured out, this is really
an issue. secteam@ has been contacted.

Blake, thanks for bringing this to attention, even while it hasn't been
noticed for a long time!
Comment 4 Mark Linimon freebsd_committer freebsd_triage 2008-02-16 00:56:44 UTC
State Changed
From-To: feedback->analyzed

Being looked at by Volker Werth.
Comment 5 Antoine Brodin freebsd_committer 2008-02-16 13:44:19 UTC
Here is a patch, not much tested and obtained from OpenBSD.
Comment 6 Antoine Brodin freebsd_committer 2008-02-16 14:20:18 UTC
replying to myself, this patch is probably wrong when acls are used...
Comment 7 Volker 2008-02-16 18:57:02 UTC
Antoine,

as I noted in an internal message to secteam, I think the correct
solution is to just unlink a previous existing core dump and then
proceed regular.
Comment 8 Remko Lodder freebsd_committer 2008-02-17 08:08:07 UTC
Responsible Changed
From-To: freebsd-bugs->secteam

reassign to secteam.
Comment 9 Konstantin Belousov freebsd_committer 2018-01-02 11:38:43 UTC
I considered the patch attached, also I looked at the NetBSD handling of this situation.  IMO the patch is fine, but also I do not see a need to avoid writing core into other-readable files.  Lets do it same as NetBSD: if core file exists and its owner is not the real user of the process, do not dump.
Comment 10 commit-hook freebsd_committer 2019-06-23 18:35:47 UTC
A commit references this bug:

Author: kib
Date: Sun Jun 23 18:35:11 UTC 2019
New revision: 349320
URL: https://svnweb.freebsd.org/changeset/base/349320

Log:
  coredump: avoid writing to core files not owned by the real user.

  Reported by: blake frantz <trew@hick.org>
  PR:	68905
  admbugs:	358
  Sponsored by:	The FreeBSD Foundation
  MFC after:	1 week

Changes:
  head/sys/kern/kern_sig.c
Comment 11 commit-hook freebsd_committer 2019-06-23 21:15:52 UTC
A commit references this bug:

Author: kib
Date: Sun Jun 23 21:15:31 UTC 2019
New revision: 349324
URL: https://svnweb.freebsd.org/changeset/base/349324

Log:
  Switch to check for effective user id in r349320, and disable dumping
  into existing files for sugid processes.

  Despite using real user id pronounces the intent, it actually breaks
  suid coredumps, while not making any difference for non-sugid
  processes.  The reason for the breakage is that non-existent core file
  is created with the effective uid (unless weird hacks like SUIDDIR are
  configured).

  Then, if user enabled kern.sugid_coredump, core dumping should not
  overwrite core files owned by effective uid, but we cannot pretend to
  use real uid for dumping.

  PR:	68905
  admbugs:	358
  Sponsored by:	The FreeBSD Foundation
  MFC after:	1 week

Changes:
  head/sys/kern/kern_sig.c
Comment 12 commit-hook freebsd_committer 2019-07-03 19:35:04 UTC
A commit references this bug:

Author: kib
Date: Wed Jul  3 19:34:18 UTC 2019
New revision: 349687
URL: https://svnweb.freebsd.org/changeset/base/349687

Log:
  MFC r349320, r349324:
  coredump: avoid writing to core files not owned by the effective user.

  PR:	68905
  admbugs:	358

Changes:
_U  stable/12/
  stable/12/sys/kern/kern_sig.c
Comment 13 commit-hook freebsd_committer 2019-07-03 19:46:17 UTC
A commit references this bug:

Author: kib
Date: Wed Jul  3 19:46:06 UTC 2019
New revision: 349689
URL: https://svnweb.freebsd.org/changeset/base/349689

Log:
  MFC r349320, r349324:
  coredump: avoid writing to core files not owned by the effective user.

  PR:	68905
  admbugs:	358

Changes:
_U  stable/11/
  stable/11/sys/kern/kern_sig.c