Messages in this thread | | | Date | Tue, 20 Apr 1999 14:36:39 -0400 (EDT) | From | "Richard B. Johnson" <> | Subject | Re: caps in elf headers: use the sticky bit! |
| |
On Tue, 20 Apr 1999, Horst von Brand wrote: [SNIPPED all] Gebtlemen,
More history. "Those who ignore history are doomed to repeat it".
To get around a lot of security problems on VAX/VMS, there were two and only two ways you could execute any program. They were RUN.EXE and RUNDET.EXE. RUN.EXE ran a program in the context of a user. RUNDET.EXE ran a program detached from a user, but using the privs of a user.
If a user had "SETPRV" privs, he could do:
RUN SYS$SYSTEM:DCL.EXE - /PROCESS_NAME = FOO - /PRIV=(NOALL, TMPMBX, NETMBX) - /INPUT=SYS$MANAGER:COMMAND.FILE - /OUTPUT=SYS$MANAGER:COMMAND.LOG - /UIC=[1,4]
In this case, DCL.EXE (the shell) executed RUNDET.EXE. RUNDET.EXE itself executed DCL.EXE in the context of the new task. The programs RUN.EXE and RUNDET.EXE had to have been installed with CHMKNL (change mode to kernel) privs because they had to acquire the caller's priv bits from the process entry table of the user which was in kernel space so the user could not change it.
The bottom line is that the privs that a task could use had nothing to do with the executables. The privs were set in kernel space, based upon entries in the authorization file, SYS$SYSTEM:SYSUAF.DAT, when the parent task was created using SYS$SYSTEM:LOGINOUT.EXE.
Programs that required special privs to execute were installed when the machine was being booted. The only difference between a normal program and a privileged program was no debugging information was allowed in the privileged program.
The kernel's task when, executing functions on behalf of a caller were very simple. An AND of the current process priv mask and the priv request resulted in pass/fail. Failure resulted in a "No privilege for attempted operation" error code being returned.
So as you can see, most of the security was obtained in user-space programs. The kernel simply checked a mask. This mask consisted of 32, later 64, bits. Each representing a specific priviledge. This mask was put into the table (Process entry Slot) for each task when it was created. When a program was installed, the mask of the installed program was ORed with the mask of the user, and the result was used in the AND for system call priv checks.
Further security was obtained by allowing only one privileged system call at a time. A programmer would execute a MACRO, for instance, like CHMKNL(address_of_procecure, parameter_list). If the caller had change-mode-to-kernel privs, the specified procedure would be executed in kernel mode. This procedure could not call any other procedure (not even fprintf()). Any attempt to modify the stack pointer due to a CALL, would result in an immediate return with an error code. So there was no way of getting privileges from stack-overflow, etc.
Incidentally, with all of this priv checking. VMS shipped for years with a back-door in the terminal driver. If you knew what to type at the "Username:" prompt, you would get the "DBG>" prompt. From there, type spawn and you are in with System privs. Hint: <ESC>[20;something..... <grin>
Cheers, Dick Johnson ***** FILE SYSTEM WAS MODIFIED ***** Penguin : Linux version 2.2.6 on an i686 machine (400.59 BogoMips). Warning : It's hard to remain at the trailing edge of technology.
- 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/
| |