2006-03-28 19:12:13

by Marko Euth

[permalink] [raw]
Subject: Who wants to test cracklinux??


Hello,

I've written a small kernel module & shared object for kernel 2.6 to
enable the following for normal users:

- inb()/outb()... via a wrapper function
- enable direct IO access (like ioperm())
- direct access on physical memory addresses
- installation of user space ISR
- change nice level

The module is primary thought for education, but perhaps also helpful
in software development.
The module is finished now, but because it's my first kernel code
there could be something to improve. If anyone wants to test, just
send me a mail and you'll get the code.

Thanks,

Marko Euth


2006-03-28 22:01:58

by Sam Ravnborg

[permalink] [raw]
Subject: Re: Who wants to test cracklinux??

On Tue, Mar 28, 2006 at 10:12:23PM +0200, Marko wrote:
>
> The module is primary thought for education, but perhaps also helpful
> in software development.
> The module is finished now, but because it's my first kernel code
> there could be something to improve. If anyone wants to test, just
> send me a mail and you'll get the code.
Why not post it to lkml?
You may be lucky and get some feedback here then.

Sam

2006-03-28 22:49:42

by Pavel Machek

[permalink] [raw]
Subject: Re: Who wants to test cracklinux??

Hi!

> I've written a small kernel module & shared object for kernel 2.6 to
> enable the following for normal users:
>
> - inb()/outb()... via a wrapper function

ioperm() does that already, no? You mean, you enable it for non-root,
too? That's security hole.

> - enable direct IO access (like ioperm())
> - direct access on physical memory addresses

read/write on /dev/mem. chmod 666 /dev/mem if you want to allow normal
users to access physical memory (security hole, again).

> - installation of user space ISR

That seems nice. Does it work with PCI shared interrupts?

> - change nice level
>
> The module is primary thought for education, but perhaps also helpful
> in software development.
> The module is finished now, but because it's my first kernel code
> there could be something to improve. If anyone wants to test, just
> send me a mail and you'll get the code.

Please post it to the list.
Pavel
--
Picture of sleeping (Linux) penguin wanted...

2006-03-28 23:49:52

by Måns Rullgård

[permalink] [raw]
Subject: Re: Who wants to test cracklinux??

Pavel Machek <[email protected]> writes:

> Hi!
>
>> I've written a small kernel module & shared object for kernel 2.6 to
>> enable the following for normal users:
>>
>> - inb()/outb()... via a wrapper function
>
> ioperm() does that already, no? You mean, you enable it for non-root,
> too? That's security hole.
>
>> - enable direct IO access (like ioperm())
>> - direct access on physical memory addresses
>
> read/write on /dev/mem. chmod 666 /dev/mem if you want to allow normal
> users to access physical memory (security hole, again).

It's a security risk, but one that you might sometimes take to gain
some performance on a non-critical machine. I've done this in the
past to be able to play videos smoothly on a slow machine.

>> - installation of user space ISR
>
> That seems nice. Does it work with PCI shared interrupts?

I obviously can't comment on this case, but I've successfully done it
previously, so it's demonstrably possible. The code is all available
from vidix.sf.net, although it's not updated to the latest ways of
doing things.

--
M?ns Rullg?rd
[email protected]

2006-03-29 11:32:12

by Marko Euth

[permalink] [raw]
Subject: Re: Who wants to test cracklinux??


Ok, here's the code.

And... of course, I know that it's a security hole.
I've written the module primary for students. They should
learn how Interrupts ... work without crashing the system
every time.

I'm appreciate for every advice!


Attachments:
cracklinux-0.50.tar.gz (18.72 kB)

2006-03-29 12:02:29

by Jan Engelhardt

[permalink] [raw]
Subject: Re: Who wants to test cracklinux??

>>
>> read/write on /dev/mem. chmod 666 /dev/mem if you want to allow normal
>> users to access physical memory (security hole, again).
>
>It's a security risk, but one that you might sometimes take to gain
>some performance on a non-critical machine. I've done this in the
>past to be able to play videos smoothly on a slow machine.
>
Actually, not only you. MPlayer's vesa output module (IIRC. if not,
then it was svga) pokes /dev/mem as well.
(Seeing vidix in your mail makes me assume you know the vesa/mem thing
already. ;-)


Jan Engelhardt
--
| Software Engineer and Linux/Unix Network Administrator
| Alphagate Systems, http://alphagate.hopto.org/
| jengelh's site, http://jengelh.hopto.org/