This is more like the dosemu implementation.
>Any/all programs make their system calls through this utility. Foreign
>programs wouldn't even execute. It's all been done before and it works
>for good security.
And how does a user program do a open/close/read/write/pipe/dup/... None of
these can be done either.
The run utility did not support security on VMS. That was done via ACLs
(version 4 and up, might have been 5 and up), user permissions (TMPMBX,
NETMBX ...) and user indentity. The run command only existed because the
command interpreter ran in the P1 address space. The run command copied
the application into P0, then called it as a subroutine (after a reduction
in privilege). At the time, VMS had a more efficent startup of a user
program than UNIX (no context switching - reduction in privelge was a
bit clear, I think). It was better for large applications; UNIX had a better
small process startup.
It was not necessary to use the run command. If the user chose to define
it as a DCL command then it would be done via the CCL (either DCL or MCR)
if done properly. VMS security was enforced by the address range that the
system call came from - user mode was P0 addresses, command was P1, kernel
was P2 (IO addresses were reserved for P3). Every system call had a
"chmknl?" (change mode to kernel - I don't remember the instruction now)
that was required to be the first instruction executed in the P1 address
range while switching levels. Then the rest of library function was processed.
This instruction acted as a barrier - if the first instruction in the
library (assuming the library in P1 or P2 space) was not the chmknl then a
trap occured aborting the execution. IMO this binding was the downfall of
VMS - the entire security structure depended on the chmknl instruction which
did not exist in other hardware. The use of libraries as part of the address
space of the user process with special privleges controlled by the address
the library resided in limited user address space (1/4 of a 32 bit range).
UNIX doesn't have the support for a "priveleged" library the way VMS used
it. This was how the RMS I/O was implemented. the runtime library was
priveleged, and resided in the P1 address space, along with the command
interpreter. User libraries resided in the P0 space along with the application.
One of the interesting features of VMS was the ability to add priveleged
functions by creating such a library. One application? that used this
was datatreve - It had a runtime library loaded into the P1 space that gave
"database" like capability to user applications for expense of a library
call. The unix method is a remote procedure call - a much more expensive
technique.
VMS didn't have good security until it had passed version 6 (or 7) DEC
presisted in leaving out ACLs on the logical names, forgot to protect
certain directories, and had a lot of network security problems. (The
first Morris style worm program I had herd of was a batch job that submitted
itself to all known remote nodes, excepting only the local node. This
shutdown the entire internal DECnetwork world-wide... The user was only
trying to map the network.)
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil
Any opinions expressed are solely my own.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/