On Fri, Aug 17, 2007 at 10:19:00AM -0400, Dave Jones wrote:
> On Wed, Aug 15, 2007 at 12:48:35AM +0200, Andi Kleen wrote:
>
> > > > In general the .data protection is only considered a debugging
> > > > feature. I don't know why Fedora enables it in their production
> > > > kernels.
> > >
>
On Wed, Aug 15, 2007 at 12:48:35AM +0200, Andi Kleen wrote:
> > > In general the .data protection is only considered a debugging
> > > feature. I don't know why Fedora enables it in their production
> > > kernels.
> >
> > That would be because we think you are wrong 8)
>
> Well, it might
> Then you fix the specific case and the game continues.
If they intercept netdev->hard_start_xmit there is nothing
to fix. Or inode->i_ops or any other virtual method pointer
that is called often..
Putting i_ops into const memory doesn't help either -- they
can just copy them and use their own a
> So even with Alan's hypervisor support the whole thing would be still
> quite holey. The argument of raising the bar also doesn't seem very
Its materially harder, especially with the hypervisor.
> convincing to me, because attackers reuse code too and it's enough
> when someone publishes such
On Aug 14 2007 21:50, Andi Kleen wrote:
>Hajime Inoue <[EMAIL PROTECTED]> writes:
>
>> Just protecting the table does not stop rootkits. A highly referenced
>> phrack article explains how to bypass the table.
>
>During .23-pre for some time the kernel text was protected too (that
>would have lik
Hajime Inoue <[EMAIL PROTECTED]> writes:
> Just protecting the table does not stop rootkits. A highly referenced
> phrack article explains how to bypass the table.
During .23-pre for some time the kernel text was protected too (that
would have likely stopped that particular attack), but it was
> Just protecting the table does not stop rootkits.
not in general no; however it requires more rights than before (eg code
execute rather than just "write to memory")
> Why isn't the rest of the kernel code protected along with the table?
it is if you set the right config options.
-
To unsu
> Just protecting the table does not stop rootkits. A highly referenced
> phrack article explains how to bypass the table.
But most people are not capable of fllowing that article - or they
wouldn't be asking here whatever their intention.
> Why isn't the rest of the kernel code protected alon
Thanks for your comments.
Alan Cox wrote:
> This is to protect it from being changed by an attacker or someone trying
> to do strange and bogus things to the kernel.
>
> What are you actually trying to achieve ?
I am trying to emulate an attacker. I'm helping develop a system that
that detects
On Tue, 14 Aug 2007, Avi Kivity wrote:
> Alan Cox wrote:
> > This is to protect it from being changed by an attacker or someone trying
> > to do strange and bogus things to the kernel.
> >
>
> Someone who apparently hasn't heard of vmap(), etc.
>
> It's a debug aid at best.
It clarifies to a
On Tue, 14 Aug 2007 08:12:29 +0300
Avi Kivity <[EMAIL PROTECTED]> wrote:
> Alan Cox wrote:
> > This is to protect it from being changed by an attacker or someone trying
> > to do strange and bogus things to the kernel.
> >
>
> Someone who apparently hasn't heard of vmap(), etc.
>
> It's a deb
Alan Cox wrote:
> This is to protect it from being changed by an attacker or someone trying
> to do strange and bogus things to the kernel.
>
Someone who apparently hasn't heard of vmap(), etc.
It's a debug aid at best.
--
Do not meddle in the internals of kernels, for they are subtle and qu
On Mon, 13 Aug 2007 18:05:35 -0400
[EMAIL PROTECTED] wrote:
> I have a question about changing the page attributes of the
> system call table.
Please don't do that.
> This works fine on my debian system, but apparently the stock Fedora
> kernel (2.6.22) has the system call table write protected.
13 matches
Mail list logo
