On Thu, 2005-04-14 at 13:22 -0400, Dan Sugalski wrote: > Anyway, a number of people I deeply respect (and who do this sort of > thing for a living, at deep levels) have told me flat-out that we're > better not having a security system than we are trying to roll our > own, and the common response to "We're lifting VMS'" has been "Good. > Do that."
Well, if you were lifting VMS's security model, that would be fine, but you're really not. You're lifting the idea of VMS's security model. A security model is a many-fold thing (I've only so far discussed the highest and most user-visible level because they are the bits most applicable to Parrot). You're talking about cherry-picking certain bits and re-designing the rest to fit. I have NO PROBLEM with that, but I want to make sure that you don't think this is the easy way to go. It's not. You're biting off a HUGE amount of work, and your first 2 attempts will likely be utterly wrong (if history is any guide, not because you're not smart and capable). > >I think it would be easier to start from scratch, personally. I > >understand your concerns, but I don't think you run any less risk by > >creating a new VM security model out of an OS security model than you do > >by creating a new one. They both create many opportunities to make a > >mistake. > > That's not been the general consensus I've seen from people doing > security research and implementation. They both create many opportunities to make a mistake. Really. Go ask the folks at Microsoft who "lifted VMS" for NT's security model, and then go ask the folks at Sun who rolled their own with Java. Both have had significant pain. > >If you really want to reduce the chances that you'll make a mistake, > >swipe the security model from JVM or CLR and start with that. At least > >those have been tested in the large, and map closer to what Parrot wants > >to do than VMS. > > The problem is twofold with those. First, there's some indications > that they're busted, They're not "busted" so much as in many places they have needed significant work. I think that the general consensus right now is that JVM is fairly well sorted out in 1.5, and CLR is moving along well. I would say that at an infrastructure level they're both more than sufficient models, and that's all you're going to lift anyway (unless you were considering lifting code from mono, which I'm not sure is workable license-wise). > and second (and more importantly) they're both > very coarse-grained, and that leads to excessive privs being handed > out, which increases your exposure to damage. That's fine. Merging down either JVM or CLR's privs into a granularity that you're happy with should work fine, and again, privs are only a small part of the security model. If you want a better picture these sources might be useful: http://developer.intel.com/technology/itj/2003/volume07issue01/art05_security/vol7iss1_art05.pdf http://java.sun.com/docs/books/security/ http://www.arctecgroup.net/ISB0705GP.pdf http://www.arctecgroup.net/ISB0706GP.pdf http://www.arctecgroup.net/ISB0707GP.pdf > >Don't get me wrong. I loved VMS back in the day. It was a pain in the > >ass at times, but what isn't. It's just that it's not a VM trying to > >execute byte-code... it's an operating system which directly manages > >hardware. > > Yeah, but don't forget that for all intents and purposes parrot is an > OS trying to execute bytecode, VMS security was interesting because it was one of the first systems to substantially abstract the security of the system from the security of the hardware. You don't get to touch hardware because you're user-land, so you have a very different set of concerns. You do, however, have roughly the same set of concerns as the JVM and CLR. That's why I suggested them. If you don't like them, that's cool, I was only trying to save those of you who have enough time to think about something as large as security infrastructure some time and pain. I don't have that kind of spare time, so I bow to your superior ability to manage your schedule.
