Linux-kernel mailing list archive 2000-29,: Re: disk-destroyer.c

# Re: disk-destroyer.c

Khimenko Victor (khim@sch57.msk.ru)
Sat, 22 Jul 2000 21:05:37 +0400 (MSD)

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Khimenko Victor: "Re: Direct access to hardware"
- Previous message: Stephen Frost: "Re: TO HELL WITH IT THEN......(re: disk-destroyer.c)"
- Maybe in reply to: Andre Hedrick: "disk-destroyer.c"
- Next in thread: Khimenko Victor: "Re: disk-destroyer.c"
- Next in thread: Trever Adams: "Subject: Re: disk-destroyer.c"
- Maybe reply: Trever Adams: "Subject: Re: disk-destroyer.c"

In <200007212128.WAA05470@flint.arm.linux.org.uk> Russell King (rmk@arm.linux.org.uk) wrote:
> I have read this entire thread so far, and I'm disgusted by the
> reaction I'm seeing. Is this the response of a forward thinking
> constructive development community, or a war zone where features
> that might improve stuff must be fought off at every corner?
> Sounds more like a certain commercial company that I want to avoid.

> Mark Gray writes:
>> The thing is, Western Digital has activeX apps on their site which
>> will do low level Disk diagnostics, which means an activeX app can also
>> be written to do a low level format (poorly!) or rewrite the firmware.
>> If root can load a module or write to /dev/kmem there is nothing to
>> prevent him doing anything to the hardware he feels like, driver or no
>> driver. If someone gets root on a box then the "admin" did not take
>> proper precautions, which makes it even less likely that he set
>> capabilities to prevent a hostile root from "having his way."

> Hey, can we stop having a go at Andre please?

> Lets look at this from a different point of view that maybe more people
> can understand. Lets say that by some means, Linus went totally mad
> and we ended up with a system call thus:

> int sys_rm_rf(char *path)
> {
> int ret = -EPERM;
> if (capability(CAP_SYS_ADMIN))
> ret = do_rm_rf(path);
> return ret;
> }

> You are developing a kernel module and program that doesn't have a
> routine in libc, and you need to use syscall(). The system call
> that you want to call is a new number and requires root privs, so
> you give it by numeric ID (but oops, you mis-type it without
> realising it).

> You compile the program (and since you're a good system admin) you
> compile it outside of root privs. You then su, and run it. Oops,
> you've just called sys_rm_rf and path was pointing at /.

> I bet you'd say that sys_rm_rf SHOULD NOT exist.

Of course not. This thing can be done perfectly well in userspace. Why to
bloat the kernel ?

> Now, by your (and everyone elses) argument, we can do the same thing
> via the /dev/ioport device, so its ok to have sys_rm_rf included in
> the kernel.

It's not. But NOT due to security issue, of course but since you can do
such thing from userspace and thus you do not need it in kernel.

> This is the EXACT same argument that Andre/lkml is fighting over.
> Either you accept both arguments or neither argument. IMHO you'd have
> to be really stupid to accept neither argument. Choosing to accept one
> argument and not the other is not only inconsistent, but non-sensible
> and you should probably be shipped off to see the men in white coats.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

- Next message: Khimenko Victor: "Re: Direct access to hardware"
- Previous message: Stephen Frost: "Re: TO HELL WITH IT THEN......(re: disk-destroyer.c)"
- Maybe in reply to: Andre Hedrick: "disk-destroyer.c"
- Next in thread: Khimenko Victor: "Re: disk-destroyer.c"
- Next in thread: Trever Adams: "Subject: Re: disk-destroyer.c"
- Maybe reply: Trever Adams: "Subject: Re: disk-destroyer.c"