Re: [patch] let CONFIG_SECCOMP default to n

Re: [patch] let CONFIG_SECCOMP default to n

[Albert Cahalan]

Linus Torvalds writes:

> I don't think SECCOMP is wrong per se, but I do believe that
> if other approaches become more popular, and the only user of
> SECCOMP is not GPL'd and uses some patented stuff, then we should
> seriously look at the other interfaces (eg the extended ptrace).
>
> Does anybody actually really _use_ SECCOMP outside of the
> patented stuff?

I write debugger code. I can not possibly express how broken
the ptrace interface is. There are numerous corner conditions
that it gets terribly wrong. If you single step over any
"interesting" instructions, if the target plays funny games
with signals or the trap flag...

The utrace stuff offers some hope for eventually fixing this
mess. Please accept that or something similar.

As for SECCOMP... non-root users need high-performance ways
to sandbox things. I do not believe that one solution fits all.
Perhaps SE Linux could be extended to let users sub-divide
their accounts, and certainly ptrace could be made better.

SECCOMP is a good idea, but currently a tad too limiting.
There are a few dozen system calls that would be safe and useful,
particularly those related to signals, memory, and synchronization.

I see no reason to have a config option outside of
CONFIG_EMBEDDED. Ditch the TSC stuff though.

Re: utrace vs. ptrace

[Ingo Molnar]

* Albert Cahalan <acahalan@gmail.com> wrote:

> The utrace stuff offers some hope for eventually fixing this mess. 
> Please accept that or something similar.

yeah. Much of the API and usage problems of ptrace stem from its (mostly 
artificial) coupling to signals (and other, mostly historical baggage).

utrace gets rid of all of that baggage and artificial coupling! The 
utrace patchset first rips out all of ptrace (completely!), then adds 
utrace (which is in essence the CPU state fiddling bits of ptrace), then 
adds the ptrace API as an utrace module. It really doesnt get cleaner 
than that. See:

  http://people.redhat.com/roland/utrace/0-intro.txt

and:

  http://people.redhat.com/roland/utrace/

for the actual code.

utrace enables exciting things like a global crash-handling daemon that 
can collect live info from crashing (segfaulting) apps transparently, 
_without_ having all apps in the system ptraced in advance!

One of the biggest QA problems Linux has is that we very frequently lose 
information about the 'first incidence of crashing'. [Some of the GUIs 
have automatic crash-reporting, but those solutions are obviously 
limited to those GUIs and they dont use ptrace and have various 
shortcomings.]

utrace enables something like 'transparent live debugging': an app 
crashes in your distro, a window pops up, and you can 'hand over' a 
debugging session to a developer you trust. Or you can instruct the 
system to generate a coredump. Or you can generate a shorter summary of 
the crash, sent to a central site.

utrace enables the distro to automatically (and transparently) download 
debuginfo packages of an app that segfaults so that next time the crash 
happens there's better info to debug it - without the user having to 
bother about this.

utrace enables multiple debugging infrastructures being attached to the 
same task.

and last but not least, utrace enables the prototyping of debuging 
infrastructure without having to revamp the kernel APIs all the time.

Even if i wanted i couldnt over-hype utrace: it is by far the most 
important thing that happened to ptrace (and Linux debugging in general) 
in the past 10 years or so.

	Ingo

Re: utrace vs. ptrace

[Ingo Molnar]

* Ingo Molnar <mingo@elte.hu> wrote:

> utrace enables something like 'transparent live debugging': an app 
> crashes in your distro, a window pops up, and you can 'hand over' a 
> debugging session to a developer you trust. Or you can instruct the 
> system to generate a coredump. Or you can generate a shorter summary 
> of the crash, sent to a central site.

not to mention that utrace could be used to move most of the ELF 
coredumping code out of the kernel. (the moment you have access to all 
crashed threads userspace can construct its own coredump - instead of 
having the kernel construct a coredump file) Roland's patch does not go 
as far yet, but it could be a possible target.

	Ingo

Re: utrace vs. ptrace

[Andi Kleen]

On Thursday 13 July 2006 11:24, Ingo Molnar wrote:
> * Ingo Molnar <mingo@elte.hu> wrote:
> > utrace enables something like 'transparent live debugging': an app
> > crashes in your distro, a window pops up, and you can 'hand over' a
> > debugging session to a developer you trust. Or you can instruct the
> > system to generate a coredump. Or you can generate a shorter summary
> > of the crash, sent to a central site.
>
> not to mention that utrace could be used to move most of the ELF
> coredumping code out of the kernel. (the moment you have access to all
> crashed threads userspace can construct its own coredump - instead of
> having the kernel construct a coredump file) Roland's patch does not go
> as far yet, but it could be a possible target.

I'm not sure that's particularly useful (I think I would prefer to keep
it in kernel), but executing a program when a core dump happens is useful with 
lots of applications.  I had patches for this
that i should probably submit at some point.


-Andi

> 	Ingo

Re: utrace vs. ptrace

[Ingo Molnar]

* Andi Kleen <ak@suse.de> wrote:

> On Thursday 13 July 2006 11:24, Ingo Molnar wrote:
> > * Ingo Molnar <mingo@elte.hu> wrote:
> > > utrace enables something like 'transparent live debugging': an app
> > > crashes in your distro, a window pops up, and you can 'hand over' a
> > > debugging session to a developer you trust. Or you can instruct the
> > > system to generate a coredump. Or you can generate a shorter summary
> > > of the crash, sent to a central site.
> >
> > not to mention that utrace could be used to move most of the ELF
> > coredumping code out of the kernel. (the moment you have access to all
> > crashed threads userspace can construct its own coredump - instead of
> > having the kernel construct a coredump file) Roland's patch does not go
> > as far yet, but it could be a possible target.
> 
> I'm not sure that's particularly useful (I think I would prefer to 
> keep it in kernel), [...]

why would we want to keep this in the kernel? Coredumping in the kernel 
is fragile, and it's nowhere near performance-critical to really live 
within the kernel.

	Ingo

Re: utrace vs. ptrace

[Andi Kleen]

> > I'm not sure that's particularly useful (I think I would prefer to 
> > keep it in kernel), [...]
> 
> why would we want to keep this in the kernel? Coredumping in the kernel 
> is fragile, and it's nowhere near performance-critical to really live 
> within the kernel.

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.

That said extended core dumping (e.g. automatic processing of the output) 
in user space makes sense. I had a prototype for that once that uploaded
a simple crash report to a web page.

-Andi

Re: utrace vs. ptrace

[Arjan van de Ven]

> That said extended core dumping (e.g. automatic processing of the output) 
> in user space makes sense. I had a prototype for that once that uploaded
> a simple crash report to a web 

the script I use for that is at
http://www.fenrus.org/bt.sh

it tries to include things like rpm versions of the package it was in
etc, and suggests/downloads the right debuginfo rpms to improve the
backtrace. Clearly that's all userspace stuff; but it can run from a
daemon easily; eg have all core dumps go to a special directory where
the daemon reaps them and analyzes.

Re: utrace vs. ptrace

[Andi Kleen]

On Thursday 13 July 2006 15:28, Arjan van de Ven wrote:
> 
> > That said extended core dumping (e.g. automatic processing of the output) 
> > in user space makes sense. I had a prototype for that once that uploaded
> > a simple crash report to a web 
> 
> the script I use for that is at
> http://www.fenrus.org/bt.sh
> 
> it tries to include things like rpm versions of the package it was in
> etc, and suggests/downloads the right debuginfo rpms to improve the
> backtrace. Clearly that's all userspace stuff; but it can run from a
> daemon easily; eg have all core dumps go to a special directory where
> the daemon reaps them and analyzes.

You can't do that right now because core_pattern doesn't support slashes.
The coredumps will be always all over the fs or not be there at all
if the cwd is write protected.

In my patch I allowed pipes and piped the coredump into a user space
processor that generated a simple report using gdb and sent it off.

The web frontend then did some statistics on what crashed most.

-Andi

Re: utrace vs. ptrace

[Arjan van de Ven]

On Thu, 2006-07-13 at 15:34 +0200, Andi Kleen wrote:
> On Thursday 13 July 2006 15:28, Arjan van de Ven wrote:
> > 
> > > That said extended core dumping (e.g. automatic processing of the output) 
> > > in user space makes sense. I had a prototype for that once that uploaded
> > > a simple crash report to a web 
> > 
> > the script I use for that is at
> > http://www.fenrus.org/bt.sh
> > 
> > it tries to include things like rpm versions of the package it was in
> > etc, and suggests/downloads the right debuginfo rpms to improve the
> > backtrace. Clearly that's all userspace stuff; but it can run from a
> > daemon easily; eg have all core dumps go to a special directory where
> > the daemon reaps them and analyzes.
> 
> You can't do that right now because core_pattern doesn't support slashes.
> The coredumps will be always all over the fs or not be there at all
> if the cwd is write protected.

are you sure? I had this working in the 2.6.9 timeframe, I could set
core pattern to /tmp/corefiles/core and such just fine..
(and the core files ended up in the /tmp/corefiles/ directory as well)

Re: utrace vs. ptrace

[Andi Kleen]

> are you sure? I had this working in the 2.6.9 timeframe, I could set
> core pattern to /tmp/corefiles/core and such just fine..
> (and the core files ended up in the /tmp/corefiles/ directory as well)

Hmm, yes maybe it has changed. When I tried it originally (which was before 2.6.9)
it didn't work

-Andi

Re: utrace vs. ptrace

[Linus Torvalds]

On Thu, 13 Jul 2006, Andi Kleen wrote:

> 
> > > I'm not sure that's particularly useful (I think I would prefer to 
> > > keep it in kernel), [...]
> > 
> > why would we want to keep this in the kernel? Coredumping in the kernel 
> > is fragile, and it's nowhere near performance-critical to really live 
> > within the kernel.
> 
> 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.

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.

		Linus

Re: utrace vs. ptrace

[Ingo Molnar]

* 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

Re: utrace vs. ptrace

[Paul Jackson]

Ingo wrote:
> 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".

Reading this brought to mind the 'user exit' hooks that are common
in IBM's mainframe O.S.'s.

Their system code does what system code does (and likely a whole lot
more than Linux would consider doing.)  But they also provide many
places for user level code to get called off a variety of hooks,
to allow for special cases.

I had fantasies of our core dumping code using call_usermodehelper()
to call a user command by a well known path, passing it the pid of
the corpse.  While waiting for the user command to exit, the kernel
would accept non-default core dump settings via special /sys or /proc
files for that pid.  The user mode helper command could set these
options before returning (by exiting) to the kernel for the core dump
to be processed.  By default, the user command would do nothing but
exit and the core dump would proceed as it does now.

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@sgi.com> 1.925.600.0401

Re: utrace vs. ptrace

[Alan Cox]

On Iau, 2006-07-13 at 12:05 -0700, Linus Torvalds wrote:
> Doing core-dumping in user space would be insane. It doesn't give _any_ 
> advantages, only disadvantages.

It has a number of very real advantages in certain circumstances and the
only interface the kernel needs to provide is the debugger interface and
something to "kick" the debugger and reparent to it, or for that matter
it might even be viable just to pass the helper the fd of an anonymous
file holding the dump.

Taking out the kernel core dump support would be insane.

We get customers who like to collect/process/do clever stuff with core
dumps and failure cases. We also get people who want to dump a core that
excludes the 14GB shared mmap of the database file as another example
where it helps.

Alan

Re: utrace vs. ptrace

[Linus Torvalds]

On Tue, 25 Jul 2006, Alan Cox wrote:
>
> On Iau, 2006-07-13 at 12:05 -0700, Linus Torvalds wrote:
> > Doing core-dumping in user space would be insane. It doesn't give _any_ 
> > advantages, only disadvantages.
> 
> It has a number of very real advantages in certain circumstances and the
> only interface the kernel needs to provide is the debugger interface and
> something to "kick" the debugger and reparent to it, or for that matter
> it might even be viable just to pass the helper the fd of an anonymous
> file holding the dump.

What you're talking about is not core-dumping, it's just an extended 
debugging interface. And it eeds to be _damn_ careful, exactly because it 
tends to be something very security-sensitive.

> Taking out the kernel core dump support would be insane.

Indeed.

> We get customers who like to collect/process/do clever stuff with core
> dumps and failure cases. We also get people who want to dump a core that
> excludes the 14GB shared mmap of the database file as another example
> where it helps.

"ptrace" certainly isn't wondeful.

What you often want is not a core-dump at all, but a "stop the process" 
thing. It's really irritating that the core-dump is generated and the 
process is gone, when it would often be a lot nicer if instead of 
core-dumping, the process was just stopped and then you could attach to it 
with gdb, and get the whole damn information (including things like access 
to open file descriptors etc).

But again, that has nothing to do with core-dumping. 

			Linus

Re: utrace vs. ptrace

[Olaf Hering]

 On Tue, Jul 25, Linus Torvalds wrote:

> What you often want is not a core-dump at all, but a "stop the process" 
> thing. It's really irritating that the core-dump is generated and the 
> process is gone, when it would often be a lot nicer if instead of 
> core-dumping, the process was just stopped and then you could attach to it 
> with gdb, and get the whole damn information (including things like access 
> to open file descriptors etc).
> 
> But again, that has nothing to do with core-dumping. 

It would be helpful to have that sort of functionality in mainline.
Would a patch be acceptable that sends SIGSTOP instead of SIGSEGV or
SIGILL if some knob was enabled, either global or per process?

Re: utrace vs. ptrace

[Ingo Molnar]

* Olaf Hering <olh@suse.de> wrote:

>  On Tue, Jul 25, Linus Torvalds wrote:
> 
> > What you often want is not a core-dump at all, but a "stop the process" 
> > thing. It's really irritating that the core-dump is generated and the 
> > process is gone, when it would often be a lot nicer if instead of 
> > core-dumping, the process was just stopped and then you could attach to it 
> > with gdb, and get the whole damn information (including things like access 
> > to open file descriptors etc).
> > 
> > But again, that has nothing to do with core-dumping. 
> 
> It would be helpful to have that sort of functionality in mainline. 
> Would a patch be acceptable that sends SIGSTOP instead of SIGSEGV or 
> SIGILL if some knob was enabled, either global or per process?

FYI, the sample utrace module from Roland does precisely that, it stops 
a task on crash... See more at:

  http://people.redhat.com/roland/utrace/

- crash-suspend.c is the sample module.

- ntrace-0.0.2.tar.bz2 is an extensive ptrace and utrace functionality 
  testsuite.

	Ingo

Re: utrace vs. ptrace

[Martin Bligh]

Alan Cox wrote:
> On Iau, 2006-07-13 at 12:05 -0700, Linus Torvalds wrote:
> 
>>Doing core-dumping in user space would be insane. It doesn't give _any_ 
>>advantages, only disadvantages.
> 
> 
> It has a number of very real advantages in certain circumstances and the
> only interface the kernel needs to provide is the debugger interface and
> something to "kick" the debugger and reparent to it, or for that matter
> it might even be viable just to pass the helper the fd of an anonymous
> file holding the dump.
> 
> Taking out the kernel core dump support would be insane.
> 
> We get customers who like to collect/process/do clever stuff with core
> dumps and failure cases. We also get people who want to dump a core that
> excludes the 14GB shared mmap of the database file as another example
> where it helps.

The in-kernel core dumper also seems to hold locks that wedge access
to /proc for that pid, which causes anything walking /proc to wedge.
For large core dumps, that takes far too long, and causes us real
problems

M.

Re: [patch] let CONFIG_SECCOMP default to n

[andrea]

Hello,

On Thu, Jul 13, 2006 at 01:43:42AM -0400, Albert Cahalan wrote:
> SECCOMP is a good idea, but currently a tad too limiting.
> There are a few dozen system calls that would be safe and useful,
> particularly those related to signals, memory, and synchronization.

malloc/free can be emulated in userland so that's not a big
problem. All the rest is a problem instead, unmodified software just
won't run.

seccomp mode 1 is the absolute minimum you need to compute ;). Every
single syscall we add it gets less secure. Several exploits happened
in mremap for example, even if at first glance it may sound a safe
syscall. It's safe now, but it may get buggy again later as new
features are being added.

I'd be skeptical adding seccomp mode 2 with more syscalls, otherwise
it's better to make it more flexible and to specify the syscalls to
allow from userland (which I'm not against if you've usages for it).

>From my part to go beyond seccomp, as jail for the interpreters I'll
probably use virtualization like ourgrid and tycoon (seccomp is the
safest and simplest mode but there's simply no way to run an
interpreter under it ;).