Hi
I think there are different categories when the kernel allows to
destroy hardware or allows to destroy data.
1. When you have (write) access to a normal file (~/myfile) you can
destroy the contents of this file. You are not capable to change
another file or change the permissions of another file (by seeking
past the end of myfile and writing something there). It would not
be ok (legal) for the kernel to allow such things. Crashing the
kernel or destroying hardware are completely impossible even
as root (if you just use the access to ~/myfile).
2. When you have access to memory devices (/dev/mem) you can
always do everything (destroy hardware and data). So you can
say it is legal that the kernel allows you to destroy hardware
and data this way.
3. When you have access to a disk devicefile (dev/hda) you can
(using open, lseek, read, write, close) only destroy the content
of this disk. You cannot destroy other disks or the hardware or
crash the kernel. For example you are not able to seek past
the end of a partition and write in the next partition. You can
now argument that you can patch a filesystem on devicefile
level to get a rootshell. Or you can patch the devicefile in a way
that makes the kernel crash (wrong filesystem data). So why is
there a check for the end of the partition at all. You are already
capable to get the ultimate power. The answer ist: There is
only protection for mistakes made by normal (root) users
(think of dd if=data of=/dev/hda1 with wrong size of data) but
no protection aggainst crackers (which is not possible at this
level).
4. When you have access to a disk devicefile (dev/hda) and you
are using ioctl you can do more (potentially dangerous) things.
You can tune you disk. You can destroy disk content. You
can destroy the disk. This is the area where all the disk-destroyer
discussions are about.
5. When you have write access to /proc configuration files you can
do also dangerous things. Like sysctl you can influence drivers and
various other parts of the kernel.
There are of course more categories. I think for every category there
should be guidelines what the worst thing is that the kernel allows.
It could be one of:
A. This data can be destroyed/changed.
B. Other data can be destroyed/changed.
C. The kernel can be crashed.
D. Hardware can be destroyed.
And because the main idea is protection for normal and root users
aggainst mistakes (and not a security aggainst crackers) only
direkt effekts should be taken into account (Getting priviledges
and destroy something in a second step does not count in this
case).
It could be like this (just an example):
1-A (File access as usual)
2-D (The ultimate power)
3-B (Other data because files on the filesystem are affected.
If you argue that the filesystem can be crashed: C)
4-B (Other data because files on the filesystem are affected.
If ioctl's can crash the kernel: C
If ioctl then: D)
5-D (Interface for all (possibly dangerous) device driver and
other kernel settings)
Of cause there are many possibilitys to enhance this concept.
But in general I think there should be general guidlines (from
Linus) like this. So that every kernel hacker / driver writer
knows what he should check and what not.
Greetings Thomas Mertes
-
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/
This archive was generated by hypermail 2b29 : Mon Jul 31 2000 - 21:00:18 EST