Messages in this thread | | | Date | Sun, 21 Nov 1999 08:44:15 -0600 (CST) | From | Jesse Pollard <> | Subject | Re: Linux needs flexible security |
| |
From: "Richard B. Johnson" <root@chaos.analogic.com> >You just need a 'RUN' utility (Just like VAX/VMS). It is the only thing >that could fork() and exec..(). This is not Unix, but could be readily >encorporated into a system that uses the Linux kernel as a core, but >has modified 'C' runtime libraries.
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/
| |