prp8683

True, but there are situations where: 1. A user must run a particular program which requires administrative rights 2. That user is not trusted to have administrative rights Altering permissions to allow the application to run in the restricted user's context may work, depending on your security needs. (The application may require access you would not otherwise grant the user; e.g. an application which must load a device driver, and you don't want the user fiddling around with devices otherwise; in this case, granting the permissions required to run the program gives the user more access than you want. On the other hand, if the app simply stores user preferences in a global location and you don't care about the user changing system-wide preferences for that app, changing the permissions is probably OK.) The Run-As method you mention is useful for admins to use non-priviliged accounts and quickly gain priviliges to perform specific functions, but it requires that the user know an administrative password, thus defeating item 2 above. What is needed here is some mechanism that allows an admin to say that 'user x is allowed to run program y with the priviliges of user z, without knowing user z's password'. *nix systems do this with the sudo program, but Windows doesn't provide that functionality. Perhaps Vista will provide this, but I'm not holding my breath.

The exe must be decrypted before it is executed, and if it stores the user/pass in encrypted form, it must decrypt those before passing them to the API functions that log the user on to do whatever the script does. Connecting a debugger to the process during this procedure will reveal the userid/password.

Of course. I merely point out that even supposedly novice users tend to be smarter in some cases than admins take for granted; just ask the IT director for any school district... True, though a blanket policy allowing *.dll would work; it's rather difficult to load an arbitrary DLL if you cant load an arbitrary EXE. (most apps don't use all that many .EXE files. Just make sure rundll32.exe and similar programs are blocked) Quite true. Task manager can be disabled by policy, but for those apps that can't, blocking access to them for users who shouldn't use them is a good idea as well.

You also need ntldr and ntdetect.com, as well as ntbootdd.sys if you have a SCSI (or anything that looks like SCSI to Windows, including most ATA/SATA RAID controllers) boot disk. You may also need to alter boot.ini to reflect any changes to the partition/disk order on the box.

Software Restriction policies in Group Policy might work for you as well. Note that even making an app the shell for a user doesn't guarantee security if the application in question allows users to execute other programs and/or provides access to file open/save dialogs. (navigate to \windows\system32, type *.* in the name box, then find CMD.exe, right click and select Open. Instant command prompt, from which the user can alter the registry to set the shell to explorer and log out/in to get a full shell.) If your app (or any apps it launches) use the standard file dialogs, you can use policy restrictions to prevent them from being misused. 1. Hide unnecessary drives from the shell using policy 2. disable shell context menus 3. Use policy to disable things such as the registry editor and command prompt. 4. etc... (play around with the settings under Administrative Templates in Group Policy. Note that setting Local User Policy on an XP box will affect ALL users on that box, but you can obtain the corresponding user-specific registry settings by opening c:\windows\inf\*.adm in notepad.)

No need for this; traverse checking merely verifies that the user has Traverse Folder (execute) permissions for the parents; it doesn't check read/write or other permissions. Also, it's on by default for Everyone, and removing that entry breaks things. (the default permissions aren't set up to be compatible with this, and from what I've read, the traverse checking algorithms are broken in recent releases. At the very least, SYSTEM requires this right or bad things happen.) All that is required is to configure READ access on the parent, then add write access to the child. (Note that if an explicit DENY ACL for write access is attached to the parent folder, ACL inheritance must be disabled for the child, or the DENY will be inherited and override the ALLOW.)

You can change the permissions on this key to prevent them from doing so. (do the same for RunOnce, RunOnceEx and half a dozen other keys that do essentially the same thing.) Actually, they're executed during the logon process, but being in HKLM, they're executed for ALL users, so if a power user alters the key and an admin then logs on, whatever the power user added will run in the administrator's context. Anyone who has sufficient rights to install most software can install binaries that will subvert the system the next time an administrator logs on, since most software installers demand write access to the system folders and sensitive registry keys. You're probably better off installing software for them if you truly want to keep your system secure; that way you can verify that the software they want to install is safe. (Yes, it's a pain, but allowing inexperienced or untrusted users to install binaries to global folders is inherently insecure.) Quite a few. Depending on your setup, power users may be able to schedule tasks with the AT command, which subsequently run as SYSTEM. Among many others. (Even Users isn't totally secure in a default XP install, unless you tweak registry and filesystem permissions.) -- Phil

Not sure about XP, but on 2k AutoPartition removes all partitions and creates a single new one. (Never really done a full unattended on XP; I generally use an imaging tool with sysprep for normal systems and XPe for specialized stuff.)

Don't use this anywhere you really need security; it's still possible to retrieve or modify the script data (including the credentials for the admin account) by running the resulting EXE thru a debugger and watching as the data is decrypted. Hopefully MS will someday add real SUID support to Windows, and this will become a non-issue. -- Phil

That is a function of the BIOS on those systems; there are some mainboards with this function (my Gigabyte board has it) but it's not all that common outside of big-name boxes. You could set up a second partition on the box and preload it such that booting from it does an unattended install of Windows onto the first partition, then makes the 1st partition active. Make sure that the boot.ini on the 1st partition has a boot option to boot from the 2nd partition, so that should the primary OS get screwed up, the 2nd partition can be booted to restore it. Of course, should the boot loader (ntldr, boot.ini, etc) get messed up, you're out of luck unless you boot from an alternate media to reset partition 2 active. (That's why the big-name systems implement this in the BIOS rather than the boot loader on the disk.) You can partially protect the boot loader by placing it on partition 2 and/or on a small boot partition elsewhere, and making sure that the boot loader's partition is not assigned a drive letter, though this is easily circumvented. (Not sure how ntldr identifies the filesystem of it's boot partition; if it uses the boot sector instead of the partition type in the MBR, you might even be able to set the hidden bit for the boot loader's partition and still boot from it.) -- Phil