Since when can't any program get MS-DOS and MS-Windows admin rights?

Question

I'm certain that I read that in the 80s with 8-bit Intel processorn, any DOS program that was run with MS-DOS was run in administrative mode and could do anything that any C program could do. Now I'm also fairly certain that this is no longer the case and I wonder if we can verify or answer these claims?

Answer 1

There are two major protection mechanisms which restrict programs run by a user:

• Access control lists define operations are permitted for a particular user to perform on files (or named OS objects in general).

• Memory protection which effectively isolates running programs from each other.

Some single-user systems (e.g. Windows 95) implement only memory protection, without ACL. The inverse situation is impossible; ACL cannot be properly implemented without memory protection.

Both mechanisms were introduced by Microsoft in Windows NT 3.1 in 1993.

Answer 2

At the time of MS-DOS, or in the graphical derivatives (up to and including Windows ME), there was no notion of "administrative rights".

There are two distinct concepts here, that should be detailed. The first one is about what a process is allowed to do when it asks nicely. The second is what it can do if it is not nice at all.

In MS-DOS, each process grabs exclusive control of the machine and can do just about anything it wishes. It sees all the RAM, can talk to all the hardware, and so on. Also, there is no scheduler, so a process uses the CPU until it exits. It is possible to make a process linger around, but that is mostly reserving a bit of RAM and waiting to be given control through, usually, an hardware interrupt (mouse handlers worked that way).

With Windows 3.1 in "386 extended mode", and its derivatives Windows 95, 98 and Millenium (ME), several processes may run concurrently, and a piece of the operating system gives the CPU to one or the other, without asking them. This is called preemptive multitasking. Each process has its own memory space, and the MMU traps cases where one process is trying to access the memory of another. However, this is only for detecting bugs, not for security: all processes can still access the hardware directly, and read and write kernel memory. Thus, there is no notion of "administrative rights" that make sense in these OS, and they don't even try.

In the NT lineage, starting with NT 3.51 then NT 4, Windows 2000, XP and subsequent versions, there is actual memory protection and processes cannot escape their address space. They cannot talk to the hardware directly, and they cannot access memory beyond that which was explicitly allocated to them. This implies that when they need to do anything that exceeds the boundaries of their private address space, be it reading a file or displaying things on the screen, they must ask the OS. And the OS will comply, or not, depending on its own notion of access rights. Any process can thus have "administrator rights" or not; if it does not, then a number of operations will be rejected with an "access denied" error.

This applies to MS-DOS executables as well. Under the NT line of systems, MS-DOS executables work with a 16-bit addressing model, meaning that they "see" an address space of about one megabyte (1114096 bytes, precisely) in which the OS emulates an old MS-DOS version -- the process believes that it is alone in the machine; but when it accesses files by talking with that emulated MS-DOS, the calls are routed back to the normal (32-bit) kernel, which will decide whether to accept them or not, based on the access rights granted to the MS-DOS process, in particular whether it was run with admin rights or not.

Note that running 16-bit code in an otherwise 32-bit OS requires usage of the VM86 mode. This mode is not supported by modern x86 CPU when they run in 64-bit mode (also known as "long mode") so running 16-bit MS-DOS processes is not supported in 64-bit versions of Windows, unless you add an extra layer of CPU emulation such as DOSBox.

Summary: 16-bit executables do not have automatic admin rights in DOS/Windows. Old OS versions have no such notion; on Windows versions that support a concept of admin rights, a 16-bit executable will have such rights only if explicitly granted -- if it can run at all, which is no longer the case with 64-bit architectures.

Answer 3

First of all, permissions have nothing to do with "C". App could be written on C, ASM, Pascal or C++. It does not matter.

Modern Intel x86 CPUs have grandfather called 8086. It was 16 (not 8!) bit CPU used for first IBM-PC and MS-DOS os was created for it.

This processor did not do any protection. Any program launched on it had access to any memory and IO spaces, so hardware and RAM (including OS itself) could be accessed for writing by any app. There was no such thing as "administrative rights".

Since 80386, they created "protected mode" (well, if was available since 80286, but was never used there). When in this mode, processor distinguish "user application" from "os/kernel". Application lives in "virtual world" of "virtual memory" and when it reads some memory, CPU (with aid of OS) maps its request to some real memory, and if app does not have access to it -- fault happens and app dies.

Modern OSes associate "user account" with each running process and use it to limit process access to some of their API (like debugging) or filesystem. (btw, FileSystem used by DOS called FAT and did not have any permission info aswell).

But any CPU may run in 8086-emulation mode (so called "real mode") with out of any protection.

There was also "virtual 86" model to emulate real mode from protected mode, but it is not available when CPU runs in long (x64) mode.