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
