[gentoo-user] /dev/shm in a Linux container

[gentoo-user] /dev/shm in a Linux container

[lee]

Hi,

when updating a guest in an LXC, emerging python pointed out a problem
with a broken /dev/shm.  So I found out how to mount /dev/shm in the
container and updated.

However, I'm wondering how secure that is, and I wonder if I should
leave it mounted or disable the mount.  It might be a very bad idea to
leave it mounted, and there's probably good reasons not to have it
mounted by default, yet I don't know if anything in the container might
use or need this mount after updating.


-- 
Again we must be afraid of speaking of daemons for fear that daemons
might swallow us.  Finally, this fear has become reasonable.

Re: [gentoo-user] /dev/shm in a Linux container

[Mike Gilbert]

On Sun, Sep 27, 2015 at 10:38 AM, lee <lee@yagibdah.de> wrote:
> Hi,
>
> when updating a guest in an LXC, emerging python pointed out a problem
> with a broken /dev/shm.  So I found out how to mount /dev/shm in the
> container and updated.
>
> However, I'm wondering how secure that is, and I wonder if I should
> leave it mounted or disable the mount.  It might be a very bad idea to
> leave it mounted, and there's probably good reasons not to have it
> mounted by default, yet I don't know if anything in the container might
> use or need this mount after updating.

There are a few glibc functions that require it:

- Shared memory
- Semaphores

As a developer, I consider your system to be mis-configured if it is
not mounted properly, and I would immediately close any related bug
reports. I don't see how it could possibly be a security problem.

Re: [gentoo-user] /dev/shm in a Linux container

[Poison BL.]

On Sun, Sep 27, 2015 at 11:06 AM, Mike Gilbert <floppym@gentoo.org> wrote:
> On Sun, Sep 27, 2015 at 10:38 AM, lee <lee@yagibdah.de> wrote:
>> Hi,
>>
>> when updating a guest in an LXC, emerging python pointed out a problem
>> with a broken /dev/shm.  So I found out how to mount /dev/shm in the
>> container and updated.
>>
>> However, I'm wondering how secure that is, and I wonder if I should
>> leave it mounted or disable the mount.  It might be a very bad idea to
>> leave it mounted, and there's probably good reasons not to have it
>> mounted by default, yet I don't know if anything in the container might
>> use or need this mount after updating.
>
> There are a few glibc functions that require it:
>
> - Shared memory
> - Semaphores
>
> As a developer, I consider your system to be mis-configured if it is
> not mounted properly, and I would immediately close any related bug
> reports. I don't see how it could possibly be a security problem.
>

By itself it's not, but there are a number of off the shelf exploits
in other code (primarily webapps) that tend to depend on it being a
trusty, reliable, writable path, even for processes running under
accounts with very low privileges. Making it noexec narrows down the
list a little, but it's far from foolproof. Avoiding it is less a
proper security measure, and more a bandaid to try to cover real
security issues you don't (yet) know you have, but the effectiveness
is really up there with obfuscation (like making your lamp stack look
like IIS to the casual passer-by).

-- 
Poison [BLX]
Joshua M. Murphy