Messages in this thread | | | From | "Khimenko Victor" <> | Date | Sat, 22 Jul 2000 21:05:37 +0400 (MSD) | 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/
| |