On Wed, 2005-04-13 at 17:01, Dan Sugalski wrote: > So here's what I was thinking of for Parrot's security and quota > model. (Note that none of this is actually *implemented* yet...) [...] > It's actually pretty straightforward, the hard part being the whole > "don't screw up when implementing" thing, along with designing the > base set of privs. Personally I think taking the VMS priv and quota > system as a base is a good way to go -- it's well-respected and > well-tested, and so far as I know theoretically sound. Unix's priv > model's a lot more primitive, and I don't think it's the one to take. > (We could invent our own, but history shows that people who invent > their own security system invent ones that suck, so that looks like > something worth avoiding)
VMS at least *is* a priv-based security model, but VMS privs are not appropriate for parrot on the whole. That said, it's been 10+ years since I've touched VMS, so pardon as I go and Google the priv list.... Privs that make sense for Parrot without change: ALL Allow all privileges. DETACH Create detached processes. EXQUOTA Exceed resource quotas. SETPRV Grant a process any privilege. SHMEM Create or delete data structures in shared memory. SYSGBL Create system global sections. SYSLCK Request locks on system resources. Privs that make no sense at all for Parrot (as far as I can tell): ACNT Create a process for which no accounting is performed. BUGCHK Make bugcheck error log entries. CMEXEC Change mode to Executive. CMKRNL Change mode to Kernel. DIAGNOSE Issue diagnostic I/O requests. GRPNAM Enter names in the group logical name table. GRPPRV Allow access to files in the group and system categories. MOUNT Issue mount volume I/O requests. PHY_IO Issue physical I/O requests. PRMCEB Create permanent common event flag clusters. PRMGBL Create permanent global clusters. PSWAPM Change process swap mode. SHARE Assign a channel to a device. SYSNAM Enter names in the system logical name table. TMPMBX Create temporary mailbox devices. VOLPRO Override protection on a volume. WORLD Control the execution of any process on the system. Privs that could make sense, but have different meanings: ALLSPOOL Allocate spooled devices. This means you can create new handles ALTPRI Increase the base execution priority for any process. change to: Allow QUOTA modification BYPASS Access resources without regard to UIC protection. This means ignore my privs and just do it (default) GROUP Control execution of other processes in the same group. This is interp-to-interp control (e.g. kill my sibling) LOG_IO Issue logical I/O requests. if we assume that this means any handle I/O NETMBX Create a network device. This just means "allocate any network resource (e.g. socket)" OPER Perform system operator functions. In VMS this was fuzzy, and referred to any operation that told the OS that it required OPER (like running certain tools). I'm not sure what this means for Parrot that BYPASS does not.... PFNMAP Create or delete sections mapped by page frame. Allocate new PMCs PRMMBX Create permanent mailbox devices. Create "special" files of any sort (e.g. POSIX fifo) SECURITY Perform security-related functions. ? SYSPRV Access resources as if the process has a system UIC. ? Privs that do not exist in VMS: NEWPBC Execute new Parrot Byte Code at run-time DEBUG Perform operations only appropriate for a debugger GCDOD Directly manage GC/DOD behavior NONREL Create I/O handles from non-relative locaters (e.g. open a rooted path; possibly applicable to URI interpretation also) DLOAD Dynamically load binary objects PLOAD Dynamically load Parrot byte code (bypass NEWPBC) This allows a PVM to load an existing PBC module and execute it, but not to create its own PBC at run-time. More...? 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. 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. 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. -- Aaron Sherman <[EMAIL PROTECTED]> Senior Systems Engineer and Toolsmith "It's the sound of a satellite saying, 'get me down!'" -Shriekback