Polyinstantiation of /tmp and /var/tmp and CGroups....

Shawn Wells shawn at redhat.com
Fri Apr 5 03:42:44 UTC 2013


On 4/3/13 11:51 AM, Kurt Seifried wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 04/03/2013 07:22 AM, Trevor Vaughan wrote:
>> >All,
>> >
>> >Should we be requiring polyinstation of /tmp and /var/tmp for users
>> >via PAM?
> We've (Red Hat) been doing this in our OpenShift software for some
> time. It prevents a lot of grief as you can imagine and seems to not
> really cause much in the way of problems.

Yes, absolutely! There's a writeup of this here:
https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Security-Enhanced_Linux/polyinstantiated-directories.html

And here (kinda old):
http://www.ibm.com/developerworks/library/l-polyinstantiation/

Patches welcome :)

>> >I had forgotten about this until reading a recent post.
>> >
>> >I feel that this would be a good idea in general, but may cause
>> >issues in terms of legitimate file sharing and end up with more
>> >users making their home directories 755 (or more ridiculous).
> There are better/more secure ways to share files, but you can also
> make per user /tmp default to a private one and have a public
> /tmp-public for example that users can explicitly use to share files.
>
>> >Also, should we be binding users to any particular CGroup limits by
>> >default?
>> >
The dozenish [1] available resource controllers are very much geared 
towards containing applications, how do you envision constraining the 
users? I like the idea, though admittedly my knowledge on cgroups is 
still evolving as I've only used them to contain applications for 
performance reasons (cpu, memory, etc).

[1] 
https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Resource_Management_Guide/ch01.html


More information about the scap-security-guide mailing list