mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Linus Torvalds <torvalds@osdl.org>
Cc: Andi Kleen <ak@suse.de>, Albert Cahalan <acahalan@gmail.com>,
	alan@lxorguk.ukuu.org.uk, arjan@infradead.org, akpm@osdl.org,
	linux-kernel@vger.kernel.org, Roland McGrath <roland@redhat.com>
Subject: Re: utrace vs. ptrace
Date: Thu, 13 Jul 2006 21:47:35 +0200	[thread overview]
Message-ID: <20060713194735.GA27807@elte.hu> (raw)
In-Reply-To: <Pine.LNX.4.64.0607131203450.5623@g5.osdl.org>


* Linus Torvalds <torvalds@osdl.org> wrote:

> > Mostly because I fear it would become another udev like disaster, 
> > requiring user space updates regularly, and core dumps are a fairly 
> > critical debugging feature that I wouldn't like to become 
> > unreliable.
> 
> Doing core-dumping in user space would be insane. It doesn't give 
> _any_ advantages, only disadvantages.

well, it was just a quick idea of mine that looked nice in the following 
sense: it would reuse (and thus test) debugging infrastructure that we 
want to and have to provide anyway. (if gdb is attached to a task that 
crashes then it is in a position to get all the information to create a 
coredump)

it wouldnt be fundamentally easier - but lots of policy stuff could be 
done there which we would otherwise reject to add to the kernel. Like 
more complex rules for "do we want to dump core for this particular 
app".

> Why do people keep thinking that doing things in user space is "safer" 
> and "easier". It's quite often not. For example, all the "fragile" 
> stuff would be true for a user-space dumper (don't tell me it's safer 
> - it would obviously have to run with elevated capabilities), and a 
> lot of it would be a hell of a lot harder.

It would have to run with privileges enough to 1) get the process/thread 
state [but not set it] 2) to write the resulting coredump to some file.

You are right that if we make it privileged enough to implement #2 as 
"put the coredump into the apps cwd, with the user's identity", that 
would expose this privileged code to similar file-permission security 
problems as the in-kernel dumper.

But if #2 is implemented in a more restricted way (like coredumps only 
go to a central directory not accessible to users, are size-limited, are 
fingerprinted for their backtraces to remove duplicates, are matched to 
an online repository of already reported bugs, etc.) then it could be 
more secure than the in-kernel dumper - just because it would do less. 
(and it would also do more, in a sense)

but ... i agree that it's not an "obvious win", and that it can create a 
less secure solution than the in-kernel dumper. Although the in-kernel 
dumper doesnt have a stellar security track record, so the quality bar 
isnt particularly high :-/

	Ingo

  reply	other threads:[~2006-07-13 19:53 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-07-13  5:43 [patch] let CONFIG_SECCOMP default to n Albert Cahalan
2006-07-13  7:04 ` utrace vs. ptrace Ingo Molnar
2006-07-13  9:24   ` Ingo Molnar
2006-07-13 12:37     ` Andi Kleen
2006-07-13 12:43       ` Ingo Molnar
2006-07-13 13:21         ` Andi Kleen
2006-07-13 13:28           ` Arjan van de Ven
2006-07-13 13:34             ` Andi Kleen
2006-07-13 13:37               ` Arjan van de Ven
2006-07-13 13:46                 ` Andi Kleen
2006-07-13 19:05           ` Linus Torvalds
2006-07-13 19:47             ` Ingo Molnar [this message]
2006-07-14 10:42               ` Paul Jackson
2006-07-25 18:49             ` Alan Cox
2006-07-25 18:27               ` Linus Torvalds
2006-07-25 18:57                 ` Olaf Hering
2006-07-25 19:12                   ` Ingo Molnar
2006-07-26  0:20               ` Martin Bligh
2006-07-13  7:07 ` [patch] let CONFIG_SECCOMP default to n andrea

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=20060713194735.GA27807@elte.hu \
    --to=mingo@elte.hu \
    --cc=acahalan@gmail.com \
    --cc=ak@suse.de \
    --cc=akpm@osdl.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=arjan@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=roland@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®