I think you miss the access call, without this you can even read /dev/mem...
I think we should be more careful for programs which get setuid, or we
get setuid programs which offers /dev/mem ;-).
> "How realistic is this exploit?" is a question that matters to
> crackers only. The fact of the matter is that it turns a legitimate,
> secure, operation into a security hole. Our job is to plug these
> holes *before* crackers find a way to exploit them.
The behavior of /dev/full is known for ages. (At least for me...)
And it has (can ?) never been exploited so far. (At least not in public
or in underground)
> What is it used for? That would be helpful to know.
Mainly for device performance tests, security tests, and program debugging.
To come to an conclusion:
As Rogier Wolff pointed out, what about changing permissions to 622
and we are all happy. (and secure)
Therefor we don't need a patch, for example if you give /dev/mem 666 permissions
you are lost anyway.
So I think we should let the people decide if they would life with
this "security bug". (Yes, I'm still not 100% convinced :-)
The 644 permission in RedHat 4.1 is RedHats security problem, and not
a security problem inside the kernel. Again, would anybody change the
behavior of /dev/mem just because somebody gives 666 permission within
a distribution ? I think not.
BTW: There are still real security bugs inside the kernel, e.g.
the use of sprintf instead of snprintf. OK, normally you can only
crash the kernel (DoS), but I think that is not what we all want.
If you really want to secure the kernel, what about correcting
these old and real security bugs ?