Hi Guys .. I am predominantly a Slackware guy who has been converted to a Suse man. I love the product and it is great ! However, what is shm fs and what is the whole thing surrounding it ? Is it a security risk ? Regards Willie Tesnaar Change your way of thinking, it might ease the process of self discovery ! (Willie Tesnaar 06/06/2001)
Hi, On 22-Aug-01 Wilhelm Tesnaar wrote:
Hi Guys ..
I am predominantly a Slackware guy who has been converted to a Suse man. I love the product and it is great ! However, what is shm fs and what is the whole thing surrounding it ? Is it a security risk ?
AFAIK shm fs is a shared-memory filesystem where files can be memory-mapped/stored in some way. I think it's mountable/umountable like "normal" devices, but the shm.h/shm.c include/source had some issues with permissions/overflows. In the kernel.org mailing list I've seen some threads discussion these issues. From the release notes of 2.2.19: "Security Updates [...] SYS5 shared memory A code path existed where the shm code would scribble on very recently freed memory. It is not clear that this was actually exploitable."
Regards Willie Tesnaar
Change your way of thinking, it might ease the process of self discovery ! (Willie Tesnaar 06/06/2001)
---
Boris Lorenz
I am predominantly a Slackware guy who has been converted to a Suse man. I love the product and it is great ! However, what is shm fs and what is the whole thing surrounding it ? Is it a security risk ?
AFAIK shm fs is a shared-memory filesystem where files can be memory-mapped/stored in some way. I think it's mountable/umountable like "normal" devices, but the shm.h/shm.c include/source had some issues with permissions/overflows. In the kernel.org mailing list I've seen some threads discussion these issues. From the release notes of 2.2.19:
"Security Updates [...] SYS5 shared memory A code path existed where the shm code would scribble on very recently freed memory. It is not clear that this was actually exploitable."
That has nothing to do with the shmfs in 2.4 (not much). SHM is part of
the sysV IPC subsystem (Inter Process Communication).
shmfs is a filesystem type that works directly in the memory management
code of the kernel. Think of it as a filesystem that is written to
a ramdisk, but much more efficient. People usually use it for /tmp or
alike, whenever performance plays a major role. The idea comes from
Solaris which has what they call "tmpfs". By default, it's mounted over
/tmp on freshly installed Solaris machines. It can be a good idea on
machines with much RAM but not many tasks: If /tmp fills up, you virtual
memory will be gone.
This is just about the security implication of it: If it's full, your mem
is gone.
You can achieve just about the same thing by leaving the buffering up to
the kernel if you use an ordinary filesystem (on disk). You might want to
tune /proc/sys/vm/bdflush to make that work better if you have much
memory in your box. :-)
Roman.
--
- -
| Roman Drahtmüller
Yuppa, On 22-Aug-01 Roman Drahtmueller wrote:
I am predominantly a Slackware guy who has been converted to a Suse man. I love the product and it is great ! However, what is shm fs and what is the whole thing surrounding it ? Is it a security risk ?
AFAIK shm fs is a shared-memory filesystem where files can be memory-mapped/stored in some way. I think it's mountable/umountable like "normal" devices, but the shm.h/shm.c include/source had some issues with permissions/overflows. In the kernel.org mailing list I've seen some threads discussion these issues. From the release notes of 2.2.19:
"Security Updates [...] SYS5 shared memory A code path existed where the shm code would scribble on very recently freed memory. It is not clear that this was actually exploitable."
That has nothing to do with the shmfs in 2.4 (not much). SHM is part of the sysV IPC subsystem (Inter Process Communication).
shmfs is a filesystem type that works directly in the memory management code of the kernel. Think of it as a filesystem that is written to a ramdisk, but much more efficient. People usually use it for /tmp or alike, whenever performance plays a major role. The idea comes from Solaris which has what they call "tmpfs". By default, it's mounted over /tmp on freshly installed Solaris machines. It can be a good idea on machines with much RAM but not many tasks: If /tmp fills up, you virtual memory will be gone.
Gosh, I never noticed what kind of OS we have! ;) So my question is: Is this a feature of both 2.2.x and 2.4.x, or 2.4.x only? Can this be set up securely? I mean, a simple leak/BoF in this code and yer box is gone forever...?! Any recommended reading/links?
This is just about the security implication of it: If it's full, your mem is gone.
If THAT would be all there is...!
Roman. -- - - | Roman Drahtm�ller
// "Caution: Cape does | SuSE GmbH - Security Phone: // not enable user to fly." | N�rnberg, Germany +49-911-740530 // (Batman Costume warning label) |
---
Boris Lorenz
Gosh, I never noticed what kind of OS we have! ;)
Da staunst Du, was? :-)
So my question is: Is this a feature of both 2.2.x and 2.4.x, or 2.4.x only? Can this be set up securely? I mean, a simple leak/BoF in this code and yer box is gone forever...?! Any recommended reading/links?
The kernel source. shmfs is 2.4 only. In some ways it's a waste product of the mm subsystem. There are big differences in the mm code btw 2.2 and 2.4.
This is just about the security implication of it: If it's full, your mem is gone.
If THAT would be all there is...!
It probably isn't. There is always the possibility for a race condition,
be it in the handling of meta data or memory. Remember the mmap()-write()
race in reiserfs that was fixed with 2.2.19, a bug that was present in the
ext2 driver in BSD? Nasty stuff...
Anyway, I think the security-relevant material is exhausted with this.
Roman.
--
- -
| Roman Drahtmüller
participants (3)
-
Boris Lorenz
-
Roman Drahtmueller
-
Wilhelm Tesnaar