All of lore.kernel.org
 help / color / mirror / Atom feed
From: Josh Triplett <josh@joshtriplett.org>
To: "Kirill A. Shutemov" <kirill@shutemov.name>
Cc: David Herrmann <dh.herrmann@gmail.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Andy Lutomirski <luto@amacapital.net>,
	Jiri Kosina <jikos@kernel.org>, Greg KH <greg@kroah.com>,
	Hannes Reinecke <hare@suse.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Arnd Bergmann <arnd@arndb.de>, Tom Gundersen <teg@jklm.no>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [RFC v1 00/14] Bus1 Kernel Message Bus
Date: Sat, 29 Oct 2016 14:04:37 -0700	[thread overview]
Message-ID: <20161029210437.la5opn65xxsdlrvb@x> (raw)
In-Reply-To: <20161027004524.GA4184@node>

On Thu, Oct 27, 2016 at 03:45:24AM +0300, Kirill A. Shutemov wrote:
> On Wed, Oct 26, 2016 at 10:34:30PM +0200, David Herrmann wrote:
> > Long story short: We have uid<->uid quotas so far, which prevent DoS
> > attacks, unless you get access to a ridiculous amount of local UIDs.
> > Details on which resources are accounted can be found in the wiki [1].
> 
> Does only root user_ns uid count as separate or per-ns too?
> 
> In first case we will have vitually unbounded access to UIDs.
> 
> The second case can cap number of user namespaces a user can create while
> using bus1 inside.

That seems easy enough to solve.  Make the uid<->uid quota use uids in
the namespace of the side whose resources the operation uses.  That way,
if both sender and recipient live in a user namespace then you get quota
per user in the namespace, but you can't use a user namespace to cheat
and manufacture more users to get more quota when talking to something
*outside* that namespace.

- Josh Triplett

  reply	other threads:[~2016-10-29 21:06 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-26 19:17 [RFC v1 00/14] Bus1 Kernel Message Bus David Herrmann
2016-10-26 19:17 ` [RFC v1 01/14] bus1: add bus1(7) man-page David Herrmann
2016-10-27 23:12   ` Kirill A. Shutemov
2016-10-26 19:17 ` [RFC v1 02/14] bus1: provide stub cdev /dev/bus1 David Herrmann
2016-10-26 23:19   ` Andy Lutomirski
2016-10-26 23:54     ` Tom Gundersen
2016-10-27  9:11       ` Arnd Bergmann
2016-10-27 15:25         ` Tom Gundersen
2016-10-27 16:37           ` Linus Torvalds
2016-10-27 16:39             ` Tom Gundersen
2016-10-29 22:13           ` Arnd Bergmann
2016-10-26 19:17 ` [RFC v1 03/14] bus1: util - active reference utility library David Herrmann
2016-10-26 19:18 ` [RFC v1 04/14] bus1: util - fixed list " David Herrmann
2016-10-27 12:37   ` Peter Zijlstra
2016-10-27 12:48     ` David Herrmann
2016-10-27 12:56       ` Arnd Bergmann
2016-10-27 13:31         ` David Herrmann
2016-10-26 19:18 ` [RFC v1 05/14] bus1: util - pool " David Herrmann
2016-10-27 12:54   ` Peter Zijlstra
2016-10-27 12:59   ` Peter Zijlstra
2016-10-27 15:00     ` Peter Zijlstra
2016-10-27 15:14   ` Peter Zijlstra
2016-10-26 19:18 ` [RFC v1 06/14] bus1: util - queue " David Herrmann
2016-10-27 15:27   ` Peter Zijlstra
2016-10-27 16:43   ` Peter Zijlstra
2016-10-28 11:33     ` Tom Gundersen
2016-10-28 13:33       ` Peter Zijlstra
2016-10-28 13:47         ` Tom Gundersen
2016-10-28 13:58           ` Peter Zijlstra
2016-10-28 14:33             ` Tom Gundersen
2016-10-28 16:49               ` Peter Zijlstra
2016-10-26 19:18 ` [RFC v1 07/14] bus1: tracking user contexts David Herrmann
2016-10-26 19:18 ` [RFC v1 08/14] bus1: implement peer management context David Herrmann
2016-10-28 12:06   ` Richard Weinberger
2016-10-28 13:18     ` Tom Gundersen
2016-10-28 13:21       ` Richard Weinberger
2016-10-28 13:05   ` Richard Weinberger
2016-10-28 13:23     ` Tom Gundersen
2016-10-28 13:54       ` Richard Weinberger
2016-10-26 19:18 ` [RFC v1 09/14] bus1: provide transaction context for multicasts David Herrmann
2016-10-28 14:37   ` Peter Zijlstra
2016-10-26 19:18 ` [RFC v1 10/14] bus1: add handle management David Herrmann
2016-10-26 19:18 ` [RFC v1 11/14] bus1: implement message transmission David Herrmann
2016-10-26 19:18 ` [RFC v1 12/14] bus1: hook up file-operations David Herrmann
2016-10-26 19:18 ` [RFC v1 13/14] bus1: limit and protect resources David Herrmann
2016-10-26 19:18 ` [RFC v1 14/14] bus1: basic user-space kselftests David Herrmann
2016-10-26 19:39 ` [RFC v1 00/14] Bus1 Kernel Message Bus Linus Torvalds
2016-10-26 20:34   ` David Herrmann
2016-10-27  0:45     ` Kirill A. Shutemov
2016-10-29 21:04       ` Josh Triplett [this message]
2016-11-02 14:45       ` David Herrmann
2017-01-30 22:11     ` Pavel Machek
2016-10-27 11:10 ` Michael Kerrisk
2016-10-28 13:11 ` Richard Weinberger
2016-10-28 13:37   ` Tom Gundersen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20161029210437.la5opn65xxsdlrvb@x \
    --to=josh@joshtriplett.org \
    --cc=akpm@linux-foundation.org \
    --cc=arnd@arndb.de \
    --cc=dh.herrmann@gmail.com \
    --cc=greg@kroah.com \
    --cc=hare@suse.com \
    --cc=jikos@kernel.org \
    --cc=kirill@shutemov.name \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=rostedt@goodmis.org \
    --cc=teg@jklm.no \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.