| 1 |
On Sun, Sep 27, 2015 at 11:06 AM, Mike Gilbert <floppym@g.o> wrote: |
| 2 |
> On Sun, Sep 27, 2015 at 10:38 AM, lee <lee@××××××××.de> wrote: |
| 3 |
>> Hi, |
| 4 |
>> |
| 5 |
>> when updating a guest in an LXC, emerging python pointed out a problem |
| 6 |
>> with a broken /dev/shm. So I found out how to mount /dev/shm in the |
| 7 |
>> container and updated. |
| 8 |
>> |
| 9 |
>> However, I'm wondering how secure that is, and I wonder if I should |
| 10 |
>> leave it mounted or disable the mount. It might be a very bad idea to |
| 11 |
>> leave it mounted, and there's probably good reasons not to have it |
| 12 |
>> mounted by default, yet I don't know if anything in the container might |
| 13 |
>> use or need this mount after updating. |
| 14 |
> |
| 15 |
> There are a few glibc functions that require it: |
| 16 |
> |
| 17 |
> - Shared memory |
| 18 |
> - Semaphores |
| 19 |
> |
| 20 |
> As a developer, I consider your system to be mis-configured if it is |
| 21 |
> not mounted properly, and I would immediately close any related bug |
| 22 |
> reports. I don't see how it could possibly be a security problem. |
| 23 |
> |
| 24 |
|
| 25 |
By itself it's not, but there are a number of off the shelf exploits |
| 26 |
in other code (primarily webapps) that tend to depend on it being a |
| 27 |
trusty, reliable, writable path, even for processes running under |
| 28 |
accounts with very low privileges. Making it noexec narrows down the |
| 29 |
list a little, but it's far from foolproof. Avoiding it is less a |
| 30 |
proper security measure, and more a bandaid to try to cover real |
| 31 |
security issues you don't (yet) know you have, but the effectiveness |
| 32 |
is really up there with obfuscation (like making your lamp stack look |
| 33 |
like IIS to the casual passer-by). |
| 34 |
|
| 35 |
-- |
| 36 |
Poison [BLX] |
| 37 |
Joshua M. Murphy |
Archives