Re: /dev/full a security hole?

H. Peter Anvin (hpa@transmeta.com)
9 Sep 1997 20:08:00 GMT


Followup to: <199709091511.RAA16410@uran.informatik.uni-bonn.de>
By author: Wolfram Kleff <kleff@informatik.uni-bonn.de>
In newsgroup: linux.dev.kernel
>
> H. Peter Anvin wrote:
> > Consider the code:
> [code deleted]
>
> I think you miss the access call, without this you can even read /dev/mem...

No, I'm not; that's what setuid(getuid()); is for. Standard
procedure. access() is a *BAD* way to do security checking, since
there is an inherent race condition.

> 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)

Doesn't matter. It is a ticking time bomb. We are supposed to fix
security problems *BEFORE* they get exploited.

> > What is it used for? That would be helpful to know.
>
> Mainly for device performance tests, security tests, and program debugging.

Huh? As in...? Remember we're talking about *reading* /dev/full
here. *Writing* /dev/full is not in question (I'm pointing that out
because a good number of private mails I have gotten have confused
these.)

> 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
> :-)

I disagree. This is a fundamental change of the semantics of the
read() system call. Unless there is a really good reason to keep this
I'd say throw it out. So far, you're the only one of 20+ people who
have responded saying that you're even using this feature.

> 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 ?

Another completely bogus argument. Yes, these should be fixed too,
but that doesn't change the argument at hand.

-hpa

-- 
    PGP: 2047/2A960705 BA 03 D3 2C 14 A8 A8 BD  1E DF FE 69 EE 35 BD 74
    See http://www.zytor.com/~hpa/ for web page and full PGP public key
Always looking for a few good BOsFH.  **  Linux - the OS of global cooperation
        I am Baha'i -- ask me about it or see http://www.bahai.org/