Re: [9fans] security questions

>> Principles of Operating Systems: Design and Applications >> by Brian Stuart >> >> ( http://www.amazon.co.uk/exec/obidos/ASIN/1418837695 ) >> >> I've only just started reading it, so can't really comment on how good >> it is yet. Looks promising so far though. > > I recently bought this book and

Re: [9fans] security questions

Robert Raschke wrote: > Also note there's a new book out that includes Inferno as a major > example, essentially explaining OS principles in general, in Inferno, > and in Linux: > > Principles of Operating Systems: Design and Applications > by Brian Stuart > > ( http://www.amazon.co.uk/exec/obidos/

Re: [9fans] security questions

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

Re: [9fans] security questions

> Very nice of you to go to lengths for describing Inferno to a non-techie. > Thank you. Just got the Fourth Edition ISO and will try it. Maybe even > learn some Limbo in long term. My pleasure. I just hope no one decides to confront me on all the inaccuracies that are likely to have crept in :

Re: [9fans] security questions

On Fri, Apr 17, 2009 at 2:08 PM, Eris Discordia wrote: > Very nice of you to go to lengths for describing Inferno to a non-techie. > Thank you. Just got the Fourth Edition ISO and will try it. Maybe even learn > some Limbo in long term. Also note there's a new book out that includes Inferno as a

Re: [9fans] security questions

hello you might want to take a look to vitanuova resources page for other inferno flavours than the official release. inferno-os.googlecode.com acme-sac.googlecode.com slds. gabi

Re: [9fans] security questions

Very nice of you to go to lengths for describing Inferno to a non-techie. Thank you. Just got the Fourth Edition ISO and will try it. Maybe even learn some Limbo in long term. --On Friday, April 17, 2009 1:55 PM +0200 lu...@proxima.alt.za wrote: what it is that Inferno does for a user or what

Re: [9fans] security questions

My understanding is that would prevent people listening and pretending to offer services on my behalf, but would not stop them dialing SMTP ports on other machines and sending them spam. -Steve

Re: [9fans] security questions

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'

Re: [9fans] security questions

> Dialing remote ports > I don't become a spam relay so some restriction must be in place, > I guess this would require a minor modification to the IP stack. does ip/hogports solve your problem? - erik

Re: [9fans] security questions

If you want true isolation between the users you should give them each a VM, not a Plan 9 account. Russ So we chose to use a VM, now we have two problems *http://tinyurl.com/cuul2m or * http://www.computerworld.com/action/article.do?command=viewArticleBasic&taxonomyName=operating_systems

Re: [9fans] security questions

2009/4/17 Bakul Shah : > On Thu, 16 Apr 2009 22:19:21 EDT "Devon H. O'Dell"   > wrote: >> 2009/4/16 Bakul Shah : >> > Why not give each user a virtual plan9? Not like vmware/qemu >> > but more like FreeBSD's jail(8), "done more elegantly"[TM]! >> > To deal with potentially malicious users you can

Re: [9fans] security questions

> what it is that Inferno does for a user or what a user can do > with it; what distinguishes it from other (operating?) systems. I've > decided to try it because documentation says it will readily run on Windows. Let's start with the fact that Inferno is a small-footprint, hosted operating envi

Re: [9fans] security questions

> The > virtual memory management is too persuasive to be broken in any > significant way. do you mean pervasive? if you do, i don't buy the argument. it's easy to get lucky when doing concurrent programming with locks, as in the plan 9 kernel. it's easy to get lucky in many cases, and yet have

Re: [9fans] security questions

> Working swap would do me to fix this, but sadly rlimits would probably > be easier to implement. There's an intrinsic belief that there cannot be anything wrong with Plan 9's swap. Having encountered the rather tightly embedded use of swap/segmentation/etc. in the Plan 9 kernel, but without h

Re: [9fans] security questions

> Erik's mod would help, but add a seccond threshold where after 15 secconds > you kill the proc failed the most fork() calls - the danger here is a spam > storm may cause listen(1) to be killed. You could put the rate limiting in listen(8) first, you may have noticed that inetd(8) has this featur

Re: [9fans] security questions

> 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. > But you'd have to implement some sort of limits on > oversubcribing (ratio of virtual to

Re: [9fans] security questions

I see. Thanks for the edification :-) I found--still find--it hard to understand what Inferno is/does. Actually read but it isn't very direct about what it is that Inferno does for a user or what a user can do with it; what distinguishes it fr

Re: [9fans] security questions

On Fri, Apr 17, 2009 at 11:29:47AM +0100, Steve Simon wrote: > I am interested in the idea of adding some kind of resource limits > to plan9. If they existsed I would probably open it up to external > users, however different things would worry me: > > CPU use > Implement the Fair share scheduler

Re: [9fans] security questions

I am interested in the idea of adding some kind of resource limits to plan9. If they existsed I would probably open it up to external users, however different things would worry me: CPU use Implement the Fair share scheduler User memory Working swap would do me to fix this, but sadly rlimits woul

Re: [9fans] security questions

> Unlike > securitization in the hedge fund world. Actually, it is a lot safer to provide something like securitisation (hm, make that "s" a "z", it is no doubt a native, American word) in a virtualised environment, you're much less likely to bring down the entire system's economy, then. ++L

Re: [9fans] security questions

> I don't know what Inferno is but the phrase 'virtual machine' appears > somewhere in the product description. Isn't Inferno the 'it' you're > searching for? No, Inferno resembles - very superficially, as you will discover if you study the literature - a JAVA interpreter surrounded by its own o

Re: [9fans] security questions

>Conceptually, anyway. Why is everyone always so hell-bent on hair-splitting? :P probably the other options suggested by the careers advisor were theology and hairdressing.

Re: [9fans] security questions

> having the potential for running out of memory in an interrupt > handler might be a sign that a little code reorg is in order, if you > are worried about this sort of thing. (and even if you're not.) To begin with: grep -n '.((iallocb)|(qproduce))' /sys/src/9/^(port pc)^/*.c

Re: [9fans] security questions

On Thu, 16 Apr 2009 22:19:21 EDT "Devon H. O'Dell" wrote: > 2009/4/16 Bakul Shah : > > Why not give each user a virtual plan9? Not like vmware/qemu > > but more like FreeBSD's jail(8), "done more elegantly"[TM]! > > To deal with potentially malicious users you can virtualize > > resources, backe

Re: [9fans] security questions

The other thought that comes to mind is to consider something like class based queuing (from the networking world). That is, allow choice of different allocation/scheduling/resource use policies and allow further subdivision. As with jail, this is also present in FreeBSD, I believe. It's called

Re: [9fans] security questions

Plan 9 itself makes a great platfrom on which to construct virtualisation. I don't know what Inferno is but the phrase 'virtual machine' appears somewhere in the product description. Isn't Inferno the 'it' you're searching for? --On Friday, April 17, 2009 6:48 AM +0200 lu...@proxima.alt.za w

Re: [9fans] security questions

As a another data point I'll offer IW9P2009-Bondi - involved a lot of beer and beach/camping but we wrote a shit-load of code. And it was fun. Not much sleep. Had to eat too but time sharing coding and cooking went well. brucee On Fri, Apr 17, 2009 at 3:52 PM, andrey mirtchovski wrote: >> 5. No

Re: [9fans] security questions

Not productive huh? That why not even Tiger reads the list anymore. But I read mail from you. brucee On Fri, Apr 17, 2009 at 3:48 PM, wrote: >> On Thu, Apr 16, 2009 at 10:33 PM, Devon H. O'Dell >> wrote: >>> 2009/4/16 erik quanstrom : On Thu Apr 16 22:18:35 EDT 2009, devon.od...@gmail.co

Re: [9fans] security questions

> 5. No code is ever implemented by anyone extremely efficient, from a SLOC point of view, no? it also leaves a lot of time for drinking belgian beer, which is nice.

Re: [9fans] security questions

> On Thu, Apr 16, 2009 at 10:33 PM, Devon H. O'Dell > wrote: >> 2009/4/16 erik quanstrom : >>> On Thu Apr 16 22:18:35 EDT 2009, devon.od...@gmail.com wrote: > i just stated what i thought the historical situation was.  the > point was only that changing direction will be difficult.

Re: [9fans] security questions

>> One can indirectly (and more consistently) limit the number of >> allocated resources in this fashion (indeed, the number of open file >> descriptors) by determining the amount of memory consumed by that >> resource as proportional to the size of the resource. If I as a user >> have 64,000 alloc

Re: [9fans] security questions

On Thu, Apr 16, 2009 at 10:33 PM, Devon H. O'Dell wrote: > 2009/4/16 erik quanstrom : >> On Thu Apr 16 22:18:35 EDT 2009, devon.od...@gmail.com wrote: >>> > i just stated what i thought the historical situation was.  the >>> > point was only that changing direction will be difficult. >>> >>> This

Re: [9fans] security questions

2009/4/16 erik quanstrom : > On Thu Apr 16 22:18:35 EDT 2009, devon.od...@gmail.com wrote: >> > i just stated what i thought the historical situation was. the >> > point was only that changing direction will be difficult. >> >> This thread certainly proves that :) > > a 9fans thread proves nothing

Re: [9fans] security questions

On Thu Apr 16 22:18:35 EDT 2009, devon.od...@gmail.com wrote: > > i just stated what i thought the historical situation was. the > > point was only that changing direction will be difficult. > > This thread certainly proves that :) a 9fans thread proves nothing. - erik

Re: [9fans] security questions

2009/4/16 Bakul Shah : > On Thu, 16 Apr 2009 21:25:06 EDT "Devon H. O'Dell" > wrote: >> That said, I don't disagree. Perhaps Plan 9's environment hasn't been >> assumed to contain malicious users. Which brings up the question: Can >> Plan 9 be safely run in a potentially malicious environment?

Re: [9fans] security questions

2009/4/16 erik quanstrom : >> Right, we're saying the same thing backwards. I just am not sure why >> smalloc was brought up. Yes, it is able to sleep until memory is >> available for the operation, but it's not used *everywhere*. > > that's part of my point. sometimes smalloc is appropriate, > so

Re: [9fans] security questions

On Thu, 16 Apr 2009 21:25:06 EDT "Devon H. O'Dell" wrote: > That said, I don't disagree. Perhaps Plan 9's environment hasn't been > assumed to contain malicious users. Which brings up the question: Can > Plan 9 be safely run in a potentially malicious environment? Based on > this argument, no,

Re: [9fans] security questions

> That said, I don't disagree. Perhaps Plan 9's environment hasn't been > assumed to contain malicious users. Which brings up the question: Can > Plan 9 be safely run in a potentially malicious environment?  Based on > this argument, no, it cannot. Since I want to run Plan 9 in this sort > of envir

Re: [9fans] security questions

> > interrupts are quite different. there are lots of things that are > > a bad idea in interrupt context. but one can wakeup a kernel > > proc that's sitting there waiting to deal with all the hair. > > Right, we're saying the same thing backwards. I just am not sure why > smalloc was brought u

Re: [9fans] security questions

2009/4/16 erik quanstrom : >> >> My misunderstanding then, as smalloc is available in port/alloc.c, >> which is also compiled into the kernel. I'm not concerned about oom >> conditions in userland. > > smalloc is used in the kernel, but only when running with up (user > process) and only when deali

Re: [9fans] security questions

> > plan 9 doesn't have interrupt threads, but that's beside the point. > > > > interrupts are driven by the hardware, not users. so smalloc, which > > is used to allow user space to wait for memory if it is not currently > > available doesn't make any sense. > > My misunderstanding then, as smal

Re: [9fans] security questions

2009/4/16 erik quanstrom : > On Thu Apr 16 17:51:42 EDT 2009, devon.od...@gmail.com wrote: >> 2009/4/16 erik quanstrom : >> > have you taken a look at the protection measures already >> > built into the kernel like smalloc? >> >> At least in FreeBSD, you can't sleep in an interrupt thread. I suppos

Re: [9fans] security questions

On Thu Apr 16 17:51:42 EDT 2009, devon.od...@gmail.com wrote: > 2009/4/16 erik quanstrom : > > have you taken a look at the protection measures already > > built into the kernel like smalloc? > > At least in FreeBSD, you can't sleep in an interrupt thread. I suppose > that's probably also the case

Re: [9fans] security questions

2009/4/16 erik quanstrom : > have you taken a look at the protection measures already > built into the kernel like smalloc? At least in FreeBSD, you can't sleep in an interrupt thread. I suppose that's probably also the case in Plan 9 interrupt handlers, and this would mitigate that situation. >>

Re: [9fans] security questions

have you taken a look at the protection measures already built into the kernel like smalloc? > While it may not be perfectly ideal, it allows the administrator to > maintain control over the system. being a system adminstrator, i dislike any ideas that require extra adminstration. for the same r

Re: [9fans] security questions

> One can indirectly (and more consistently) limit the number of > allocated resources in this fashion (indeed, the number of open file > descriptors) by determining the amount of memory consumed by that > resource as proportional to the size of the resource. If I as a user > have 64,000 allocation

Re: [9fans] security questions

2009/4/16 Venkatesh Srinivas : > Devlimit / Rlimit is less than ideal - the resource limits aren't > adaptive to program needs and to resource availability. They would be > describing resources that user programs have very little visible > control over (kernel resources), except by changing their s

Re: [9fans] security questions

Devlimit / Rlimit is less than ideal - the resource limits aren't adaptive to program needs and to resource availability. They would be describing resources that user programs have very little visible control over (kernel resources), except by changing their syscall mix or giving up a segment or so

Re: [9fans] security questions

> The benefit to this approach is that we would have an extremely easy > way to add new constraints as needed (simply create another tunable > pool), without changing the API or interfering with multiple > subsystems, outside of changing malloc calls if needed. The limits > could be checked on a pe

[9fans] security questions

In the interests of academia (and from the idea of setting up a public Plan 9 cluster) comes the following mail. I'm sure people will brush some of this off as a non-issue, but I'm curious what others think. It doesn't seem that Plan 9 does much to protect the kernel from memory / resource exhaust