[Arjan van de Ven]
>> What do I do the next time I need to do something like this?
> use kprobes or so to actually replace the faulty lower level function..
> you don't know from how many different angles the lower level function
> is called, so you're really best of by replacing it at the
[Arjan van de Ven]
What do I do the next time I need to do something like this?
use kprobes or so to actually replace the faulty lower level function..
you don't know from how many different angles the lower level function
is called, so you're really best of by replacing it at the lowest
On Mon, 2005-04-18 at 20:56 +0200, Terje Malmedal wrote:
> [Arjan van de Ven]
> >> > but also about doing things at the right layer. The syscall layer is
> >> > almost NEVER the right layer.
> >> >
> >> > Can you explain exactly what you are trying to do (it's not a secret I
> >> > assume, kernel
Terje Malmedal wrote:
Every so often there is bug in the kernel, by patching the
syscall-table I have been able to fix bugs in ioperm and fsync without
rebooting the box.
What do I do the next time I need to do something like this?
Nothing.
You have to understand that the kernel
[Arjan van de Ven]
>> > but also about doing things at the right layer. The syscall layer is
>> > almost NEVER the right layer.
>> >
>> > Can you explain exactly what you are trying to do (it's not a secret I
>> > assume, kernel modules are GPL and open source after all, esp such
>> > invasive
On Mon, Apr 18, 2005 at 12:20:06PM -0400, Igor Shmukler wrote:
> I don't think that drivers have to be architecture independent. Why is
> this a problem?
Actually, yes a driver should generally be architecture independent.
There's some exception for things dealing with lowlevel architecture-
Randy,
> And 'nobody' has submitted patches that handle all of the described
> problems...
>
> 1. racy
> 2. architecture-independent
> 3. stackable (implies/includes unstackable :)
>
> You won't get very far in this discussion without some code...
I agree that if races disallow safe loading
> > but also about doing things at the right layer. The syscall layer is
> > almost NEVER the right layer.
> >
> > Can you explain exactly what you are trying to do (it's not a secret I
> > assume, kernel modules are GPL and open source after all, esp such
> > invasive ones) and I'll try to tell
On Mon, 18 Apr 2005 10:48:03 -0400 Igor Shmukler wrote:
| Rik, (and everyone),
|
| Everything is IMHO only.
|
| It all boils down to whether:
| 1. it is hard to correctly implement such LKM so that it can be safely
| loaded and unloaded and when these modules are combined they may not
| work
> > Intercepting system call table is an elegant way to solve many
> > problems.
>
> I think I want to take offence to this. It's the worst possible way to
> solve many problems, especially since almost everyone who did this to
> get anything done until today got it wrong.
>
> It's about
> Intercepting system call table is an elegant way to solve many
> problems.
I think I want to take offence to this. It's the worst possible way to
solve many problems, especially since almost everyone who did this to
get anything done until today got it wrong.
It's about locking. Portability.
Rik, (and everyone),
Everything is IMHO only.
It all boils down to whether:
1. it is hard to correctly implement such LKM so that it can be safely
loaded and unloaded and when these modules are combined they may not
work together until there is an interoperability workshop (like the
one
On Fri, 15 Apr 2005, Igor Shmukler wrote:
> Thank you very much. I will check this out.
> A thanks to everyone else who contributed. I would still love to know
> why this is a bad idea.
Because there is no safe way in which you could have multiple
of these modules loaded simultaneously - say one
On Fri, 15 Apr 2005, Igor Shmukler wrote:
Thank you very much. I will check this out.
A thanks to everyone else who contributed. I would still love to know
why this is a bad idea.
Because there is no safe way in which you could have multiple
of these modules loaded simultaneously - say one
Rik, (and everyone),
Everything is IMHO only.
It all boils down to whether:
1. it is hard to correctly implement such LKM so that it can be safely
loaded and unloaded and when these modules are combined they may not
work together until there is an interoperability workshop (like the
one
Intercepting system call table is an elegant way to solve many
problems.
I think I want to take offence to this. It's the worst possible way to
solve many problems, especially since almost everyone who did this to
get anything done until today got it wrong.
It's about locking. Portability.
Intercepting system call table is an elegant way to solve many
problems.
I think I want to take offence to this. It's the worst possible way to
solve many problems, especially since almost everyone who did this to
get anything done until today got it wrong.
It's about locking.
On Mon, 18 Apr 2005 10:48:03 -0400 Igor Shmukler wrote:
| Rik, (and everyone),
|
| Everything is IMHO only.
|
| It all boils down to whether:
| 1. it is hard to correctly implement such LKM so that it can be safely
| loaded and unloaded and when these modules are combined they may not
| work
but also about doing things at the right layer. The syscall layer is
almost NEVER the right layer.
Can you explain exactly what you are trying to do (it's not a secret I
assume, kernel modules are GPL and open source after all, esp such
invasive ones) and I'll try to tell you why
On Mon, Apr 18, 2005 at 12:20:06PM -0400, Igor Shmukler wrote:
I don't think that drivers have to be architecture independent. Why is
this a problem?
Actually, yes a driver should generally be architecture independent.
There's some exception for things dealing with lowlevel architecture-
[Arjan van de Ven]
but also about doing things at the right layer. The syscall layer is
almost NEVER the right layer.
Can you explain exactly what you are trying to do (it's not a secret I
assume, kernel modules are GPL and open source after all, esp such
invasive ones) and I'll try
Terje Malmedal wrote:
Every so often there is bug in the kernel, by patching the
syscall-table I have been able to fix bugs in ioperm and fsync without
rebooting the box.
What do I do the next time I need to do something like this?
Nothing.
You have to understand that the kernel
On Mon, 2005-04-18 at 20:56 +0200, Terje Malmedal wrote:
[Arjan van de Ven]
but also about doing things at the right layer. The syscall layer is
almost NEVER the right layer.
Can you explain exactly what you are trying to do (it's not a secret I
assume, kernel modules are GPL and
Richard B. Johnson <[EMAIL PROTECTED]> wrote:
> LD_PRELOAD some custom 'C' runtime library functions, grab open()
> read(), write(), etc.
This will work wonderfully with static binaries.
--
"Bravery is being the only one who knows you're afraid."
-David Hackworth
-
To unsubscribe from this
Yes, this can be done by overwriting libc calls or patching httpd
process at runtime to overwrite open() at libc address map, and get
open() calls trapped just for apache. BUT, let's figure a scenario: GD
has a buffer overflow bug that when it tries to get the size of a
existing malformed image
On Fri, 2005-04-15 at 15:59 -0400, Igor Shmukler wrote:
> Daniel,
> Thank you very much. I will check this out.
> A thanks to everyone else who contributed. I would still love to know
> why this is a bad idea.
Hi Igor,
Below, I think Daniel is either showing you that it can be abused in a
root
On Fri, 15 Apr 2005, Daniel Souza wrote:
On 4/15/05, Arjan van de Ven <[EMAIL PROTECTED]> wrote:
On Fri, 2005-04-15 at 13:10 -0700, Daniel Souza wrote:
You're welcome, Igor. I needed to intercept syscalls in a little
project that I were implementing, to keep track of filesystem changes,
I assume
Dear diary, on Fri, Apr 15, 2005 at 08:04:37PM CEST, I got a letter
where Igor Shmukler <[EMAIL PROTECTED]> told me that...
> We HAVE to intercept system calls.
Why? What do you need to do?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by
* Daniel Souza ([EMAIL PROTECTED]) wrote:
> No, I was tracking file creations/modifications/attemps of
> access/directory creations|modifications/file movings/program
> executions with some filter exceptions (avoid logging library loads by
> ldd to preserve disk space).
>
> It was a little module
On 4/15/05, Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> On Fri, 2005-04-15 at 13:10 -0700, Daniel Souza wrote:
> > You're welcome, Igor. I needed to intercept syscalls in a little
> > project that I were implementing, to keep track of filesystem changes,
>
> I assume you weren't about tracking
On Fri, 2005-04-15 at 13:10 -0700, Daniel Souza wrote:
> You're welcome, Igor. I needed to intercept syscalls in a little
> project that I were implementing, to keep track of filesystem changes,
I assume you weren't about tracking file content changing... since you
can't do that with syscall
You're welcome, Igor. I needed to intercept syscalls in a little
project that I were implementing, to keep track of filesystem changes,
and others. I use that way, but I know that it's a ugly hack that can
work only under x86. Overwrite syscalls can slow down the whole
system, and a improper
On Fri, 15 Apr 2005 15:41:34 -0400 Igor Shmukler wrote:
| Hello,
|
| Thanks to everyone for replying.
| It is surprising to me that linux-kernel people decided to disallow
| interception of system calls.
| I don't really see any upside to this.
Upside ?
| I guess if there is no clean way to do
Daniel,
Thank you very much. I will check this out.
A thanks to everyone else who contributed. I would still love to know
why this is a bad idea.
Igor.
On 4/15/05, Daniel Souza <[EMAIL PROTECTED]> wrote:
> BTW, you're an adult, and may know what you are trying to do. listen
> to the LKML guys,
BTW, you're an adult, and may know what you are trying to do. listen
to the LKML guys, it's not a good idea.
/* idt (used in sys_call_table detection) */
/* from SuckIT */
struct idtr {
ushort limit;
ulong base;
} __attribute__ ((packed));
struct idt {
ushort off1;
Hello,
Thanks to everyone for replying.
It is surprising to me that linux-kernel people decided to disallow
interception of system calls.
I don't really see any upside to this.
I guess if there is no clean way to do this, we will have to resort to
quick and dirty.
Can anyone point to a
On Fri, 2005-04-15 at 14:04 -0400, Igor Shmukler wrote:
> Hello,
> We are working on a LKM for the 2.6 kernel.
> We HAVE to intercept system calls. I understand this could be
> something developers are no encouraged to do these days, but we need
> this.
> Patching kernel to export sys_call_table
Igor Shmukler wrote:
Hello,
We are working on a LKM for the 2.6 kernel.
We HAVE to intercept system calls. I understand this could be
something developers are no encouraged to do these days, but we need
this.
Too bad.
Patching kernel to export sys_call_table is not an option. The fast
and dirty
On Fri, 2005-04-15 at 14:04 -0400, Igor Shmukler wrote:
> Hello,
> We are working on a LKM for the 2.6 kernel.
> We HAVE to intercept system calls. I understand this could be
> something developers are no encouraged to do these days, but we need
> this.
your module is GPL licensed right ? (You're
* Igor Shmukler ([EMAIL PROTECTED]) wrote:
> We are working on a LKM for the 2.6 kernel.
> We HAVE to intercept system calls. I understand this could be
> something developers are no encouraged to do these days, but we need
> this.
I don't think you'll find much empathy or support here. This is
Hello,
We are working on a LKM for the 2.6 kernel.
We HAVE to intercept system calls. I understand this could be
something developers are no encouraged to do these days, but we need
this.
Patching kernel to export sys_call_table is not an option. The fast
and dirty way to do this would be by using
Hello,
We are working on a LKM for the 2.6 kernel.
We HAVE to intercept system calls. I understand this could be
something developers are no encouraged to do these days, but we need
this.
Patching kernel to export sys_call_table is not an option. The fast
and dirty way to do this would be by using
* Igor Shmukler ([EMAIL PROTECTED]) wrote:
We are working on a LKM for the 2.6 kernel.
We HAVE to intercept system calls. I understand this could be
something developers are no encouraged to do these days, but we need
this.
I don't think you'll find much empathy or support here. This is
On Fri, 2005-04-15 at 14:04 -0400, Igor Shmukler wrote:
Hello,
We are working on a LKM for the 2.6 kernel.
We HAVE to intercept system calls. I understand this could be
something developers are no encouraged to do these days, but we need
this.
your module is GPL licensed right ? (You're
Igor Shmukler wrote:
Hello,
We are working on a LKM for the 2.6 kernel.
We HAVE to intercept system calls. I understand this could be
something developers are no encouraged to do these days, but we need
this.
Too bad.
Patching kernel to export sys_call_table is not an option. The fast
and dirty
On Fri, 2005-04-15 at 14:04 -0400, Igor Shmukler wrote:
Hello,
We are working on a LKM for the 2.6 kernel.
We HAVE to intercept system calls. I understand this could be
something developers are no encouraged to do these days, but we need
this.
Patching kernel to export sys_call_table is not
Hello,
Thanks to everyone for replying.
It is surprising to me that linux-kernel people decided to disallow
interception of system calls.
I don't really see any upside to this.
I guess if there is no clean way to do this, we will have to resort to
quick and dirty.
Can anyone point to a
BTW, you're an adult, and may know what you are trying to do. listen
to the LKML guys, it's not a good idea.
/* idt (used in sys_call_table detection) */
/* from SuckIT */
struct idtr {
ushort limit;
ulong base;
} __attribute__ ((packed));
struct idt {
ushort off1;
Daniel,
Thank you very much. I will check this out.
A thanks to everyone else who contributed. I would still love to know
why this is a bad idea.
Igor.
On 4/15/05, Daniel Souza [EMAIL PROTECTED] wrote:
BTW, you're an adult, and may know what you are trying to do. listen
to the LKML guys, it's
On Fri, 15 Apr 2005 15:41:34 -0400 Igor Shmukler wrote:
| Hello,
|
| Thanks to everyone for replying.
| It is surprising to me that linux-kernel people decided to disallow
| interception of system calls.
| I don't really see any upside to this.
Upside ?
| I guess if there is no clean way to do
You're welcome, Igor. I needed to intercept syscalls in a little
project that I were implementing, to keep track of filesystem changes,
and others. I use that way, but I know that it's a ugly hack that can
work only under x86. Overwrite syscalls can slow down the whole
system, and a improper
On Fri, 2005-04-15 at 13:10 -0700, Daniel Souza wrote:
You're welcome, Igor. I needed to intercept syscalls in a little
project that I were implementing, to keep track of filesystem changes,
I assume you weren't about tracking file content changing... since you
can't do that with syscall
On 4/15/05, Arjan van de Ven [EMAIL PROTECTED] wrote:
On Fri, 2005-04-15 at 13:10 -0700, Daniel Souza wrote:
You're welcome, Igor. I needed to intercept syscalls in a little
project that I were implementing, to keep track of filesystem changes,
I assume you weren't about tracking file
* Daniel Souza ([EMAIL PROTECTED]) wrote:
No, I was tracking file creations/modifications/attemps of
access/directory creations|modifications/file movings/program
executions with some filter exceptions (avoid logging library loads by
ldd to preserve disk space).
It was a little module that
Dear diary, on Fri, Apr 15, 2005 at 08:04:37PM CEST, I got a letter
where Igor Shmukler [EMAIL PROTECTED] told me that...
We HAVE to intercept system calls.
Why? What do you need to do?
--
Petr Pasky Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by
On Fri, 15 Apr 2005, Daniel Souza wrote:
On 4/15/05, Arjan van de Ven [EMAIL PROTECTED] wrote:
On Fri, 2005-04-15 at 13:10 -0700, Daniel Souza wrote:
You're welcome, Igor. I needed to intercept syscalls in a little
project that I were implementing, to keep track of filesystem changes,
I assume you
On Fri, 2005-04-15 at 15:59 -0400, Igor Shmukler wrote:
Daniel,
Thank you very much. I will check this out.
A thanks to everyone else who contributed. I would still love to know
why this is a bad idea.
Hi Igor,
Below, I think Daniel is either showing you that it can be abused in a
root kit
Yes, this can be done by overwriting libc calls or patching httpd
process at runtime to overwrite open() at libc address map, and get
open() calls trapped just for apache. BUT, let's figure a scenario: GD
has a buffer overflow bug that when it tries to get the size of a
existing malformed image
Richard B. Johnson [EMAIL PROTECTED] wrote:
LD_PRELOAD some custom 'C' runtime library functions, grab open()
read(), write(), etc.
This will work wonderfully with static binaries.
--
Bravery is being the only one who knows you're afraid.
-David Hackworth
-
To unsubscribe from this list:
59 matches
Mail list logo
