These are two seperate normal installs directly from the XP cd. They don't have the same machine SID.
Which method did you try? Both? At what point does it seem to break? Are you listed as an authorized user for the files in the encryption properties on both installs?
OK. I could not get the recovery agent function to work properly, but I could add normal (transparent) access users from other computers to a file. Both are running seperate installs of XP SP2, and AFAIK neither has ever been a domain member.
Encrypt a file on computer A, user A like normal.
Export user A's private key.
Use ntbackup or a different local installation to access the still-encrypted file on computer/installation B.
Import user A's private key into B's key store on computer B.
Note that the encryption properties of the file list user B as having transparent access.
Open the file.
OR
Export user B's public certificate.
Import that certificate into your personal or the computer's list of "Trusted People" on A.
Encrypt a file on A, and add user B to the transparently authorized list (note the user@computer for B is now listed in Add)
Transfer the encrypted file to computer B. User B can access the file transparently.
Not exactly. A public/private key set is generated the first time you encrypt a file. The public key is used to encrypt files and the private to decrypt them. The only place these keys are stored are in a special key store that is encrypted with your password, unless you explicitly export the keys with the Certificates snap-in. On a domain, this is in the Active Directory and on stand-alone computers it's in the SAM. When your account is deleted or the password is reset, the key store is lost. Even though you have the original password, the old key store is gone. At this point, you re-import your backed up keys into the new store. There aren't any 'hidden passwords'.
I just tried it. It works fine. Here was my procedure:
Create a EFS recovery agent certificate and private key pair using cipher/r:efskey and enter a password to protect the key file. This produces efskey.cer and efskey.pfx.
Add the certificate (efskey.cer) to the list of recovery agents using the Local Security Policy snap-in. (must be admin for this)
As user A, create a file and encrypt it.
As user B, add the private key (efskey.pfx) to your personal store using the certificates snap-in. You must re-enter the password used when you created the private key.
As user B, browse to the encrypted file and decrypt it. Note that the user that did this was listed as a recovery agent but not a normal 'transparent access' user.
Notes:
The options for import and export are in 'All Tasks'. Just right-click on a folder (probably Personal) to import into or specific key to export and use the All Tasks submenu.
Make sure that you import the.pfx key file (not the.cer certificate) into the recovery agent's key store. The default file filter is for.cer; change it to.pfx.
The certificate must be defined as a recovery agent before files on the system are encrypted, or they won't be decryptable using the recovery agent. Use cipher/u to update the key list on all encrpyted files on local drives.
Anyone can export their EFS key for backup purposes using the certificates snap-in. This will work regardless of installation.
You can have many encryption keys and certificates, both for transparent and recovery agent uses.
You're not so much adding users to the list of recovery agents, but a list of trusted certificates. Any user that has (and adds to their certificate/key store) the corresponding private key to one of those trusted certificates can decrypt files. The certificate store also contains the normal EFS key and cert. It is protected by the user's password, so when it is reset the store becomes inaccessible along with your keys (unless you exported them for backup).
The Data Recovery Agent works only if you happen to know the other password, generated by Windows XP. If you put the same login name and password on another computer, you cannot recover your files, because the hidden password will be different.
Huh? The only passwords needed were for user logon and an optional one to protect the recovery cert private key. If you are going to another computer, export your keys. That's exactly what the export and import functions are for.
The DRA works only if you are using the original installation of Windows. If you have a system crash, you lose EVERYTHING. Your backup is NOT a backup! That's cruel.
You backup the data and you export and backup the keys. Simple.
The only difference between 2000 and XP's EFS system for data recovery agents (DRAs) is that 2000 used to make administrators DRAs by default but XP requires you to do it manually using this procedure.
Yeah, you can lose your data, if you reset the user's password. Before you reset a password, a big ugly warning box is shown stating that the user might expierence data loss. (a dialog not present in 2000). It's not like you'll magically lose your files in XP for no reason.
This information means that you can lose your files in Windows XP in a way that you could not lose them in Windows 2000. Microsoft made this change, but provided no on-screen warning.
This isn't a new way to lose files. It's a simple change in the default configuration. An on screen warning? What do you want, an immense file shown on screen during installation listing all the changes in the operating system since the last version? A warning displayed every time you encrypt a file? What if the user really wants to have no DRAs?
If you are concerned about the status of DRAs, go and check the group policy yourself. If you don't know how to set up and query DRAs correctly (it's not hard) then you shouldn't be using EFS at all.
It should say, Stand-alone computers CANNOT have a DRA that allows decryption of files from a different computer with the same user name and password.
Sure you can. Make sure you connect using the "Connect using a different user name" option. You may have to do it by mapping a drive letter. If you have computers where you are maintaining a set of identical users with the same passwords, it's probably time to upgrade to a domain. That's what they are for.
I find the problem to be the insidious architecture of XP specifically the lack of clear demarcation between a priveleged user and an admin.
Power Users is kinda in the middle. I guess the idea is that you can assign permissions and privileges to users as needed.
And I pretty much always have myself configured as an admin type user... not because I have to all the time (I do lots of work not needing that level of access) but more because of the unpredictability of what isn't going to work in some strange way when I'm using XP as an un-priveleged user. It sucks, but I've found it to be the most expedient way, and I'm always nervous about it.
Yeah, I usually end up doing the same thing too, for the same reasons. There are way too many apps that are somewhat broken, fail to start silently or otherwise balk at getting only reasonable access to the system. To mitigate this, I logon, run the shell and trusted apps as an admin, but start everything else with restricted tokens with the administrator's group SID and often the user identity SID deleted. Also, I usually make jobs for them which restrict USER handles and some reasonable memory and process quotas. These are really useful security features that have been available since Windows 2000, but as usual Microsoft provides no easy way to exploit them. I wrote a little command-line program that exposes most of the features of job objects and restricted tokens, jobprc. For example, I can run jobprc iexplore -dsid administrators -dprivmax -handles -prclimit 20 -jobmem 64000000 and be assured that a vuln in IE could damage my own profile or stuff that everyone has access to at most (since it still has my user SID enabled). Denying access to my profile breaks tons of apps (they get read-only access to the default user profile instead). Restricting SIDs are very powerful, (closer to a capabilities style system) but tend to break things in all kinds of weird ways. Anyways, the underlying system is there, but 1. it's hard to get to and use and 2. it's popular to ignore.
Everything pretty much works the way it's supposed to in a unix world -- the unix community is pretty savvy about what the various directory structures are for, what levels of access they provide, and how to work within that paradigm.
Yeah, espescially UNIX developers vs Windows developers. I find that cross platform or UNIX software ported to Windows is the best behaved. Plus, the biggest problem with the NT security model is that it's too complicated for most developers (let alone most users) to bother with. Good old rwx permissions on files are very simple by comparison. An operating system for The People should use something at least as simple.
Windows doesn't have a direct equivalent to root. root can ignore the security on any object, but Administrator still needs to be included in an object's ACL to get access. Still, the Administrators group has access to pretty much everything by default. Admins also have the take ownership privelege, which allows them to become the owner of any object, and since the owner can set a new ACL, admins can have full control over any object. The idea is that requiring an extra step (taking ownership) leaves an audit trail, and helps admins to use the privelege only when necessary.
For example, go into windows and bring up your process listing. Look for an item called SERVICES. Now, try to kill it. You'll get access denied.
Task Manager won't let you kill it, not the OS itself. You have access, but Task Manager is taking matters into its own hands. It would be like the Red Hat task manager UI app (forget the name) preventing you from killing init. I hate it when Task Manager or Explorer does stuff like this too. However, it's a problem with the UI, not the underlying system. pskill services works fine. It doesn't do anything fancy, just opens the process and kills it.
As a result, the priveledge separation in Unix is much better. There are ways to temporarily become root to handle tasks. No need to log out of the system all together, you can use simple commands to change.
Another thing worth mentioning is that under Unix you can grant limited root access to people. For example, let's say you needed to be able to restart my mail server, for whatever reason. I can grant you the ability to do just that without giving you the keys to the kingdom.
Every service (like every other object in Windows) has an ACL you can use to give permission to start, stop, query and control services. The easiest way to set that is to use a security template.
But the beauty of it is that, most of the time, you don't need to do that. A user can install software, and all that stuff, without needing admin access in most cases. The reason why most people run Windows as administrators is that it's hard to do anything without that ability.
Install, are you sure? Most package management apps need to be root to run. There are a few hacks to get them to install to home, but it's not common. It's true that there is a lot of Windows software that requires excessive priveleges to run. Usually, it is the app developer's fault for assuming the system is single user when it's not.
The vulnerabilities in MSFT's OS cannot be blamed on third-party software.
No, they can't, but there's a big difference between an insecure design and an insecure implementation. Any vulnerabilities that Windows suffers that allow the machine to become infected without the assistance of an administrator are implementation, not design problems. What third-party software can be blamed for is contributing to poor user habits by requiring unnecessary priveleges for their products to run.
MSFT themselves have
"value-added" "ease-of-use" into their NT/2K/XP
product to bring the OS down -- not just damaging
the user's home directory.
Name one feature in the design of Windows added for "value" or "ease-of-use" that allows a normal user to take down the system. Name one design flaw that compromises the OS's ability to restrict normal users.
Email malware, port scans w/service attacks, and
even dodgy bitmaps pulled into IE have all been
used to totally hose a Windows OS.
When run as a normal user, Email trojans, and IE vulns cannot cause the privelege escalation necessary to damage the system or other users. Attacking a listening service would only work if its patches weren't kept up to date.
Build a new
computer from scratch, install MSFT OS on it, and
put it on the internet without (1) a good firewall,
and (2) all the required security patches, and the
computer will be compromised within minutes, even
if the only website you are connecting to is MSFT
(for patches).
Build a new computer from scratch, install Redhat 7.2 (same age as XP with no patches) on it, and put it on the internet without (1) a good firewall, and (2) all the required security patches, and the computer will be compromised within days if not hours, even if the only website you are connecting to is Redhat (to upgrade since 7.2 is EOL). It'll take a little longer to get 0wned, but not much.
And when 3rd
party applications are finally added in, the situation
only gets much worse, security-wise. It is with
good reason that many corporate WinXP sites still
haven't upgraded to SP2 -- too many apps they
rely upon will immediately break.
If the 3rd party apps are compromising the system's security this is hardly Microsoft's fault. If you're giving the apps unnecessary priveleges, then it's your fault too. What specifically in SP2 is breaking those critical apps? Is it that the apps were relying on undocumented behavior that has changed? Is it DEP? Before any blame can be assigned, it has to be made clear what the exact cause of the problem is. It could be MS's fault or it could be sloppy, fragile programming on the app developer's part.
Of course,
it is always good policy to never build a system
while connected to any network, especially the
internet.
No, it isn't a good idea to build the system while connected. I'm glad you realize this.
But MSFT is getting ready to
unleash SP2 on an as-yet unprepared corporate
audience when they make their announced changes
to "Update" (, a utility I have never really
trusted for over-the-wire patches).
A network admin can still avoid SP2 if they really want to by implementing SUS and not offering SP2 on it. MS will continue to support SP1 at least until SP3 comes out.
Try to keep a user from seeing a subdirectory in which they do not have any rights. Can't do it it NTFS, you can in the NetWare/NCP environment.
You can't do this because list permission exists on containers, not content entries. So what? The user can see the directory but they can't do anything with it. This isn't a security hole. If anything, it should be the application layer that hides directories the user has no access to from view, not the OS.
Try to allow a user to create a new file in a subdirectory, but not list, read, write or modify any files that already exist in that subdirectory. Can't do it either.
Give them only Create Folders or Create Files permission and have the entry apply only to directories and subdirectories (not files). Don't give them any other privleges. The shell won't like this because you can't navigate to directories unless you can list the files. You just have to type the new filename in manually.
Try assigning filesystem rights to anything other that Users or Groups (for example, to an Application Object, or an OU in the Directory Service). Whoops, can't do that!
NTFS can assign access to anything that has a SID. Only Users, Groups and a few special things have SIDs. This isn't NTFS's fault.
You can implement this yourself by denying Administrators execute access on the binaries you don't want them to run. Just add an execute deny entry for the group Administrators that applies to the files/directories that you don't want them executing. As a rule of thumb, everything in the Windows directory should be OK, but stuff in other directories like Program Files and user profiles aren't. This could be distributed using a security template. Admins could still override this by removing the deny entry when necessary.
This would have to be done manually based on individual files (after installation), but I'm sure that an application could be written to search for binaries on the disk and apply the proper permissions, based on a database of hashes or filenames.
I doubt that Microsoft would implement this themselves anytime soon, as it would probably sound too anticompetitive, and it wouldn't fix insecure programs that require admin just to run.
Read Windows NT and VMS: The Rest of the Story Just because marketing says it's "new technology" doesn't make it so. NT originally referred to the codename N-10 Intel i860 CPU that it was going to run on.
If I run a malware email attachment as a normal user on my Windows box, it can damage at most that user's profile. That user doesn't have permission to write to anything outside their profile, and so can't damage anything else. Before it can even run, the directory or hash for the binary can't be on SRP's blacklist and the user needs file execute permission. Although SRP wasn't introduced until XP, everything else has been true since the first version of NT. Show me malware that can bring down an entire Windows system when run as a normal user. If you're running it as admin, then that's the first problem, isn't it?
http://world.std.com/~mikep/machpaper.html: a page that has a good overview of the design differences between the Mach and NT kernels. They have a lot in common but aren't the same, especially in implementation.
In Windows, shared memory is done the same way that memory mapped files are. If you just want to share memory without mapping a file, you have to map a section of the page file. If there is no page file, this doesn't work. From CreateFileMapping:
If hFile is INVALID_HANDLE_VALUE, the calling process must also specify a mapping object size in the dwMaximumSizeHigh and dwMaximumSizeLow parameters. In this case, CreateFileMapping creates a file mapping object of the specified size backed by the operating-system paging file rather than by a named file in the file system.
Here's an example of creating shared memory between two processes using this method.
I don't know why screen savers would stop working, but I bet the developers never planned for the creation of shared memory failing.
A multi-user OS means that I can log in several times on the same computer at the same time. And that multiple users can log on at the same time from different places.
The GUI is not the only service that a computer can use to provide logins. Every version of NT has the basic OS support for mulitple users, if the service they are connecting to supports them.
Notably, the Windows GUI didn't support remote sessions until NT4.0 Terminal Server (or 3.51 with Citrix), but connections to other services like file sharing or SSH, or even *gasp* X-Windows (there are plenty of X client and server programs for Windows ported to SFU and Cygwin) have always worked fine for multiple concurrent, remote users.
The biggest reason that Microsoft doesn't have good support for remote GUIs is for marketing reasons: they don't want to lose their thick-client model without charging a lot of money (TS client licences), not for technical reasons.
Microsoft could have made remote GUIs on Windows free and easy a long time ago (the OS is capable) but they don't want to.
The only things centralized about the registry are that it has a single database server that does the actual file writes while providing a high level API, and it has a single-root hierarchy. Data in the registry is stored in hives mounted at various places in the registry's hierarchy. The registry's root is a key named \REGISTRY in the Object Manager's namespace. Win32 confuses things a little by renaming \REGISTRY\MACHINE to HKEY_LOCAL_MACHINE and \REGISTRY\USER to HKEY_USERS, and providing some pseudo keys, like for the current user, but the idea is the same. The RegLoadKey, RegUnLoadKey and RegSaveKey functions can be used to dynamically mount, unmount and copy hives in the registry. The key \REGISTRY\MACHINE\SYSTEM\CurrentControlSet\Control \hivelist contains a list of all the hives to be automatically mounted at startup. Go ahead, divide the registry into as many hives as you want, and put them where ever you want.
What I'm trying to say is that the registry is no more centralized than the VFS is in Linux. The registry consists of various hives mounted at different locations, just like the VFS consists of various filesystems mounted at different locations.
As for messyness, is this due to the structure of the registry itself, or Microsoft's usage of it: do you really think that if Windows used an/etc it would be any better documented or organized? Personally, I don't think the layout is all that bad.
3 seconds later, and it's over with the last two bashes stalled, waiting for ctrl-c. The same thing happens under SFU, but it displays less Permission denied messages. The rest of the machine didn't even notice.
That's what job limits are for. Shameless plug: get jobprc, a GPL'd command-line job creator (written by me) here.
Am I alone in wondering whether this truth extends to running Windows Limited Accounts, instead of Administrator logins?
I'm sure it does extend to that. Users aren't used to dealing with computer security, on any operating system. It wasn't so important to a home user before the Internet, and it was impossible on 9x. Now they're using a different OS and are connected to a malicious network, but don't want to learn to adapt.
As for resources, ask Google. noadmin.editme.com has a wiki about it, and also see Aaron Margosis' WebLog, aka the The Non-Admin blog, made by a Microsoft employee. Windows NT Security in Theory and Practice, a long-running set of MSDN articles about NT security is also interesting, espescially to developers. Also useful are FileMon and RegMon from SysInternals, to see what files/reg keys an app is hung up on trying to get unreasonable access to. (Remember that security is checked only on open/create, so set the filter to show opens only)
Still, there is too little information about running stuff as non-admin. Part of the problem is that making a program run as non-admin when it wasn't designed for that, usually isn't easy.
Exactly. I was really hoping that Avalon with.NET would become a new environment subsystem to replace Win32 in Longhorn. This is exactly the kind of thing that environment subsystems were designed to do:.NET is a new API, has (or should have) a completely seperate interface from Win32, and it will (supposedly) have an entirely different graphical and windowing system. Hey, even ReactOS is planning a Java environment subsystem, one not built on Win32.
Win32 was introduced in NT 3.1 to be easy to port using source code written for (dos) Win3.1 that followed all the Win16 API rules. Win16, IIRC, goes all the way back to Windows 1.0. Since then, layer after layer of compatibility has been added so that you can still compile different binaries that will run on Win1.0, 3.1, 95, NT, XP and everything in between using the same source code. Compatibility is nice, but forcing the main API to be compatible with all those previous versions is getting a little excessive. There should be wrapper libraries that covert the old API versions to the new ones without sacraficing the design of the new API's interface or implementation. Win16 was never designed for long-term compatibility, and it shows. All windows are expected to be visible to all applications and allow unrestricted transmission of messages, including dangerous ones. NT works around this by dividing the window spaces into desktops, but desktops can't be used widely because the would break compatibility. Note subtle differences between WM_XBUTTONDOWN, WM_LBUTTONDOWN, WM_NCXBUTTONDOWN, WM_NCLBUTTONDOWN, WM_NCHITTEST, and WM_INPUT. WM_L/R/MBUTTONDOWN were used in versions previous to 2000/ME to be compatible with Win16. The WM_XBUTTONDOWN is a more generic version introduced in 2000/ME. WM_NCHITTEST also sends click messages, but also includes movement and some special events also duplicated in WM_SYSCOMMAND, WM_ACTIVATE and WM_APPACTIVATE. WM_INPUT does the same things, but with handles and less pre-processing. The WM_NC* messages are special for non-client messages that haven't been captured. Juggling capture, focus and disabled windows is fun. Each windows message has exactly two parameters: lparam and wparam. This can't be changed because it would break the fixed format of all the message functions. There are many creative ways to cram as much information into these two parameters as possible. The MSG structure has a few other fixed properties, like pt for screen coordinates which are sent even for messages that have nothing to do with coordinates, so some functions use it to pack more parameters..NET wouldn't have this problem: events are objects, and you can always add new properties to
First, what kind of dipshit designs a system where the standard method of running programs is to create a window and event loop?
It's a holdback from the earliest versions of Windows. I agree that it has become an old design with many layers of compatibility and some cruftyness. The basic idea, having client threads wait for incoming events so they can be processed, however is fine. A replacement, Avalon in Longhorn is planned.
Second, having a privileged window should not open up the system to guaranteed forms of attack.
It's only a risk if the underlying desktop is accessible by malicious processes. A desktop is a shared area, with little security inside of it. It's like sharing a section of memory between processes; it's only safe to do that with processes you trust. The idea is to prevent access to the entire area, which works fine using desktops. Either that, or put the unsafe processes inside a job that limits window handles to only those belonging to processes in the job. Sandboxes can be built, you just have to ask for them.
That means everyone is encouraged to break the security advice that Microsoft quietly puts out beneath their blaring marketing campaigns.
That is simply crappy design no matter how you spin it, and a webpage does not mitigate the pervasive problem.
Huh? No one said security was easy. You have to understand the system before you can secure it. Willfully ignoring the documentation is not a defense for insecure programming.
But NT, while it was (at least supposed to be) a from-the-ground-up rewrite of Windows, it still kept enough of the original design to be seriously flawed with respect to multi-user (see the shatter attack) and the Internet (see the RPC issues, along with many others).
Shatter attacks only work on programs that have been written insecurely. Shatter attacks work by sending malicious window messages to a target process using an exposed window the target owns. A process can only send messages to a window when it has access to the desktop that it is contained in. Desktop objects are securable, and have been available since NT 3.51. If a program is vulnerable to a shatter attack it is only because the app developer didn't use desktop objects properly; they put windows owned by a privileged process onto the interactive desktop, just like Microsoft tells you not to. 2000 and later can also use jobs to prevent window messages from leaving a restricted job.
Vulnerabilities in RPC were due to implementation problems, like buffer overflows, not bad design.
Although I will say that NT was originally expected to run on closed networks, not the Internet.
In the same way, Microsoft can make Windows cluster. But was it designed for it? Or was it just forced into the role, with a lot of duct tape and bandaids?
As someone said before, the operating system itself has a lot less to do with clustering than the applications themselves. You can build a cluster on just about anything, given the right application. The OS does need support any special communication hardware, but even that could be an add-on in the form of drivers. Windows has had official cluster support since Windows 2000. The cluster service does some interesting things, but requires a lot of application support.
I'm curious: what kind of support do other OSes provide to clusters?
The backend of IE's rendering engine is a COM library called mshtml.dll, with a control called WebBrowser, which is documented. This and the items documented here comprise the standard HTML rendering API on Windows. A nice thing about COM is that any interface can be re-implemented. There is a project, Mozilla ActiveX Control, which re-implements WebBrowser and some of the other interfaces using the Mozilla engine. It's designed to be a drop-in replacement for apps that use mshtml, so they can use Mozilla without modification. I've heard that it can be registered as mshtml, replacing IE's rendering engine completely.
Huh? 1. Download installer package for new version, put it on the desktop or something. 2. Uninstall old version. 3. Run installer for new version. You don't need a browser at this point because the installer was already downloaded in step 1.
Normally, the installer can upgrade the old version, making the uninstall step unnecessary.
Lan Manager passwords have a maximum size of 14 ascii characters. NTLM passwords have a maximum size of 128 unicode characters. Windows 9x uses Lan Manager hashes unless upgraded with the Active Directory Client, in which case it uses NTLM v2. Windows NT (and derivatives) have always used NTLM passwords; NT has always supported passwords up to 128 unicode chars, if you disable storing Lan Manager hashes. NTLM v2 was first introduced in NT4 sp3.
Here's a Microsoft page describing user authentication in detail for NT versions 3.1 to 4.0. Here's a good reference page about SMB, with a section about Windows network authentication-- scroll down to section 2.8.
Slashdot Mirror
These are two seperate normal installs directly from the XP cd. They don't have the same machine SID.
Which method did you try? Both? At what point does it seem to break? Are you listed as an authorized user for the files in the encryption properties on both installs?
- Encrypt a file on computer A, user A like normal.
- Export user A's private key.
- Use ntbackup or a different local installation to access the still-encrypted file on computer/installation B.
- Import user A's private key into B's key store on computer B.
- Note that the encryption properties of the file list user B as having transparent access.
- Open the file.
ORNot exactly. A public/private key set is generated the first time you encrypt a file. The public key is used to encrypt files and the private to decrypt them. The only place these keys are stored are in a special key store that is encrypted with your password, unless you explicitly export the keys with the Certificates snap-in. On a domain, this is in the Active Directory and on stand-alone computers it's in the SAM. When your account is deleted or the password is reset, the key store is lost. Even though you have the original password, the old key store is gone. At this point, you re-import your backed up keys into the new store.
There aren't any 'hidden passwords'.
- Create a EFS recovery agent certificate and private key pair using cipher
/r:efskey and enter a password to protect the key file. This produces efskey.cer and efskey.pfx. - Add the certificate (efskey.cer) to the list of recovery agents using the Local Security Policy snap-in. (must be admin for this)
- As user A, create a file and encrypt it.
- As user B, add the private key (efskey.pfx) to your personal store using the certificates snap-in. You must re-enter the password used when you created the private key.
- As user B, browse to the encrypted file and decrypt it. Note that the user that did this was listed as a recovery agent but not a normal 'transparent access' user.
Notes:- The options for import and export are in 'All Tasks'. Just right-click on a folder (probably Personal) to import into or specific key to export and use the All Tasks submenu.
- Make sure that you import the
.pfx key file (not the .cer certificate) into the recovery agent's key store. The default file filter is for .cer; change it to .pfx. - The certificate must be defined as a recovery agent before files on the system are encrypted, or they won't be decryptable using the recovery agent. Use cipher
/u to update the key list on all encrpyted files on local drives. - Anyone can export their EFS key for backup purposes using the certificates snap-in. This will work regardless of installation.
- You can have many encryption keys and certificates, both for transparent and recovery agent uses.
You're not so much adding users to the list of recovery agents, but a list of trusted certificates. Any user that has (and adds to their certificate/key store) the corresponding private key to one of those trusted certificates can decrypt files. The certificate store also contains the normal EFS key and cert. It is protected by the user's password, so when it is reset the store becomes inaccessible along with your keys (unless you exported them for backup).Huh? The only passwords needed were for user logon and an optional one to protect the recovery cert private key. If you are going to another computer, export your keys. That's exactly what the export and import functions are for.You backup the data and you export and backup the keys. Simple.How would you do things differently?
Yeah, you can lose your data, if you reset the user's password. Before you reset a password, a big ugly warning box is shown stating that the user might expierence data loss. (a dialog not present in 2000). It's not like you'll magically lose your files in XP for no reason.This isn't a new way to lose files. It's a simple change in the default configuration. An on screen warning? What do you want, an immense file shown on screen during installation listing all the changes in the operating system since the last version? A warning displayed every time you encrypt a file? What if the user really wants to have no DRAs?
If you are concerned about the status of DRAs, go and check the group policy yourself.
If you don't know how to set up and query DRAs correctly (it's not hard) then you shouldn't be using EFS at all.Sure you can. Make sure you connect using the "Connect using a different user name" option. You may have to do it by mapping a drive letter. If you have computers where you are maintaining a set of identical users with the same passwords, it's probably time to upgrade to a domain. That's what they are for.
Although the maximum nonpaged pool size in the 32 bit versions is 256MB, but it may be auto-set to less if you have less than 1GB of memory. You can override the default by setting HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\NonPagedPoolSize to the number of bytes you want the pool to be.
You can use the driver verifier's (verifier.exe) pool tracking function to see how much memory tcpip.sys is taking up.
The nonpaged pool limit in the 64 bit versions is 128GB.
For example, I can run jobprc iexplore -dsid administrators -dprivmax -handles -prclimit 20 -jobmem 64000000 and be assured that a vuln in IE could damage my own profile or stuff that everyone has access to at most (since it still has my user SID enabled). Denying access to my profile breaks tons of apps (they get read-only access to the default user profile instead). Restricting SIDs are very powerful, (closer to a capabilities style system) but tend to break things in all kinds of weird ways.
Anyways, the underlying system is there, but 1. it's hard to get to and use and 2. it's popular to ignore.Yeah, espescially UNIX developers vs Windows developers. I find that cross platform or UNIX software ported to Windows is the best behaved.
Plus, the biggest problem with the NT security model is that it's too complicated for most developers (let alone most users) to bother with. Good old rwx permissions on files are very simple by comparison. An operating system for The People should use something at least as simple.
I hate it when Task Manager or Explorer does stuff like this too. However, it's a problem with the UI, not the underlying system.
pskill services works fine. It doesn't do anything fancy, just opens the process and kills it.Like RunAs, psexec, or tsdiscon?Every service (like every other object in Windows) has an ACL you can use to give permission to start, stop, query and control services. The easiest way to set that is to use a security template.Install, are you sure? Most package management apps need to be root to run. There are a few hacks to get them to install to home, but it's not common.
It's true that there is a lot of Windows software that requires excessive priveleges to run. Usually, it is the app developer's fault for assuming the system is single user when it's not.
What third-party software can be blamed for is contributing to poor user habits by requiring unnecessary priveleges for their products to run.Name one feature in the design of Windows added for "value" or "ease-of-use" that allows a normal user to take down the system. Name one design flaw that compromises the OS's ability to restrict normal users. When run as a normal user, Email trojans, and IE vulns cannot cause the privelege escalation necessary to damage the system or other users. Attacking a listening service would only work if its patches weren't kept up to date.Build a new computer from scratch, install Redhat 7.2 (same age as XP with no patches) on it, and put it on the internet without (1) a good firewall, and (2) all the required security patches, and the computer will be compromised within days if not hours, even if the only website you are connecting to is Redhat (to upgrade since 7.2 is EOL). It'll take a little longer to get 0wned, but not much.If the 3rd party apps are compromising the system's security this is hardly Microsoft's fault. If you're giving the apps unnecessary priveleges, then it's your fault too.
What specifically in SP2 is breaking those critical apps? Is it that the apps were relying on undocumented behavior that has changed? Is it DEP? Before any blame can be assigned, it has to be made clear what the exact cause of the problem is. It could be MS's fault or it could be sloppy, fragile programming on the app developer's part.No, it isn't a good idea to build the system while connected. I'm glad you realize this.A network admin can still avoid SP2 if they really want to by implementing SUS and not offering SP2 on it. MS will continue to support SP1 at least until SP3 comes out.
You can implement this yourself by denying Administrators execute access on the binaries you don't want them to run. Just add an execute deny entry for the group Administrators that applies to the files/directories that you don't want them executing. As a rule of thumb, everything in the Windows directory should be OK, but stuff in other directories like Program Files and user profiles aren't. This could be distributed using a security template. Admins could still override this by removing the deny entry when necessary.
This would have to be done manually based on individual files (after installation), but I'm sure that an application could be written to search for binaries on the disk and apply the proper permissions, based on a database of hashes or filenames.
I doubt that Microsoft would implement this themselves anytime soon, as it would probably sound too anticompetitive, and it wouldn't fix insecure programs that require admin just to run.
See also Software Restriction Policies, which is somewhat similar, although it applies to all users.
Read Windows NT and VMS: The Rest of the Story
Just because marketing says it's "new technology" doesn't make it so. NT originally referred to the codename N-10 Intel i860 CPU that it was going to run on.
If I run a malware email attachment as a normal user on my Windows box, it can damage at most that user's profile. That user doesn't have permission to write to anything outside their profile, and so can't damage anything else. Before it can even run, the directory or hash for the binary can't be on SRP's blacklist and the user needs file execute permission.
Although SRP wasn't introduced until XP, everything else has been true since the first version of NT. Show me malware that can bring down an entire Windows system when run as a normal user.
If you're running it as admin, then that's the first problem, isn't it?
http://world.std.com/~mikep/machpaper.html: a page that has a good overview of the design differences between the Mach and NT kernels. They have a lot in common but aren't the same, especially in implementation.
I don't know why screen savers would stop working, but I bet the developers never planned for the creation of shared memory failing.
Notably, the Windows GUI didn't support remote sessions until NT4.0 Terminal Server (or 3.51 with Citrix), but connections to other services like file sharing or SSH, or even *gasp* X-Windows (there are plenty of X client and server programs for Windows ported to SFU and Cygwin) have always worked fine for multiple concurrent, remote users.
The biggest reason that Microsoft doesn't have good support for remote GUIs is for marketing reasons: they don't want to lose their thick-client model without charging a lot of money (TS client licences), not for technical reasons.
Microsoft could have made remote GUIs on Windows free and easy a long time ago (the OS is capable) but they don't want to.
The only things centralized about the registry are that it has a single database server that does the actual file writes while providing a high level API, and it has a single-root hierarchy.l \hivelist contains a list of all the hives to be automatically mounted at startup. Go ahead, divide the registry into as many hives as you want, and put them where ever you want.
/etc it would be any better documented or organized?
Data in the registry is stored in hives mounted at various places in the registry's hierarchy. The registry's root is a key named \REGISTRY in the Object Manager's namespace. Win32 confuses things a little by renaming \REGISTRY\MACHINE to HKEY_LOCAL_MACHINE and \REGISTRY\USER to HKEY_USERS, and providing some pseudo keys, like for the current user, but the idea is the same. The RegLoadKey, RegUnLoadKey and RegSaveKey functions can be used to dynamically mount, unmount and copy hives in the registry. The key \REGISTRY\MACHINE\SYSTEM\CurrentControlSet\Contro
What I'm trying to say is that the registry is no more centralized than the VFS is in Linux. The registry consists of various hives mounted at different locations, just like the VFS consists of various filesystems mounted at different locations.
As for messyness, is this due to the structure of the registry itself, or Microsoft's usage of it: do you really think that if Windows used an
Personally, I don't think the layout is all that bad.
That's what job limits are for. Shameless plug: get jobprc, a GPL'd command-line job creator (written by me) here.
As for resources, ask Google.
noadmin.editme.com has a wiki about it, and also see Aaron Margosis' WebLog, aka the The Non-Admin blog, made by a Microsoft employee.
Windows NT Security in Theory and Practice, a long-running set of MSDN articles about NT security is also interesting, espescially to developers.
Also useful are FileMon and RegMon from SysInternals, to see what files/reg keys an app is hung up on trying to get unreasonable access to. (Remember that security is checked only on open/create, so set the filter to show opens only)
Still, there is too little information about running stuff as non-admin. Part of the problem is that making a program run as non-admin when it wasn't designed for that, usually isn't easy.
Exactly. I was really hoping that Avalon with .NET would become a new environment subsystem to replace Win32 in Longhorn. This is exactly the kind of thing that environment subsystems were designed to do: .NET is a new API, has (or should have) a completely seperate interface from Win32, and it will (supposedly) have an entirely different graphical and windowing system. Hey, even ReactOS is planning a Java environment subsystem, one not built on Win32.
.NET wouldn't have this problem: events are objects, and you can always add new properties to
Win32 was introduced in NT 3.1 to be easy to port using source code written for (dos) Win3.1 that followed all the Win16 API rules. Win16, IIRC, goes all the way back to Windows 1.0. Since then, layer after layer of compatibility has been added so that you can still compile different binaries that will run on Win1.0, 3.1, 95, NT, XP and everything in between using the same source code. Compatibility is nice, but forcing the main API to be compatible with all those previous versions is getting a little excessive. There should be wrapper libraries that covert the old API versions to the new ones without sacraficing the design of the new API's interface or implementation.
Win16 was never designed for long-term compatibility, and it shows. All windows are expected to be visible to all applications and allow unrestricted transmission of messages, including dangerous ones. NT works around this by dividing the window spaces into desktops, but desktops can't be used widely because the would break compatibility.
Note subtle differences between WM_XBUTTONDOWN, WM_LBUTTONDOWN, WM_NCXBUTTONDOWN, WM_NCLBUTTONDOWN, WM_NCHITTEST, and WM_INPUT. WM_L/R/MBUTTONDOWN were used in versions previous to 2000/ME to be compatible with Win16. The WM_XBUTTONDOWN is a more generic version introduced in 2000/ME. WM_NCHITTEST also sends click messages, but also includes movement and some special events also duplicated in WM_SYSCOMMAND, WM_ACTIVATE and WM_APPACTIVATE. WM_INPUT does the same things, but with handles and less pre-processing. The WM_NC* messages are special for non-client messages that haven't been captured. Juggling capture, focus and disabled windows is fun.
Each windows message has exactly two parameters: lparam and wparam. This can't be changed because it would break the fixed format of all the message functions. There are many creative ways to cram as much information into these two parameters as possible. The MSG structure has a few other fixed properties, like pt for screen coordinates which are sent even for messages that have nothing to do with coordinates, so some functions use it to pack more parameters.
Vulnerabilities in RPC were due to implementation problems, like buffer overflows, not bad design.
Although I will say that NT was originally expected to run on closed networks, not the Internet.As someone said before, the operating system itself has a lot less to do with clustering than the applications themselves. You can build a cluster on just about anything, given the right application. The OS does need support any special communication hardware, but even that could be an add-on in the form of drivers.
Windows has had official cluster support since Windows 2000. The cluster service does some interesting things, but requires a lot of application support.
I'm curious: what kind of support do other OSes provide to clusters?
The backend of IE's rendering engine is a COM library called mshtml.dll, with a control called WebBrowser, which is documented. This and the items documented here comprise the standard HTML rendering API on Windows. A nice thing about COM is that any interface can be re-implemented. There is a project, Mozilla ActiveX Control, which re-implements WebBrowser and some of the other interfaces using the Mozilla engine. It's designed to be a drop-in replacement for apps that use mshtml, so they can use Mozilla without modification. I've heard that it can be registered as mshtml, replacing IE's rendering engine completely.
Huh?
1. Download installer package for new version, put it on the desktop or something.
2. Uninstall old version.
3. Run installer for new version. You don't need a browser at this point because the installer was already downloaded in step 1.
Normally, the installer can upgrade the old version, making the uninstall step unnecessary.
ftp://ftp.mozilla.org/ using standard ftp.exe. Not the best solution for Joe User, but it's still possible to download things without a web browser.
And after I install FireFox to replace IE, there is little reason to keep IE around, except for the programs that depend on its libraries.
Lan Manager passwords have a maximum size of 14 ascii characters.
NTLM passwords have a maximum size of 128 unicode characters.
Windows 9x uses Lan Manager hashes unless upgraded with the Active Directory Client, in which case it uses NTLM v2.
Windows NT (and derivatives) have always used NTLM passwords; NT has always supported passwords up to 128 unicode chars, if you disable storing Lan Manager hashes. NTLM v2 was first introduced in NT4 sp3.
Here's a Microsoft page describing user authentication in detail for NT versions 3.1 to 4.0.
Here's a good reference page about SMB, with a section about Windows network authentication-- scroll down to section 2.8.