linux-kernel - Re: [RFC PATCH] tmpfs: support user quotas

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 7 Nov 2011 22:53:14 +0000
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Kay Sievers <kay.sievers@...y.org>
Cc:	Davidlohr Bueso <dave@....org>,
	Lennart Poettering <mzxreary@...inter.de>,
	Christoph Hellwig <hch@...radead.org>,
	Hugh Dickins <hughd@...gle.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	lkml <linux-kernel@...r.kernel.org>, linux-mm@...ck.org
Subject: Re: [RFC PATCH] tmpfs: support user quotas

> What part of the message did you read? This is about _per_user_
> limits, not global limits!

What part of 'we support lots of mounts' don't you understand. Or perhaps
you could go use a control group for it ?

> Any untrusted user can fill /dev/shm today and DOS many services that
> way on any machine out there. Same for /tmp when it's a tmpfs, or
> /run/user. This is an absolutely unacceptable state and needs fixing.

Actually if you've mounted it with limits they can be a nuisance but
little more, and if you are running with memory overcommit disabled then
its accounted for in that. If you are running with memory over commit
allowed (as eg Red Hat and Fedora do) you are peeing into the wind at this
point anyway so wasting time.

> I don't care about which interface it is, if someting else fits
> better, let's discuss that, but it has surely absolutely noting to do
> with size/nr_blocks/nr_inodes.

Per user would be quota, per process would be rlimit. Quite simple
really, nice standard interfaces we've had for years. Various systems
have been quotaing /tmp/ for a long time. Smart secure ones of course
mount a per user /tmp via PAM or similar to avoid /tmp attacks and in that
case the mount options I pointed out already do the job.

Quota isn't entirely trivial because you want your quota db initialised
at mount so you'd need to pass a quota file pointer to the mount command
ideally. All doable however and makes the management easy and means you
get all the application expected behaviour when you exceed your limits
(that is for properly written stuff - lots of crappy badly written desktop
programs randomly crash or worse as we already know)

This is why I'm confused - you are wittering about all sorts of security
stuff but you are not addressing the more serious matters first - the
ones that go beyond a DoS.

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/