Messages in this thread | | | From | (H. Peter Anvin) | Subject | Re: /dev/full a security hole? | Date | 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/
| |