Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Windows NT didn't copy the Unix security model. Indeed, people have remarked for the past 30 years that the Windows NT model has nothing like set-UID, for starters. People who think that the Windows NT model is like the Unix one, do not know Windows NT. There are some very interesting differences, including:

* Variable-length security IDs, with a much larger namespace.

* The ability of a process to employ multiple tokens during the course of its existence, including kernel-enforced restrictions on how it can employ tokens borrowed from service clients.

* Nonce security IDs, employed (for example) to partition a single user from xyrself when it comes to granting access to window stations and desktops.

* Universal security IDs for truly universal things, such as "Everyone" and "Creator Group", that are the same everywhere. "nobody" is one UID on FreeBSD and Debian, and a different UID on OpenBSD.

* Local security IDs for local things, such as all security IDs for domain user accounts incorporating the unique ID of the domain (controllers) making the domain user account SIDs globally unique. Two BSD/Linux systems can have two different users with the same UID 1001.

* Universal RIDs for things that every domain has, like "this domain's printer operator", "this domain's policy administrator", and "this domain's backup operator". FreeBSD's/OpenBSD's "operator" has the UID of Debian's "bin"; FreeBSD's/OpenBSD's "bin" has the UID of Debian's "sys"; FreeBSD's/OpenBSD's "operator" group has the GID of Debian's "tty" group; FreeBSD's/OpenBSD's "tty" group has the GID of Debian's "adm" group.

* Standard security IDs for granting permissions to log on locally, via a network, in batch, as a service, or via dialup.

* A Hurd-like mechanism for obtaining process tokens: an RPC transaction to a distinguished server process inside the TCB -- /hurd/passwd meet Local Security Authority Subsystem Service



I have very limited experience with Windows and don't claim to know much of anything about its security. I was referring to the User Account Control system introduced in Windows 7. Whatever might be happening underneath, the system appears to end up doing the same thing: the user operates in a reduced-privileges mode until specifically authorizing a local, temporary elevation.


And people just end up running everything as Admin the first time something needs any of this.


You exaggerate, but only slightly. Whatever the theoretical properties of the windows security model, it's a failure of usability, and that means most of the time none of it gets used.

Windows is not alone in this, SELinux suffers from exactly the same problem.


Exactly. JOin NT perms with sharing perms plus GPO's and you'll get a clusterfuck.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: