1 |
> > as was said already, it's not an exploit per se, it's a hacking technique |
2 |
> > to stay on an already compromised box. /dev/shm is a tmpfs filesystem, you |
3 |
> > can check your 'mount' output or /etc/fstab. most likely it isn't mounted |
4 |
> > with the noexec (let alone nodev, nosuid, etc) options so it serves as an |
5 |
> > ideal hiding place (as in, many people don't think of it as a general |
6 |
> > purpose storage place). |
7 |
> |
8 |
> on that note, is there any reason to not mount /dev/shm by default with all |
9 |
> these options you listed ? |
10 |
|
11 |
honestly, i don't know, but you can just try it and see what breaks. |
12 |
however if you want to turn 'noexec' mounts into a securing method |
13 |
then you'll have to revamp the filesystems completely, not unlike how |
14 |
PaX does it with memory access control: separate the writable (by a |
15 |
potential attacker) filesystems from the executable ones (i.e., those |
16 |
mounted without noexec). of course this gives you a very coarse grained |
17 |
control over what the user can execute vs. write to, if you need more |
18 |
then you'll need some kind of access control mechanism, there's a few |
19 |
of them in the hardened subproject, choose one that fits your |
20 |
requirements best (based on granularity vs. usability vs. whatever |
21 |
you care about). |
22 |
|
23 |
|
24 |
-- |
25 |
gentoo-hardened@g.o mailing list |