lkml.org 
[lkml]   [2000]   [Jul]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:57    [W:0.104 / U:0.064 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site