Re: /dev/full a security hole?

Wolfram Kleff (
Tue, 9 Sep 1997 17:11:20 +0200 (MET DST)

H. Peter Anvin wrote:
> Consider the code:
[code deleted]

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 ?