Prev: kvm: Introduce kvm_host_page_size
Next: [PATCH] Staging: comedi: ssc_dnp: fixed a brace coding style issue
From: Alexey Dobriyan on 19 Feb 2010 07:10
On Fri, Feb 19, 2010 at 1:57 PM, wzt wzt <wzt.wzt(a)gmail.com> wrote:
> Maybe, but The attackers will use a complicated way to find the
> security_ops address, it's a barrier to attackers.

It's not a barrier, it's garbage. Once you know the adress security_ops
ended up at, you simply write to it.

> LSM is security framework, �we don't want the attackers can easily
> to break it.

LSM doesn't protect kernel from kernel.

> Just like the sys_call_table variable in kernel 2.4.x(global and
> writeable), evil drivers can extern the variable, �then replace the
> Sys_X functions.

Not that easily, but they still can.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: wzt wzt on 19 Feb 2010 07:30
> It's not a barrier, it's garbage. Once you know the adress security_ops
> ended up at, you simply write to it.

How to find the security_ops address if the variable is static? Would
you please make an example?

> Not that easily, but they still can.
That's why i suggest to make the variable to static, if you had wrote
a rootkit, you will find that in kernel 2.4.x, there are many many
rootkits, but in kernel 2.6.x, rootkit became fewer. Not all the
kernel driver writers can master this method to find the variable's
address.

The patch also delete the secondary_ops variable.

On Fri, Feb 19, 2010 at 8:02 PM, Alexey Dobriyan <adobriyan(a)gmail.com> wrote:
> On Fri, Feb 19, 2010 at 1:57 PM, wzt wzt <wzt.wzt(a)gmail.com> wrote:
>> Maybe, but The attackers will use a complicated way to find the
>> security_ops address, it's a barrier to attackers.
>
> It's not a barrier, it's garbage. Once you know the adress security_ops
> ended up at, you simply write to it.
>
>> LSM is security framework,  we don't want the attackers can easily
>> to break it.
>
> LSM doesn't protect kernel from kernel.
>
>> Just like the sys_call_table variable in kernel 2.4.x(global and
>> writeable), evil drivers can extern the variable,  then replace the
>> Sys_X functions.
>
> Not that easily, but they still can.
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Alexey Dobriyan on 19 Feb 2010 07:30
On Fri, Feb 19, 2010 at 2:23 PM, wzt wzt <wzt.wzt(a)gmail.com> wrote:
>> It's not a barrier, it's garbage. Once you know the adress security_ops
>> ended up at, you simply write to it.
>
> How to find the security_ops address if the variable is static? Would
> you please make an example?

See /proc/kallsyms .

>> Not that easily, but they still can.
> That's why i suggest to make the variable to static, if you had wrote
> a rootkit, you will find that in kernel 2.4.x, there are many many
> rootkits, but in kernel 2.6.x, rootkit became fewer. Not all the
> kernel driver writers can master this method to find the variable's
> address.

Please.

> The patch also delete the secondary_ops variable.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Bernd Petrovitsch on 19 Feb 2010 08:20
On Fre, 2010-02-19 at 20:23 +0800, wzt wzt wrote:
> > It's not a barrier, it's garbage. Once you know the adress security_ops
> > ended up at, you simply write to it.
>
> How to find the security_ops address if the variable is static? Would
> you please make an example?
- Find the accessor function (which is surely non-static).
- Find the address where writes the parameter.

Other must decide, if it's more secure (as in "obscure") with the
accessor funtion or not.

Bernd
--
Bernd Petrovitsch Email : bernd(a)petrovitsch.priv.at
LUGA : http://www.luga.at

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: wzt wzt on 19 Feb 2010 08:30
security_ops is not static, so you can find the address with kallsysm,
but you can try secondary_ops:
static struct security_operations *secondary_ops = NULL;

cat /proc/kallsysm|grep secondary_ops

On Fri, Feb 19, 2010 at 8:27 PM, Alexey Dobriyan <adobriyan(a)gmail.com> wrote:
> On Fri, Feb 19, 2010 at 2:23 PM, wzt wzt <wzt.wzt(a)gmail.com> wrote:
>>> It's not a barrier, it's garbage. Once you know the adress security_ops
>>> ended up at, you simply write to it.
>>
>> How to find the security_ops address if the variable is static? Would
>> you please make an example?
>
> See /proc/kallsyms .
>
>>> Not that easily, but they still can.
>> That's why i suggest to make the variable to static, if you had wrote
>> a rootkit, you will find that in kernel 2.4.x, there are many many
>> rootkits, but in kernel 2.6.x, rootkit became fewer. Not all the
>> kernel driver writers can master this method to find the variable's
>> address.
>
> Please.
>
>> The patch also delete the secondary_ops variable.
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: kvm: Introduce kvm_host_page_size
Next: [PATCH] Staging: comedi: ssc_dnp: fixed a brace coding style issue