From mboxrd@z Thu Jan 1 00:00:00 1970 To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> In-reply-to: Your message of "Fri, 17 Apr 2009 08:14:12 EDT." <9ab217670904170514u621d72bfwc2ddab44c58b80c1@mail.gmail.com> References: <20090417063313.8DBC95B1B@mail.bitblocks.com> <4158a19ee9e8f2af3ca8c77c1fd842ac@quanstro.net> <9ab217670904170514u621d72bfwc2ddab44c58b80c1@mail.gmail.com> From: Bakul Shah Date: Fri, 17 Apr 2009 11:29:53 -0700 Message-Id: <20090417182953.B49D55B24@mail.bitblocks.com> Subject: Re: [9fans] security questions Topicbox-Message-UUID: e27d960e-ead4-11e9-9d60-3106f5b1d025 On Fri, 17 Apr 2009 08:14:12 EDT "Devon H. O'Dell" wrote: > 2009/4/17 erik quanstrom : > >> 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.