Re: [9fans] security questions

[Bakul Shah <bakul+plan9@bitblocks.com>]

On Fri, 17 Apr 2009 08:14:12 EDT "Devon H. O'Dell" <devon.odell@gmail.com>  wrote:
> 2009/4/17 erik quanstrom <quanstro@quanstro.net>:
> >> What if each user can have a separate IP stack, separate
> >> (virtualized) interfaces and so on?
> >
> > already possible, but you do need 1 physical ethernet
> > per ip stack if you want to talk to the outside world.
>
> I'm sure it wouldn't be hard to add a virtual ``physical'' interface,
> even though that seems a little bit pervasive, given the already
> semi-virtual nature due to namespaces. Not sure how much of a hassle
> it would be to make multiple stacks bindable to a single interface...
> but perhaps that's the better way to go?

You'd have to add a packet classifier of some sort.  Packets
to host A get delivered to logical interface #1, host B get
delivered to #2 and so on.  Going out is not a problem.

Alternatively put each virtual host on a different VLAN (if
your ethernet controller does VLANs).

> >> But you'd have to implement some sort of limits on
> >> oversubcribing (ratio of virtual to real resources). Unlike
> >> securitization in the hedge fund world.
> >
> > this would add a lot of code and result in the same problem
> > as today =97 you can be run out of a criticial resource.
>
> Oversubscribing is the root of the problem. In fact, even if it was
> already done, on a terminal server, imagmem is also set to kpages. So
> if someone found a way to blow up the kernel's draw buffer, boom. I
> don't know how far reaching that is, as I've never really seen the
> draw code.

If you are planning to open up a system to the public, then
provisioning for the peak use of your system will result in a
lot of waste (even if you had the resources to so provision).
Even your ISP uses oversubscription (probably by a factor of
100, if not more. If his upstream data pipes give him N bps,
he will give out 100N bps of total bandwidth to his
customers.  If you want guaranteed bandwidth, you have to
shell out a lot more for a "gold" service level agreement).

What I meant is
a) you need to ensure that a single user can't exceed his resoucre limits,
b) enforce a sensible oversubscription limit (if you oversubscribe
   by a factor of 30, don't let in the 31st concurrent user), and
c) very likely you also want to put these users in different
   login classes (ala *BSD) and disallow each class to
   cumulatively exceed configured resource limit (*BSD
   doesn't do this) -- this is where I was thinking of CBQ.