[systemd-devel] /run DoS

[Michał Piotrowski]

W dniu 3 kwietnia 2011 18:00 użytkownik drago01 <drago01 at gmail.com> napisał:
> 2011/4/3 Michał Piotrowski <mkkp4x4 at gmail.com>:
>> W dniu 3 kwietnia 2011 12:54 użytkownik Lennart Poettering
>> <mzerqung at 0pointer.de> napisał:
>>> On Sun, 03.04.11 13:10, Michał Piotrowski (mkkp4x4 at gmail.com) wrote:
>>>
>>>> Hi,
>>>>
>>>> I can write to /run/user/michal in this way I can fill the entire free
>>>> tmpfs space which is not good from my POV.
>>>
>>> Yupp, this is trivially fixable by placing another tmpfs on /run/user,
>>> which can be done by installing a run-user.mount unit.
>>>
>>> We considered doing so by default, but stepped back a little, since we
>>> didn't want to add another tmpfs to the mix, just like that. But yeah,
>>> we probably should do that.
>>
>> I see no other way out here because tmpfs does not support quota.
>>
>> BTW. There still be a possibility to deadlock machine if you have a
>> not limited /tmp on tmpfs. By default tmpfs can use a half of system
>> memory size, so if you got a two user writable tmpfs file systems you
>> can try to deadlock system.
>
> You can try but that isn't a deadlock (if you can trigger a deadlock
> that way you hit a kernel bug).

I did not mean deadlock in kernel synchronization mechanisms.

Let's say that we have a system with 2 GB of RAM and we got a /tmp
with tmpfs - if you don't configure size of this fs it will be 1 GB by
default. Next we got /run/user that also gets 1 GB by default. Both
dirs are user writable, so malicious user can fill them with data. Now
imagine that the system enters OOM situation. OOMK will not help here
- it can not delete files from tmpfs.

-- 
Best regards,
Michal

http://eventhorizon.pl/