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/