lkml.org 
[lkml]   [1997]   [Sep]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: /dev/full a security hole?
Date
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/

\
 
 \ /
  Last update: 2005-03-22 13:40    [W:0.183 / U:0.136 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site