It's not A key. It's MULTIPLE keys in addition to the directory vs. just the directory alone. That may or may not be more difficult, but it certainly is by definition more complicated.
If the keys are spread out all over, then the application is clearly disregarding application guidelines. If they're nested, what's the problem?
If you just want to re-use an entire profile from a similar version of windows, you can just copy the entire profile directory, user registry hive and all. In the system control panel->advanced->user profile settings, use the Copy To button. The old profile will need to be in the same "Documents and Settings" directory as the rest of the profiles are to show up in the list. The advantage of using this interface as opposed to just copying it yourself (which can also be done) is that this automatically transfers security access to the new account. This also is how roaming profiles work. FYI, the locations for each user's profile is stored at HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList, keyed by user SID.
Finally, copying a directory requires specialized tools?
To copy files, you need something like explorer.exe or cmd.exe. To copy keys, you need something like regedit.exe or reg.exe. To modify conf text files, you need a text editor like notepad or vi. I call these programs tools. I guess there could be some question as to which are specialized or not, but the fact is that you need an interface program for each operation. At the Win32 and syscall level, the registry and file functions exist side-by-side.
The ability to kill 'required' services, for example. It can be done, but not as 'Administrator'.
You can kill any process you can get TERMINATE permission for. Administrators have the SeTakeOwnership privilege, allowing them to take ownership of any process (any kernel object, actually) and grant themselves TERMINATE permission. SeDebugPrivilege (which Administrators also have) also allows you to get TERMINATE permission for any process. Task Manager limits itself as to which processes it will kill. Other programs, such as taskkill or Process Explorer do not have this limitation, and will happily allow you to kill whatever processes. Note that it is possible that a process won't die because a poorly-written kernel driver isn't allowing its IO operations to be canceled correctly. This isn't a security issue; it's a driver bug (SYSTEM can't kill those either).
Also, you have to pull some tricks to make filesystem changes to files marked 'protected' by Windows... or that any 3rd party marks as 'protected'.
Can you be more specific? There are only three reasons that a file can't be deleted:
You don't have permission. Administrators can take ownership of any object and give themselves permission. SYSTEM would also be blocked (unless it was specifically granted access) because it can't bypass ACLs directly either.
A sharing violation. A program like Process Explorer can find out what process has the file opened (opened without FILE_SHARE_DELETE) so you can forcibly close the handle or kill the process. SYSTEM can't delete locked files either.
System file protection. The file can be deleted, but it comes back. There are several ways to disable system file protection, or you can delete the backup copy of the file at the same time as the original so there's nowhere to get a replacement to restore the file. This effect still occurs even when a SYSTEM authority process deletes such a file.
SYSTEM is just another account on the system, albeit one without a password (like LOCAL SERVICE or NETWORK SERVICE). A SYSTEM authority process is subject to access checks just like every other user mode process (even those of administrators). Only the kernel can bypass security when it wants to.
If you're interested, you can start processes interactively as SYSTEM with psexec -s -i -d <program>
Ask permission of the programs? A program has to store its settings somewhere. You don't need anyone's permission to copy them. If it's not keeping them in the standard locations, then it's the developer's fault. I can't think of any reason that the established guidelines can't be followed. You can put files in the wrong places just as easily as keys.
Even Microsoft has come to see this.
Microsoft is made of up many different developers in many different departments. As much as marketing likes to say that Windows is integrated, it's actually many different pieces of software put together. Many times, developers from different departments don't understand each other and end up interfacing badly. Without any more specific reasons that Windows Mail has changed its configuration storage, I expect it to be an example of that syndrome: the original developers of the mail app understood the registry and used it correctly, but now a new team has inherited the product and instead of understanding how the old system worked, they've decided to implement something new (complete with new buzzword non-features). This is not a new or unusual story, even outside Microsoft.
Basically, if you just have to export files (instead of registry keys) it is generally easier, simpler and safer for end users to perform maintenance tasks on their computers [...]
I don't see how it's so much more difficult or complicated to copy a key vs copying a directory. Both require specialized tools that exist for both the command line and GUI. Both operations can fail to work correctly if done improperly. How is it more dangerous to edit/copy registry values over editing config files? Only the content of those storage locations could be a source of danger-- not the structure behind them.
To move settings, copy the Application Data directory and the SOFTWARE key from the source profile into the destination profile. It's not rocket science. It's not going to cause your computer to melt. For convenience, the Files and Settings Transfer Wizard from the XP setup CD will transfer all the types of user configuration.
You can say that users should never be delving into the registry, but the plain fact is that sometimes it is necessary because software screws things up. Even Microsoft's knowledge base says that certain registry changes need to be made to make repairs.
You should need to manually edit the registry about as often as you need to manually edit conf files. The process, risks and need are very similar.
I can see your explanation for the creation of the registry, but no explanation as to why Microsoft hasn't seen fit to deprecate its use over a better method.
Because it works the way it's supposed to? Almost all the 'problems' people have with the registry are due to misuse; problems that would exist regardless of how configuration storage was implemented.
In comparison to what Linux and OS X has, the registry system simply makes Windows look bad, and indeed, in my opinion, it severely hurts the maintainability of Windows.
How do you figure?
It is also one of the things that make program installation and removal potentially far more problematic than it needs to be.
The Windows Installer has been the only sanctioned installation method for application software since Windows 2000. Do you have evidence that the Windows Installer is causing these problems, or is it third party apps that disregard guidelines? All modern platforms have rules for installation, and disregarding them can cause problems on all of them. If apps are leaving remnants of themselves strewn about after uninstallation, it's the app's fault. How is leaving remnant keys different than leaving remnant files?
Heck, there doesn't even seem to be a validation system to test or correct the registry.
What are you asking for? The structure of the registry is journalled and expected to be self-healing. A fsck type fix is applied automatically if needed. Its recovery is akin to a journalled, auto-fsck filesystem. As for the content of the registry, every software component has its own needs and validity constraints-- there's no way to build a tool that would know about all of them. It'd be like asking for a/etc verifier.
For reasons that only God may know, AIM stores away messages in the registry, and the only way to move away messages to a new computer is to export the registry key(s).
Let's do a little search-and-replace: For reasons that only God may know, AIM stores away messages in a file in the user's profile, and the only way to move away messages to a new computer is to export the file(s).
You've failed to explain how is a key in the user's registry worse than a file in the user's profile.
Both have standard naming conventions; for the registry, HKCU\Software\<Company>\<AppName> and for user profiles, %USERPROFILE%\Application Data\<Company>\<AppName>. It's up to the app how well it wants to document these locations and how easy it wants to make exporting settings.
The GDM daemon normally runs as root, as does the slave.
The GUI logon programs run as a special user that also has its own dangerous privileges as described further down.
IIRC, KDE and XDM also expect expect to be run as root, although I can't find a reference for that offhand. The instructions for starting them always go "as root, type *DM" or call some startup script as root.
I'm sure that there exist special configurations for running them at a lower privilege level, so that's why I said many (not all) window managers.
I merely speak from the experience of having shitty Genicom (which were only provided kernel mode) and HP LaserJet print drivers, in both Windows NT4 and 2000 wreak havoc on a SQL database, as well as the local filesystem's integrity. Not fun.
Eew. I don't envy your position. I guess this is one of those cases where you set up a dedicated server just for printing (possibly with a different OS) or use a VM. I don't know about Genicom, but HP's printing software is awful, and it's getting worse.
True, but on a workstation, at least the filesystem will be left in a consistent state, and I don't have to waste time rebooting and going through filesystem checks...
Autochk.exe is run when the system starts (even before Win32 starts, when no files are open), and it will do a fsck on any volumes with the "dirty bit" set (set because it had an outstanding transaction). You can control this behavior, including excluding volumes from being checked and forcing them to be checked at next start with the chkntfs.exe program.
If I don't like X, I can just not install it. Or I can be ultra-paranoid and use X on something like SE Linux where everything is ACL'd to hell and back. Or I can write my own, or pay somebody else to write a better window server. Or I can run some other window server, from some vendor (I'm to lazy at the moment to cite examples, I know they exist).
That's all true. I, too, am disappointed about how many things are dependent on Win32 and how Win32 is inseperable from the GUI. Most of the time for a Windows server, the best you can do is to concentrate on software that doesn't use the GUI, allowing it to sit in the background idle and paged out.
P.S. What's up with deleting print jobs in Windows? Why do they just refuse to go away with this "printing-error-deleting" madness until you restart the print spooler service!? Even when the printer isn't in an error state, it just seems like it'll delete the job whenever it feels like it (umpteen wasted pages later). In Mac OS X for example, it simply finishes printing what's in the print buffer, and ejects the page.
When a job is canceled, it's supposed to stop printing immediately. The print spooler calls the printer driver's DrvDocumentEvent with a code of DOCUMENTEVENT_ABORTDOC, which the driver is supposed to use to tell the printer to cancel the print job, clearing on board caches as necessary. For some silly reason, the entire DrvDocumentEvent function is optional for the driver to implement. GDI will stop sending data to the print driver in any case, but the printer will continue to spool any driver-created and internal buffers unless the print driver cancels the document properly. It seems like 'extended' abilities like canceling jobs are among the first things for driver writers to skimp on.
I've got a laptop that uses XP's built in wireless support, and I can plug in/unplug the card and manage wireless network connections as both a standard user and a power user (once it was installed).
IIRC, 2000 requries a third-party wireless client. It's possible that that it doesn't support LUA properly. I know that XP uses a privileged service in the background (which the UI running as the interactive user talks to) to do actual control over the network devices. I'm not familiar enough with the various clients to know if they do the same. It's also possible that 2000 had other issues that would prevent it from working properly, issues that were fixed in XP. Have you tried running just the client software as admin?
LOL... The print spooler in NT 4 through 2000 SP4 was moved into Ring0, which allows bad print drivers and malformed jobs to at least, BSOD the system, or worst case, execute arbitrary code... That's secure!
First, the print spooler runs in the Spooler service hosted by the user-mode spoolsv.exe process. I agree that having printer drivers running in kernel mode is ugly, but only NT4 required such an arrangement. It was done because printers are just another type of display device that has to talk to GDI, and as you noted, GDI moved to the kernel mode win32k.sys in NT4. NT3 had the GDI server in user mode, and 2000 supports "version 3" printer drivers that run in user mode.
They also moved GDI into the kernel in NT4 which allows crappy video drivers to BSOD the system. Though this provided a good performance improvement, it still does compromise security for performance!
Compare NT3's user mode Win32 server (winsrv.dll in csrss.exe) and NT4+'s kernel mode Win32 server (win32k.sys) to a standard X-Windows on UNIX:
Killing the server ends the life of all client processes in all three cases.
Since all meaningful processes in Windows are Win32 clients (the Win32 server provides more services than just the GUI), this puts the OS into a fairly useless state in the NT3x case.
In NT4+, the kernel bugchecks, terminating all current activity.
With X-Windows, all of the user's GUI apps die. For a workstation, this likely represents everything important.
The server is highly privileged because it has to access the graphics hardware.
In NT3, csrss runs with the SYSTEM token, effectively granting total control over the computer; if the Win32 server is compromised, so is the machine.
Since win32k.sys runs in kernel mode, compromising it also grants full control over the machine.
X-Windows normally runs as root (without resorting to slow wrappers), and so do many window managers. Compromising these also compromises the entire machine. Even if X doesn't run as root, it's likely that unfixable privilege escilations exist due to the control over the video hardware and memory mapping that the X process has. X can be somewhat safer with some extra work and overhead.
The issues you've brought up are comparatively minor implementation choices compared to the design of the authorization and authentication systems.
And Windows should have been designed with security in mind since '95, when they integrated networking and web browsing.
Windows NT 3.1 was released in 1993 and was definately designed with security in mind. Windows NT(and its derivatives)'s security issues stem from misuse and implementation errors, not design flaws. Unfortunately, NT requires about 4x the memory of Win95, and didn't have as good compatibility with Win16 and DOS apps (due to strict memory protection), so wansn't marketed as a consumer OS until version 5.1 (XP).
Windows 95 (and its derivatives) weren't designed with security in mind, but that line of Windows is EOL now. Getting many apps designed for 9x to work on NT requires misuse, usually in the form of excessive privileges.
Ctrl2Cap is a kernel driver. Read the first sentance of the description. If you have the authority to install a kernel driver, you have control over the system. This is true of every OS in existence, short of TCPA. I specifically said that a SAS is useless if the OS is already compromised (along with all other software measures); having malicious kernel drivers installed certainly qualifies as compromised.
Show me an example of being able to disable/intercept the SAS with only the access that a standard (non-admin) user has.
Actually, a better solution for authentication from the OS is a secure attention sequence (SAS), e.g. CTRL+ALT+DELETE on Windows NT or CTRL+ALT+PAUSE on Linux. The OS supersedes any application's attempt to trap this key sequence and puts the display into a mode that only shows OS sanctioned secure dialog boxes. On Windows (and XP with the welcome screen off) this is the "Windows Security" screen. This way, if you always enter the SAS before entering your password, you know that only the OS is receiving it. It helps to build the habit when the OS always asks you for the SAS before entering passwords.
The new authorization dialog boxes in Vista are like this; this is the reason they take over the desktop. IIRC, you can hit CTRL+ALT+DELETE while one of these is up and you'll know its authentic because it'll stay there (if it weren't you'd switch to the "Windows Security" screen instead.)
Of course, these are useless if the OS is already compromised, but the whole idea is to keep it from getting that far.
Don't [confuse] available memory with address space.
I'm not. That's why I said "in a single process."
I agree completely that there are uses for lots of address space and 64-bit computing. What I was questioning was if the OP was actually had need of them. The OP didn't seem to understand the implications of 64-bitness very well.
I would like to get the 64 bit version of Windows Vista for the expanded memory capability, and the signed drivers.
You're planning to need more than 3GB of resident memory in a single process on your new computer? That's the only thing the expanded memory capability is going to bring you. Driver signing is still present in the 32-bit versions, as it is in current versions of Windows-- it's just that the 64-bit version doesn't let you install unsigned drivers (which is not the same thing as having passed WHQL) without specifying special a boot option. The biggest thing that 64-bit mode brings right now is more and bigger general purpose registers for more speed, and these only help for 64-bit code.
If my current library of software, hardware, and games work with the 32-bit version of the Vista operating system will they also work with the 64 bit version?
The WOW-64 subsystem (that runs 32-bit processes on a 64-bit install) has pretty good compatibility right now for XP-64, and I'm sure its a priority for Vista. Do you have some specific 32-bit software in mind that already fails to run on XP-64?
Can we really expect hardware manufacturers to make top quality drivers for both the 32 and 64 bit versions of Vista?
If the manufactures wrote good drivers in the first place, the 32 and 64 bit drivers use the exact same source files, simply compiled with different architectures specified, possibly with a few different arch-specific functions on the side. The NT compilation environment and kernel provide high level software abstractions for arch-specific functions, as do all other portable OSes.
Why didn't microsoft make a single unified driver model for the 32/64 bit versions of Vista? As I understand it, Apple has done this.
It's impossible to provide binary code compatible with two architectures that don't provide binary compatibility, i.e. IA32 and AMD64. They might as well be PowerPC and MIPS. What the AMD64 arch DOES provide is a special compatibility mode for IA32 that the CPU can switch to. There's no room for this kind of mode switching inside the kernel-- the kernel has to run in exactly one mode. For user mode, it's possible for the OS to run different processes in different modes as needed.
Apple only provides 32-bit kernels that can support both 32 and 64-bit processes in user mode (one for PPC and one for Intel). Microsoft provides both a 32-bit kernel that can run 32-bit processes and a 64-bit kernel that can run both 32 and 64-bit processes. The system processes run in the same mode as the kernel in both cases.
I plan to buy a whole new machine to ensure full compatibility with the new OS and to take advantage of it's high end features.
I, for one, don't plan to buy a new machine anytime just to upgrade to Vista. There are other features besides the eye candy that might be nice to have. I'm sure this machine is capable of running Vista (I've been trying the betas for while now), but it's far from compatible with the 64-bit version.
If I buy the 64 bit version of Vista will I be screwed by compatibility issues, and slow hardware driver releases?
Microsoft always publishes a hardware compatibility list with their operating systems: check it. Check with the manufacturers of your hardware to see if and when they will provide appropriate drivers.
What are you talking about? File access is handled by the filesystem. When you mount an existing fileystem, its files continue to have the same security descriptors as they did before. The only access check done when opening a file is against that file's SD. In order to have the behavior you're implying, Vista would have to intentionally modify the SD of every file to some ridiculous default, just by mounting a volume-- a behavior I've not witnessed and seriously doubt exists.
What it sounds like is ACTUALLY happening is that you assigned ownership and sole access to a local account from your previous installation that does not exist in the new Vista installation's account database. Since no account on the new installation can match the unique SID of the old account in the previous installation, you are not granted access. This behavior has been the same in every version of NT. In UNIX terms, you've assigned ownership and group on the files to a uid that doesn't exist in this installation.
Usernames are not assigned access to and ownership of objects; SIDs are. A SID is a binary value that is used as the primary key identifying a user or group. A unique local account SID contains a randomly generated prefix that was generated during installation and a sequential suffix for the specific user. With the machine's prefix, no two unique SIDs from different installations can be the same. Even if the account name matches in the two installs, the accounts will have different SIDs.
When you said that "you have to go and Take Ownership of every item on the drive, and then give yourself Full Control" (emphasis mine) you're setting yourself up for failure if you ever try to access the volume from another installation that (again) can't and won't have information about the local accounts from this installation. If, in the future you want to assign access consistently across installations sharing a volume, assign access to non-unique groups such as Users and Administrators. The SIDs of these groups are the same regardless of installation. Either that, or join both installs to a domain and use domain accounts.
A dependancy list makes it difficult to determine complete order though and provides a lot less flexibility.
AFAICT from Getting Started with launchd and man lanuchd.plist(5), "You cannot specify dependencies and ordering for launchd jobs; instead, design daemons to wait for needed resources, or trigger them automatically." Instead, you have to specify an attempt to open sockets, or changes to files in order to launch jobs by implicit need. It seems like this would leave a much more opaque start order than an explicit dependecny hierarchy, since the order depends on the resources that processes request at runtime. Also, what if there is a dependency on a service that a job provides not covered by accessing a socket or file? I guess the dependent process itself would have to tell launchd to start the job explicitly.
What if I have unrelated services, which order do they start in? Alphabetical? I know the answer in OSX.
If they're unrelated, it shouldn't matter what order they start in. Since XP, automatic start services and drivers are started in parallel as much as possible, with short pauses between start commands to avoid excessive thrashing, with I guess an arbitrary order. There was a tool, bootvis, which could illistrate and time the start process. OK, so what order do unrelated jobs start in on OSX?
Also, services.msc doesn't allow me an interface to determine whether my list of services has changed or added.
If you want the services data in text, you can export the HKLM\SYSTEM\CurrentControlSet\Services key into a.reg file and diff that with previous versions. There is another control set that represents the previous successful boot, for reference (the number is the LastKnownGood under HKLM\SYSTEM\Select). Someone should write a registryXML translator... they do seem to have a lot in common.
Additionally, launchd allows you to put everything in one place.. whether a daemon starts on boot versus daily or hourly (crontab-type entry), it is tons easier to put these in the same place.
The task scheduler service is for periodic commands, and the SCM for services. You could link the two by making the program a service and then using the task scheduler to issue the start and possibly stop commands, i.e. schedule sc start OnceADay to run once a day. Any dependcies that OnceADay has would automatically be started before it is. One issue might be that those dependencies would be left running even after OnceADay had quit. The general strategy Windows seems to use for possibly unused services is that such services should be sleeping (not using any CPU) and their memory can be paged out at the system's leisure; just let them run all the time.
I put it to you that part of good security is knowing when your system has been compromised.
What I meant is that if your system is compromised, a rootkit may have been installed which can render itself invisible. GUIDs and the size of the registry and system directories certainly don't help matters, so I concentrate on not letting it get to that point.
Hmmm... see Secure Coding Guide to see why launchd can alleviate if not fix completely the whole setuid security issue.
Interesting. The more I learn about launchd and the SCM, the more they seem alike, at least as far as conventions for seperating client user code from trusted, secure code.
I appreciate you taking more time on this response.
Please consider that spyware exists and consider that the nastier types restart themselves via the registry and lock the entries they use to make them uneditable in safe mode.
You're referring to the locations shell's Run ke
How would it be helpful to move these into a text file in the user's home directory? Perhaps the problem is that explorer has too many places where software can be started at logon time-- a problem that won't be affected by where exactly those places are. Besides, you can hold down SHIFT during logon to bypass the things that the shell would start at logon. The system related start locations require high privileges to modify, so if those have been modified your system may already be compromised (short of booting from trusted media). There is no method to 'lock' keys in the registry, other than the security system which administrators can override by forcibly taking ownership.
Large numbers of them are reported all of the time which all people who work in any feild related to IT should be aware of - spyware is the most obvious current manifestation of several of the problems.
Spyware isn't a vulnerability; it's a potential use. Usually, they just take advantage of user stupidity (something available on all platforms). Either it has take over the system by stupidity or a flaw you haven't named, or it's acting within the user's own privileges, in which case Windows doesn't provide any less protection than OSX or standard Linux. Only a system that gives less privileges to a user's applications than the user has can hope to fix this.
Having to remove a compromised disk and load it into another machine that could become compomised to fix this is the time consuming method to fix this - I consider the registry a nasty hack and an obstruction to many basic things including system backups.
You know, if you can access the registry hive files while the OS isn't running (they're locked when it is running), like by making a copy with the recovery console or a PE CD, you can use the registry editor to mount those hives temporarily with the File->Load Hive... option (do it from HKEY_LOCAL_MACHINE) so you can view/modify it. The system hives are in %WINDIR%\system32\config. You can also export the hives in this way (make sure the type is "registry hive files") for backup, and restore them even while the system is running. Reg.exe also provides the same mount/unmount, save/restore hive functionality.
The main problems were of course backing up those registries and file locking on mailboxes. I don't even know if ntbackup can handle files bigger than 2GB - it appears to be old abandonware these days.
If you use it correctly, ntbackup uses the same registry hive save and restore functions as above. Locking isn't much of an issue since at least sv2003, since it uses volume shadow copies to freeze-copy-on-write the locked file during backup so that the lock holder can continue to modify the file while ntbackup gets a single snapshot. Ntbackup definately handles files larger than 2GB. I do it all the time. It's old because it was done properly in the first place and has aged pretty well.
There is a desciption. ok... so how can I tell if that file is supplied by microsoft or is it droppings from malware?
System binaries have digital signatures. Five seconds on Google turned up To verify that system files have a digital signature. Process Explorer can also verify the signatures of loaded binaries. In any case, the system directories are trusted and can only be modified by highly privileged accounts (i.e. admins); if malware can put files in here, the machine is already compromised.
Even dll's are a pain in the butt to look up in the registry.. if I register it multiple times there are multiple entries (each under the GUID, not in English) and it is DIFFICULT to determine which one is "real"
Only COM libraries have GUIDs. The registry is not a dictionary of all libraries. Besides, if the machine registry has been altered by malware, that malware already had admin privileges and might as well have already installed a rootkit by now.
Think about what the complaint is about, even if not well written: NTFS allows secondary streams, and the only programs that use them for the most part are Malicious. The complaint is that the OS allowing access to these streams is YET ANOTHER point of contention. It is not an exploitable hole (in the hacker sense), but it is exploitable by hackers (in the making Windows hard as hell to keep secure). Simple to close that up.., yet Microsoft just seems completely unconcerned.
There are many legitimate uses for alternate data streams. For example, they're used by the summary information in the shell's dialog for file properties. This data is also used by the indexing service. Since the interfaces have been published and supported for a long time, disabling them could break a lot of software for something that admittedly isn't a vulnerability. If you've let malware create files at arbitrary locations on your disk, you've already got a bigger problem. Otherwise, use streams to locate exting alternate streams.
Launchd allows you to specify rights. You get a lot more control of the order processes are started. Launchd, like xinit, allows you to start processes on demand. Launchd can control who/what is allowed to start processes, unlike the "net start" command, "oh it's set to automatic, great, I'll start it" mentality.
The SCM allows you to specify an any account (that has the "log on a service" privilege) you have the password for to run the service as. SYSTEM and the low privilege LOCAL SERVICE and NETWORK SERVICE accounts are also available. Services can be started, stopped, and paused on demand via services.msc or sc.exe or the related API functions. Every service can have a list of dependencies. You can see these with services.msc or sc.exe enumdepend. These dependencies are always started before the service in question starts and must be stopped after the service stops. See About Services.
There are a lot of services that run as SYSTEM, but remember that Win32 doesn't have setuid binaries. Instead, NT uses privileged services accessible only on the local machine that listen for requests. Compare the entire list of setuid binaries plus daemons that run as root (and any dependent libs) on a UNIX to all the processes on NT that have the SYSTEM token (and any dependenent libs)-- these are the comprehensive lists of system trusted user mode binaries for the two platforms.
OK, GUIDs are randomly generated keys that aren't human readable. 128 bits of random space has an infinitesimal chance of collision, unlike text names. I'm not sure of any way in which different parties can independently come up with unique keys without allocating them through a central authority, other than a large random value. Note that the numbers are stored in text, not binary form, and the GUIDs in the registry have associated readable text that can show their purpose as well as any text config file.
{098f2470-bae0-11cd-b579-08002b30bfeb} is apparently the identity of the null persistent handler; it's the class used by the content indexer for files that explicitly don't have indexable content. This class is exported by query.dll. I just looked up the key "{098f2470-bae0-11cd-b579-08002b30bfeb}" under HKEY_CLASSES_ROOT\CLSID.
Administrators have full control over scheduled tasks. Backup operators and server operators (who can already take control of the system indirectly) can create and list tasks.
The accounts that can already control the system can launch SYSTEM processes. So? This is not a hole.
How can "[any] application elevate to SYSTEM without too much trouble"?
The LanManServer service (aka Server) is mostly implemented in kernel mode in srv.sys, so most of the user-mode tirade is irrelevant.
[From the article]
SYSTEM is a pseudo-user (LocalSystem) that trumps Administrator (like UNIX's root) in privileges. SYSTEM cannot be used to log in, but it also has no password, no login script, no shell and no environment, therefore The activity of SYSTEM is next to impossible to control or log.
SYSTEM doesn't trump Administrator(s): since either can control the kernel, they both represent full control. SYSTEM can't magically bypass security descriptors any more than administrators can; both have but indirect end runs available. SYSTEM's profile has the global system environment. In Win32, shells have considerably less importance, but SYSTEM processes can still have them. SYSTEM's actions can certainly be audited, so I'm not sure what they meant by impossible to log.
Most of the code running on any Windows system at a given time is related to services, most or all of which run with SYSTEM privileges, therefore [...]
There are lots of services running as low privilege LOCAL SERVICE and NETWORK SERVICE. Perhaps there could be more. Note that a single svchost can represent several services.
Windows will notify you on an attempt to overwrite one of its own system files stored here, but does not try to protect privileged software.
The binaries that implement system services are protected by system file protection. SFP isn't a security feature; it's there to work around buggy installer behavior.
Windows requires that users log in with administrative privileges to install software, which causes many to use privileged accounts for day-to-day usage.
This isn't true on a domain where the admin has designated installable packages, and RunAs works fine for installation programs that are written properly.
Microsoft made it easy for commercial applications to refuse a debugger's attempt to attach to a process or thread.
I'm not sure what's meant by this, but if your kernel is owned on any OS, a rootkit can be installed to evade any kind of debugging.
Access to the massive, arcane, nearly unstructured, non-human-readable Windows Registry, which was to be obsolete by now, remains the only resource a Windows attacker needs to analyze and control a Windows system.
Non-human-readable? Never used the registry editor? The key and value names seem to be in English... It's like saying that a filesystem isn't human-readable because you need ls. There are no plans to make the registry obsolete for system configuration. In fact, the new boot loader's config database is a registry hive. As for owning the computer throught the registry, every key is protected by an ACL. There's nothing inherant in the registry that allows an attack, privilege escilation or otherwise.
Another trick that attackers learned from Microsoft is that Registry entries can be made read-only even to the Administrator, so you can find an exploit and be blocked from disarming it.
So then the admin takes ownership of the keys in question, forcibly with the SeTakeOwnershipPrivilege, and since the owner of an object can always set the DACL, the admin returns himself full control. Either that or use the SeRestorePrivilege to overwrite the key directly.
One of the strongest tools that Microsoft has to protect users from malware is Access Control Lists (ACLs), but standard tools make ACLs difficult to employ, so most opt for NTFS's inadequate standard access rights.
What's wrong with the shell's ACL editor? What's wrong with the default permissions?
OS X has no user account with privileges exceeding root.
Since root can ignore security, this isn't saying anything. In Windows, only the kernel can bypasss security.
Sadly dialogue is rare in politics, so you never even see this much progress.
I, too, appreciate actually being able to explore a different viewpoint without having it degenerate into a flamefest. If it seems like it takes me a while to respond, it's because you've given me something to think about.
It'd be nice to have more depth in popular politics, but it seems like when politics are actually about an issue the stances are few in number and very simple: the kind of thing that fits nicely into soundbites.
And this has a vast potential of abuse, what if the un-or-underproductive are deemed dead-weight, holding back productive society, would it then be acceptible to remove them?
I wouldn't support the use of force to 'remove' people for the sake of some promise that it will increase productivity. The only reason I can think of for someone to advocate this is to prop up a system that is failing to be productive in the first place; true production doesn't need to steal anything in order to create.
And I think your view might change if you ever had one as a child, or sibling.
It might. Then again, it's possible that it would make me emotionally too close to the problem for rational judgement.
I guess we disagree as to what the responsibilities of government are. I'm all for government acting in the actual best interests of society (not to be confused with what they say are the best interests), but I find it hard to see how supporting permanently unproductive people actually helps society. I'd say it's government's place to provide an environment where people can ensure their own well being and happiness, rather than provide those things directly.
I am optimistic about the ideals of capitalism, when implemented correctly. Unfortunately, reality is not as simple as the bases of capitalism assume; those ideals are not met often. I'm all for looking for solutions to those problems, but I usually like to put things in terms of regaining the ideal. It seems closer to fixing the root of the problem, rather than treating the symptoms. I know that capitalism isn't the end all be all, and am always open to other options; other systems (such as socialism) have much of the same difficulty of implementation and potential for being useful.
What if there comes a point where it is not profitable (or even against the best interests) of the improving party, yet the poor community(s) are still sub-par? It seems it is in the best interests to only increase welfare to the point of production, and never to the point where the poor would be equal in eduction, or potential for earning.
It's possible that the risk could be too high to justify an investment financially, and in this case the government should probably subsidize the venture since it has more to gain from improvement. My investment suggestion is for people/communities who are so poor that they have little to no hope of ever getting out. Once they are making real money, it becomes possible for them to afford to help themselves, with better funding for local schools, college, and many other resources not previously available. The point is to break the vicious cycle.
Exploitation is a long term feature of capitalism, and unions are needed as a balance.
There exist many companies that have never had or needed unions because management understands that worker happiness and appreciation is necessary for long term success. It's only when management fails to understand this (possibly by being too short sighted) worsened when the labor market is severely oversupplied with people unwilling (or unable) to move to other jobs, workers are treated badly enough to unionize. Unions can't even fix the second problem when it is severe enough, because if there are enough unemployed workers management can always fire all union employees and hire the others. This happened with airline mechanics recently, IIRC.
Each person with basic means has some control over how they're treated at work by only working at places meet with that person's standards. If that person has few job options available, then that is the root problem. Poor treatment at those places is just a manifestation of the real problem; it's past time to find another field to work in, as people aren't owed the jobs they want.
I can't even understand this.
Animals can feel and suffer, but it's totally impractical to subsidize the comfort of all animal life. People who can still think, even with physical disability, would seem to still have value-- especially in this emerging information age.
The measurable productiveness of a person (ideally, but not always the same as income) definately says a lot towards the value of that person in my book. Almost everything in modern society depends (past and present) on productive people. Is there more? I guess it really depends on the individual, but productiveness is usually the easisest thing to measure. I do think the Bill Gates is overvalued. It's hard to imagine someone being THAT productive... not that it's impossible, just that megafortunes always seem to be the result of many other things.
What I should have said is that it's not in the government's interest to subsidize the totally incapable. If you feel for them, fine: spend your own money in support. Just don't impose your values on me by having my tax money go to something that can never (by definition) benefit me. It's in my interest to improve people and communities, but we're talking about people beyond the real possibility of improvement.
I agree that there are a lot of people that are poor due to momentum: they start poor and don't have the resources to escape. I'd like to see more investment in the people and communities in this situation, and I mean investment in the standard financial sense with research, input, and risk of profit or loss for the investors. I think that profit is necessary to motivate and keep the operation on track: the goal is to make the person or community more productive (raising their standard of living in the process). It would be in the government's interest to encourage it as well, but not direct control since government projects of this type are prone to corruption and inefficiency.
For one (and for this I will be flamed) we need to bring back Unions and other workers rights organizations [...]
With unions there is the risk that they will outlive their usefulness or suffer mission creep, becoming a leach on the company and its workers. Unions need to have a clear description of purpose and a mechanism to be dissolved/weakened if and when it is no longer needed. Really, the need for a union represents a failure of management to see into the long term.
It gets harder and harder to find a mid level job that offers above 39 hours/week (and thus benefits)
Personally, I think that insurance designed to cover regular medical expenses is a bit pointless, since you can't expect to get more money out of the insurance company than you put in (or else it'd go bankrupt). The only use I see for it is for hedging against the possibility of a catastrophic, expensive disease whose cost would outstrip your ability to pay (assuming it's actually covered). Otherwise, I'd rather have the money myself to put into savings for emergency use, avoiding the overhead of the insurance company. Then it's a problem of the job not providing enough hours, and paying a lower effective wage due to the lack of benefits; it becomes an issue of price discrimination.
The drug companies emphasis on marketing and long term cash drugs is certainly a failure of applied capitalism and the current model of corporate America. I'm at a loss to suggest any solution to this. The fact that the consumers of these products react so well to these tactics isn't helping, either.
Notice the term "free lunch" was never mentioned, though it might be necissary in those cases in which the poor and incapible of work.
How do we decide who is capable of what work? There is a risk of people saying that "I can't work (very efficiently) because I'm stupid." That attitude was pervasive when I was at high school, and the system often played into their hands. Since stupid meant less work, it became very popular. Pure capitalism in this case works nicely because it puts the one person who can really tell if someone is able to work in charge of doing the work.
As for the people who really can't and can never work or contribute anything of value, I don't think it's really in society's interests to help those people. Charities exist for that sort of thing, for people to contribute on a voluntary basis.
We have lost any sense of commitment to society as a whole, we are more worried about ourselves. It seems we have forgotten completely that we are part of society, and benefit from it too.
The thing is that the value of society as a whole, and of culture and those other long term things are hard to quantify. It's hard to work with something so indirect, so I think people are concentrating on what the see as more reliable investments. This usually means spending on ones self, since we know ourselves better than we know others.
I, too believe that we should look for more comprehensive solutions to complex problems, not simple quick fix ideologies. Still, modern society is more productive and has a higher standard of living across the board than any other time in history, and it's only getting better. There are still details to attend to, but I'm not worried about the direction as a whole.
Slashdot Mirror
If you just want to re-use an entire profile from a similar version of windows, you can just copy the entire profile directory, user registry hive and all. In the system control panel->advanced->user profile settings, use the Copy To button. The old profile will need to be in the same "Documents and Settings" directory as the rest of the profiles are to show up in the list. The advantage of using this interface as opposed to just copying it yourself (which can also be done) is that this automatically transfers security access to the new account. This also is how roaming profiles work. FYI, the locations for each user's profile is stored at HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList, keyed by user SID.To copy files, you need something like explorer.exe or cmd.exe. To copy keys, you need something like regedit.exe or reg.exe. To modify conf text files, you need a text editor like notepad or vi. I call these programs tools. I guess there could be some question as to which are specialized or not, but the fact is that you need an interface program for each operation. At the Win32 and syscall level, the registry and file functions exist side-by-side.
- You don't have permission. Administrators can take ownership of any object and give themselves permission. SYSTEM would also be blocked (unless it was specifically granted access) because it can't bypass ACLs directly either.
- A sharing violation. A program like Process Explorer can find out what process has the file opened (opened without FILE_SHARE_DELETE) so you can forcibly close the handle or kill the process. SYSTEM can't delete locked files either.
- System file protection. The file can be deleted, but it comes back. There are several ways to disable system file protection, or you can delete the backup copy of the file at the same time as the original so there's nowhere to get a replacement to restore the file. This effect still occurs even when a SYSTEM authority process deletes such a file.
SYSTEM is just another account on the system, albeit one without a password (like LOCAL SERVICE or NETWORK SERVICE). A SYSTEM authority process is subject to access checks just like every other user mode process (even those of administrators). Only the kernel can bypass security when it wants to.If you're interested, you can start processes interactively as SYSTEM with psexec -s -i -d <program>
To move settings, copy the Application Data directory and the SOFTWARE key from the source profile into the destination profile. It's not rocket science. It's not going to cause your computer to melt. For convenience, the Files and Settings Transfer Wizard from the XP setup CD will transfer all the types of user configuration.
For reasons that only God may know, AIM stores away messages in a file in the user's profile, and the only way to move away messages to a new computer is to export the file(s).
You've failed to explain how is a key in the user's registry worse than a file in the user's profile.
Both have standard naming conventions; for the registry, HKCU\Software\<Company>\<AppName> and for user profiles, %USERPROFILE%\Application Data\<Company>\<AppName>. It's up to the app how well it wants to document these locations and how easy it wants to make exporting settings.
IIRC, KDE and XDM also expect expect to be run as root, although I can't find a reference for that offhand. The instructions for starting them always go "as root, type *DM" or call some startup script as root.
I'm sure that there exist special configurations for running them at a lower privilege level, so that's why I said many (not all) window managers.
I've got a laptop that uses XP's built in wireless support, and I can plug in/unplug the card and manage wireless network connections as both a standard user and a power user (once it was installed).
IIRC, 2000 requries a third-party wireless client. It's possible that that it doesn't support LUA properly. I know that XP uses a privileged service in the background (which the UI running as the interactive user talks to) to do actual control over the network devices. I'm not familiar enough with the various clients to know if they do the same. It's also possible that 2000 had other issues that would prevent it from working properly, issues that were fixed in XP. Have you tried running just the client software as admin?
- Killing the server ends the life of all client processes in all three cases.
- Since all meaningful processes in Windows are Win32 clients (the Win32 server provides more services than just the GUI), this puts the OS into a fairly useless state in the NT3x case.
- In NT4+, the kernel bugchecks, terminating all current activity.
- With X-Windows, all of the user's GUI apps die. For a workstation, this likely represents everything important.
- The server is highly privileged because it has to access the graphics hardware.
- In NT3, csrss runs with the SYSTEM token, effectively granting total control over the computer; if the Win32 server is compromised, so is the machine.
- Since win32k.sys runs in kernel mode, compromising it also grants full control over the machine.
- X-Windows normally runs as root (without resorting to slow wrappers), and so do many window managers. Compromising these also compromises the entire machine. Even if X doesn't run as root, it's likely that unfixable privilege escilations exist due to the control over the video hardware and memory mapping that the X process has.
The issues you've brought up are comparatively minor implementation choices compared to the design of the authorization and authentication systems.X can be somewhat safer with some extra work and overhead.
Windows 95 (and its derivatives) weren't designed with security in mind, but that line of Windows is EOL now. Getting many apps designed for 9x to work on NT requires misuse, usually in the form of excessive privileges.
Ctrl2Cap is a kernel driver. Read the first sentance of the description. If you have the authority to install a kernel driver, you have control over the system. This is true of every OS in existence, short of TCPA. I specifically said that a SAS is useless if the OS is already compromised (along with all other software measures); having malicious kernel drivers installed certainly qualifies as compromised.
Show me an example of being able to disable/intercept the SAS with only the access that a standard (non-admin) user has.
Actually, a better solution for authentication from the OS is a secure attention sequence (SAS), e.g. CTRL+ALT+DELETE on Windows NT or CTRL+ALT+PAUSE on Linux. The OS supersedes any application's attempt to trap this key sequence and puts the display into a mode that only shows OS sanctioned secure dialog boxes. On Windows (and XP with the welcome screen off) this is the "Windows Security" screen. This way, if you always enter the SAS before entering your password, you know that only the OS is receiving it. It helps to build the habit when the OS always asks you for the SAS before entering passwords.
The new authorization dialog boxes in Vista are like this; this is the reason they take over the desktop. IIRC, you can hit CTRL+ALT+DELETE while one of these is up and you'll know its authentic because it'll stay there (if it weren't you'd switch to the "Windows Security" screen instead.)
Of course, these are useless if the OS is already compromised, but the whole idea is to keep it from getting that far.
That was ten years ago. A lot has been done for concurrency since then.
For example, Windows Server 2003 Kernel Scaling Improvements (Google MS Word->HTML version)
I agree completely that there are uses for lots of address space and 64-bit computing. What I was questioning was if the OP was actually had need of them. The OP didn't seem to understand the implications of 64-bitness very well.
Apple only provides 32-bit kernels that can support both 32 and 64-bit processes in user mode (one for PPC and one for Intel). Microsoft provides both a 32-bit kernel that can run 32-bit processes and a 64-bit kernel that can run both 32 and 64-bit processes. The system processes run in the same mode as the kernel in both cases.I, for one, don't plan to buy a new machine anytime just to upgrade to Vista. There are other features besides the eye candy that might be nice to have. I'm sure this machine is capable of running Vista (I've been trying the betas for while now), but it's far from compatible with the 64-bit version.Microsoft always publishes a hardware compatibility list with their operating systems: check it. Check with the manufacturers of your hardware to see if and when they will provide appropriate drivers.
What are you talking about? File access is handled by the filesystem. When you mount an existing fileystem, its files continue to have the same security descriptors as they did before. The only access check done when opening a file is against that file's SD. In order to have the behavior you're implying, Vista would have to intentionally modify the SD of every file to some ridiculous default, just by mounting a volume-- a behavior I've not witnessed and seriously doubt exists.
What it sounds like is ACTUALLY happening is that you assigned ownership and sole access to a local account from your previous installation that does not exist in the new Vista installation's account database. Since no account on the new installation can match the unique SID of the old account in the previous installation, you are not granted access. This behavior has been the same in every version of NT. In UNIX terms, you've assigned ownership and group on the files to a uid that doesn't exist in this installation.
Usernames are not assigned access to and ownership of objects; SIDs are. A SID is a binary value that is used as the primary key identifying a user or group. A unique local account SID contains a randomly generated prefix that was generated during installation and a sequential suffix for the specific user. With the machine's prefix, no two unique SIDs from different installations can be the same. Even if the account name matches in the two installs, the accounts will have different SIDs.
When you said that "you have to go and Take Ownership of every item on the drive, and then give yourself Full Control" (emphasis mine) you're setting yourself up for failure if you ever try to access the volume from another installation that (again) can't and won't have information about the local accounts from this installation. If, in the future you want to assign access consistently across installations sharing a volume, assign access to non-unique groups such as Users and Administrators. The SIDs of these groups are the same regardless of installation. Either that, or join both installs to a domain and use domain accounts.
There are a lot of services that run as SYSTEM, but remember that Win32 doesn't have setuid binaries. Instead, NT uses privileged services accessible only on the local machine that listen for requests. Compare the entire list of setuid binaries plus daemons that run as root (and any dependent libs) on a UNIX to all the processes on NT that have the SYSTEM token (and any dependenent libs)-- these are the comprehensive lists of system trusted user mode binaries for the two platforms.
OK, GUIDs are randomly generated keys that aren't human readable. 128 bits of random space has an infinitesimal chance of collision, unlike text names. I'm not sure of any way in which different parties can independently come up with unique keys without allocating them through a central authority, other than a large random value. Note that the numbers are stored in text, not binary form, and the GUIDs in the registry have associated readable text that can show their purpose as well as any text config file.
{098f2470-bae0-11cd-b579-08002b30bfeb} is apparently the identity of the null persistent handler; it's the class used by the content indexer for files that explicitly don't have indexable content. This class is exported by query.dll. I just looked up the key "{098f2470-bae0-11cd-b579-08002b30bfeb}" under HKEY_CLASSES_ROOT\CLSID.
Administrators have full control over scheduled tasks. Backup operators and server operators (who can already take control of the system indirectly) can create and list tasks.
The accounts that can already control the system can launch SYSTEM processes. So? This is not a hole.
How can "[any] application elevate to SYSTEM without too much trouble"?
[From the article]
SYSTEM doesn't trump Administrator(s): since either can control the kernel, they both represent full control. SYSTEM can't magically bypass security descriptors any more than administrators can; both have but indirect end runs available. SYSTEM's profile has the global system environment. In Win32, shells have considerably less importance, but SYSTEM processes can still have them. SYSTEM's actions can certainly be audited, so I'm not sure what they meant by impossible to log.
There are lots of services running as low privilege LOCAL SERVICE and NETWORK SERVICE. Perhaps there could be more. Note that a single svchost can represent several services.
The binaries that implement system services are protected by system file protection. SFP isn't a security feature; it's there to work around buggy installer behavior.
This isn't true on a domain where the admin has designated installable packages, and RunAs works fine for installation programs that are written properly.
I'm not sure what's meant by this, but if your kernel is owned on any OS, a rootkit can be installed to evade any kind of debugging.
Non-human-readable? Never used the registry editor? The key and value names seem to be in English... It's like saying that a filesystem isn't human-readable because you need ls. There are no plans to make the registry obsolete for system configuration. In fact, the new boot loader's config database is a registry hive. As for owning the computer throught the registry, every key is protected by an ACL. There's nothing inherant in the registry that allows an attack, privilege escilation or otherwise.
So then the admin takes ownership of the keys in question, forcibly with the SeTakeOwnershipPrivilege, and since the owner of an object can always set the DACL, the admin returns himself full control. Either that or use the SeRestorePrivilege to overwrite the key directly.
What's wrong with the shell's ACL editor? What's wrong with the default permissions?
Since root can ignore security, this isn't saying anything. In Windows, only the kernel can bypasss security.
It'd be nice to have more depth in popular politics, but it seems like when politics are actually about an issue the stances are few in number and very simple: the kind of thing that fits nicely into soundbites.I wouldn't support the use of force to 'remove' people for the sake of some promise that it will increase productivity. The only reason I can think of for someone to advocate this is to prop up a system that is failing to be productive in the first place; true production doesn't need to steal anything in order to create.It might. Then again, it's possible that it would make me emotionally too close to the problem for rational judgement.
I guess we disagree as to what the responsibilities of government are. I'm all for government acting in the actual best interests of society (not to be confused with what they say are the best interests), but I find it hard to see how supporting permanently unproductive people actually helps society. I'd say it's government's place to provide an environment where people can ensure their own well being and happiness, rather than provide those things directly.
I am optimistic about the ideals of capitalism, when implemented correctly. Unfortunately, reality is not as simple as the bases of capitalism assume; those ideals are not met often. I'm all for looking for solutions to those problems, but I usually like to put things in terms of regaining the ideal. It seems closer to fixing the root of the problem, rather than treating the symptoms. I know that capitalism isn't the end all be all, and am always open to other options; other systems (such as socialism) have much of the same difficulty of implementation and potential for being useful.
Each person with basic means has some control over how they're treated at work by only working at places meet with that person's standards. If that person has few job options available, then that is the root problem. Poor treatment at those places is just a manifestation of the real problem; it's past time to find another field to work in, as people aren't owed the jobs they want. Animals can feel and suffer, but it's totally impractical to subsidize the comfort of all animal life. People who can still think, even with physical disability, would seem to still have value-- especially in this emerging information age.
The measurable productiveness of a person (ideally, but not always the same as income) definately says a lot towards the value of that person in my book. Almost everything in modern society depends (past and present) on productive people. Is there more? I guess it really depends on the individual, but productiveness is usually the easisest thing to measure.
I do think the Bill Gates is overvalued. It's hard to imagine someone being THAT productive... not that it's impossible, just that megafortunes always seem to be the result of many other things.
What I should have said is that it's not in the government's interest to subsidize the totally incapable. If you feel for them, fine: spend your own money in support. Just don't impose your values on me by having my tax money go to something that can never (by definition) benefit me. It's in my interest to improve people and communities, but we're talking about people beyond the real possibility of improvement.
The drug companies emphasis on marketing and long term cash drugs is certainly a failure of applied capitalism and the current model of corporate America. I'm at a loss to suggest any solution to this. The fact that the consumers of these products react so well to these tactics isn't helping, either. How do we decide who is capable of what work? There is a risk of people saying that "I can't work (very efficiently) because I'm stupid." That attitude was pervasive when I was at high school, and the system often played into their hands. Since stupid meant less work, it became very popular. Pure capitalism in this case works nicely because it puts the one person who can really tell if someone is able to work in charge of doing the work.
As for the people who really can't and can never work or contribute anything of value, I don't think it's really in society's interests to help those people. Charities exist for that sort of thing, for people to contribute on a voluntary basis. The thing is that the value of society as a whole, and of culture and those other long term things are hard to quantify. It's hard to work with something so indirect, so I think people are concentrating on what the see as more reliable investments. This usually means spending on ones self, since we know ourselves better than we know others.
I, too believe that we should look for more comprehensive solutions to complex problems, not simple quick fix ideologies. Still, modern society is more productive and has a higher standard of living across the board than any other time in history, and it's only getting better. There are still details to attend to, but I'm not worried about the direction as a whole.