LUA Allowing Write Access to Windows & Program Files

Hi All,

I am running XP Home SP3 and have recently begun using a Limited User Account (LUA) along with System Restriction Policies (SRP) via the automatic setup contained in Pretty Good Security (PGS - thanks Sully!). PGS seems to have done it's job as nothing launches from anywhere except c:\windows or c:\program files, however the LUA doesn't seem to be offering the protection I thought it would.

I have read many references stating that a LUA prevents write access to c:\windows and c:\program files, but I am still able to manually copy and create files in both these locations from user accounts. This includes accounts which were created as LUAs and are not just converted Admin accounts.

Using FajoXP I see that under Advanced Security Settings for Users there is a "Read, Execute" Permission and also an additional "Special" Permission which grants users the right to "create files/write data" and "create folders/append data". These permissions have been inherited from the parent location ie. the root directory.

Is this normal or has some program maybe created this "special" permission? Am I even right in expecting a LUA to prevent a user from having anything but read/execute permission on these folders?

 

The default security on a workstation is as follows:

Admins - full access to just about everywhere

Users - read/execute access to just about everywhere, write access to only user profile areas. Custom made directories (those made after installation) by the user are devoid of any real security policy, except those that would be inherited.

Normally, you can create a directory in c:\ and make your custom content there. As a User does this, the user is the owner, so they inherit owners rights which is pretty much full access.

Normally, a user may not modify/delete any files/directories in root (c:\ ) that are in a default install. You know, boot.ini, ntldr, etc. Program files and windir are also locked down. The inheritance is probably the issue you are having here.

Suffice to say that if you create a new user account, and that user is allowed to write/modify to windir or program files without admins privelage escelation, there is an issue.

From my experience the issue normally comes from an account being admin and then demoted to user. The user rights are present, but the user himself (who was admin) is still the owner of many objects, and the owner has full access normally.

Creating a brand new user account with membership only in the users group should not grant any rights to the user at all to windir or program files.

It is higly possible also that if you are using xp home, there are issues not resolved by you yet. But I don't normally mess with home versions, so cannot give a 100% accurate answer.

You can look at defltwk.inf in c:\windows\inf and here you can see every permission that is assigned at installation. If a user gets only GRGX (that is generic read and generic execute) on a file/object, and your user can somehow get around that, you are most likely also the owner.

Sul.

Edit: Also, I have played with this and found it to be true most of the time, but if you create a user account from the control panel applet, the user is actually a Power User, who does have elevated rights above a user and could do I believe what you are talking about. Creating a user from the snap-in (mmc) Computer Managment (right click on my computer to access this) and creating a user creates a user in the User group NOT the Power User group. This does not seem to be 100% accurate, but it is something to check.

 

No, it's most certainly not normal. Limited users (user accounts who are members of the Users group, and have no membership in any higher privileged groups like administrators or power users) by default have only read and execute permissions on Windows and Program Files folders. In your case, something has messed up the default permissions. That something is likely to be whoever built your computer: many large PC manufacturers have, in the past, set insecure permissions on their systems possibly to make it "easier" to use them. It's very unlikely that the permissions were changed by any program you installed afterwards - I haven't ever seen any legit piece of software that would go around messing up the default permissions like that.

Strange. I've never seen that happen in about a gazillion cases. When you choose to create a limited user account from the User Accounts control panel applet, it creates a limited user account, not a power user one. If one has been able to reliably reproduce and document that behavior of the control panel applet creating power users when it should be creating limited users, that should certainly be reported as a bug to Microsoft.

 

Thanks Sully for the reply.

I have used the program AccessEnum to identify the folders/files owned by my previous admin account as I was aware of the ownership issue carrying over from a "converted" admin account. However I have been doing my file access testing in limited accounts which were created when I installed XP Home, as having teenagers in the house I always ran them as limited users. (Yes I know what you are thinking - it's all their fault!!).

I had a look at defltwk.inf but couldn't make too much sense of it. I had previously tried to reset file permissions via secedit using the settings in defltwk.inf (as suggested by tlu in another thread) but it failed, saying I couldn't change permissions for a built-in account. With regard to the issue of power users, I don't have the option to create users within the Computer Management module, I only seem to be able to use Control Panel.

I guess the real issue is can (or even should) I change the permissions for these two folders? Is a LUA a waste of time if these two folders can't be locked down? If so should I change permissions for all existing sub-folders and files within windows/program files? There are some files within windows which have unfamiliar ownerships and I don't want to hose my machine completely!

Thanks again.

 

Thanks Windchild for your reply.

My computer is a Dell but has undergone many changes (CPU, Video Cards, Hard Drives etc.) in the 10 years (OMG is that how old it is!!) since I've had it.

You got me thinking though that not long after I installed XP I realised I needed a new hard drive. I installed the new one and used a Seagate Drive Management utilility to make the new drive the master and the old one the slave and at the same time copy the old drive contents to the new one. That may be what screwed the permissions up?

 

I stumbled on that perhaps a year ago. I have tested it in vm boxes using different versions of XP, and found it to be true. I started advising to use the snap-in or a command line method to create users accounts. Sorry, I don't remember much other than I have tried it and indeed, the CP applet made a PU instead of a User.

I am not sure it is a bug, as I found it somewhere when looking up permissions or something like that. I am sure though that I tried it multiple times, so it was reproduced. I will see if I can do that again tommorrow and see what happens.

I thought it was very intersting.

Sul.

 

Home Edition, Professional or converted to Professional using the hack mentioned in one of the LUA + SRP topics? If it's been converted to Professional as mentioned, then what you describe is exactly the results I got when testing the Home to Pro conversion. It renedered LUA + SuRun useless even though the accounts created were for sure listed as LUA, there was no way to get rid of the "Special Permissions" you mentioned even when resetting file permissions. At one time, some time back, I could even convert my Admin account to LUA and LUA + SuRun worked perfectly. My latter day and last attempt of this was a waste of time since it appeared that everything was being run as a full blown admin, at least SuRun saw it that way. I mentioned it in this thread https://www.wilderssecurity.com/showthread.php?p=1590689#post1590689
In the end, I never could figure out what the difference was compared to successfully doing it months prior to my last attempt. I don't know if it was some Win updates, or the latest version of SuRun or a combo of both. Anywho, I gave up on it and decided to go with the security I trust the most, me + Eaz-Fix + Imaging.

 

It's possible, I suppose, although I haven't used any Seagate drive management tools. More often the culprit is the installation media customized by the PC manufacturer so it creates non-standard file permissions - or sometimes a FAT32 file system which is even worse, considering then there's absolutely no security...

LUA isn't worth much if the file permissions are messed up so that LUA can write to system folders, especially if it can not only create new files in system folders but modify existing ones. For LUA to be worthwhile again, the permissions would need to be returned to MS defaults, and those strange special permissions that allow LUA write access to system folders deleted.

The VM may explain it. I never test these things in VMs, since VMs can be and frequently are very quirky. For testing anything, I suggest doing it outside the VM. Or at least, first doing it in a VM, and if the result seems weird in the least, then testing it in a real system to see if there are any differences.

I can open a real XP Home (and Pro, too) system with default settings as they come from MS, right at this moment, and create a new "Limited" user account from the User Accounts control panel applet. And what happens? It's created, as it should be, as a limited user account - no membership in the power users group or admins or any other group of higher than user privileges, and it most certainly does not have any write privileges in system folders (with the obvious, by-design exceptions like Temp). And that is, of course, how it's intended to work. If creating a new "Limited" user account from the control panel applet creates a power user account instead, that is certainly a bug (or perhaps someone having seriously hacked up the OS so that account creation gets messed up) and a very strange bug at that, seeing how it seems not to occur in most cases and there seems to be no MS documentation that suggests that is the intended behavior of the control panel applet. The control panel applet has descriptions for the "Limited" account type that contradict the abilities of a power user account. Power users can write to system folders and can install programs, but the applet clearly states that Limited accounts cannot always install programs. None of the abilities of power users are mentioned in the description of "Limited" accounts in the control panel applet.

Now, I can see that if one was to upgrade to XP from NT 4 or something as ancient as that, one might get weird group memberships for users due to the changes in the security between those operating systems. But other than that, I'd blame it on the VM or the side effect of some hack made by a user. I'd be extremely surprised if you could consistently reproduce the "Limited accounts are created as power users by the User Accounts control panel applet" behavior on a real system with default settings from MS.

 

Why?.. I've never experienced any quirkiness, interesting that you have. In practical purposes they are real machines and would recommend testing.

 

Why? Because VMs are sometimes quirky and sometimes that gives you the wrong results when you test things. Of course, most of the time they work just as a real system would. Sometimes, however, they don't work quite that well. And it's those sometimes scenarios that can really mess up testing. Many are the software developers who thought that because their new version worked fine in a (insert OS here) virtual machine, it would also work fine on a real system - but were later shown to be mistaken as the bug reports rolled in. VMs are very useful. But they have their flaws. To test something in a VM is a good idea if you don't have real machines to use for testing or if the quality of the test results isn't extremely important. However, expecting that because something works like X in a VM, it will also with absolute certainty work like X in a real system, is expecting too much. Especially with complex software, including malware that is VM aware. I've seen my share of quirky behavior in VMs and reported enough bugs in virtualization software to prefer testing on real systems where it is practical and reasonable. Most users would do just fine with testing things in VMs, but sometimes that may lead to results that are different from what would happen on a real system. But, I digress... my point originally was that if something works in what feels like a strange way when you test it in a VM, it's often worth testing it also on a real system, because it might be just a glitch-by-VM kind of thing. I've come to distrust VMs due to what I've seen, and that's why I avoid testing in VMs, except when I don't care much about how accurate the results are.

 

I guess you're referring to this post of mine? You tried to apply these steps while you were in your admin account, weren't you?

 

Yup I can confirm this. I remember when I first discovered the whole LUA+SRP approach to security. I even posted on these forums that "limited" users were having write access all over the place (when created with the : Control Panel -->User Accounts--->Add User--->Limited).

The way I got around it was by opening up Explorer, right clicking my C: drive (I only have one HD), selecting Properties, going to the Security tab, clicking Advance, then in the Permissions tab, removing everything from Users except Read And Execute. Then clicking Apply. Problem solved.

Then to make sure no lingering elevated permissions were left I clicked on the Owner tab, made sure Administrators was the owner, then clicked Apply.

All problems solved. Users can only write to their User folder and the Admin owns everything on the pc.

It should be noted my machines are XP Home hacked to XP Pro.

 

So the problem only happens on xp home->pro converted machines?

*EDIT*

maybe I've answered my own question. I hardly ever use XP anymore but I have a XP Pro virtualbox setup and I was not able to write to unauthorized locations in the limited account - created, no less, via the CP when I setup the vm.

 

OK, this sounds very similar to what I described then. I can't remember the details of my last attempt on this but if I remember correct, I also did as you suggested here but ended up hosed. I may have to give this another one last try which I said I wouldn't do,lol. Are you still running it this way Home to Pro?

 

Fortunately not my experience developing a driver or whatever through pre alpha to release vms will stay invaluable saving time and money.

This one gets put out quite often for not using a vm, in fact there is quite a lot you can do to stop vm detection. Personally, and I work with malware every day, I use VMWare for it's snapshots or a write cache card, but sometimes in a live assessment it is important to use the actual machine that is compromised.

sorry for any OT remarks.

 

I'm thinking this thread is proving that hacking the registry to convert a home version to a pro version is none too reliable.

 

It's not. The only benefit one would get would be the UI for Group Policy/Local Security. Anywho, I've just tried the LUA + SuRun once again,lol and the only Standard User apps that are recognized are the ones that have already been pre-defined in the registry under 131072. Everything else launches as full Admin. I'm going to double check zopzop's comments and go from there before rolling this back

 

That is interesting stuff. In your case, there seems to be nothing that implies the "Limited" users are created as power users from the control panel applet as was suggested earlier - instead, it's simply that the Users group is being given permissions that it should not have by default. IOW, it's not group membership that's the issue, it's just non-standard file permissions for the Users group. If the limited users had really been created as power users (members of the Power Users group), then changing those file permissions for the Users group would not have solved the problem of being able to write to system folders, since the Power Users group would still have write permissions to those folders (Modify permissions, more accurately). So, the fact that changing the permissions given to the Users group solved the issue actually proves the "Limited" accounts created from the control panel applet were not power users but just normal limited users that only have membership in the Users group, not in Power Users group. But in any case, Users having write access to system folders is non-default and is a problem. Come to think of it, that sounds a bit like someone had applied the Compatws.inf security template on the system...

But from what you guys have posted, it sure does sound like whichever hack was used on XP Home to get Pro features enabled also mucked up the file permissions for your systems. Well, "hacks" can cause unexpected issues at times, which is one good reason to avoid them. Anyone remember which particular hack was used before you experienced this issue? FajoXP was mentioned by the original poster, so perhaps that is one possible culprit.

Yeah, I certainly don't mean to label VMs useless. They obviously have many uses. I just don't trust them to always act like real systems would, since they - well - don't. That's why it's worth testing things on a real system if strange things are happening in a VM...

As far as VM detection is concerned, I find that many people, even those who are supposedly professionals, often forget the very existence of VM aware malware. AV companies have missed samples being malicious because they didn't do anything in VMware... While preventing detection can be so easy it happens by accident (as in the malware detects pretty much one VM software and fails to detect any others that are still commonly used), I don't know a lot of people outside security professionals that actually take measures to prevent VM detection by malware...

But it's an interesting topic to me - the whole test in VMs vs test in real systems. VMs have the ease of use going for them, while real systems tend to deliver more accurate results in testing.


Anyways, sorry if my post is a little convoluted. It's pretty late here and I'm short on coffee, so...

 

Hi all.

Greg S, I am running XP Home with SRP provided by Sully's PGS, with FajoXP providing access to the Security Tab in File Properties. Other than that it is a standard SP3 installation.

Yesterday I tried the automated fix to return all security settings to default as outlined in Microsoft KB Article 313222 but it still didn't seem to touch my file permissions. Microsoft stated that only the automated fix could be used for XP Home editions. The manual fix for other XP versions appears similar to the one outlined by tlu, except it doesn't use the defltwk.inf file.

BTW tlu, you may be right, I might not have been logged in as admin at the time I tried your fix - doh! I am a little wary of trying it again given the MS recommendation to only use the automated fix. Has anyone else used tlu's fix successfully?

Last night I had a good look around on a friend's totally standard XP Home computer. I used safe mode to access the file security settings and lo and behold users only have read and execute privileges on c:\windows and c:\program files as expected. After noting their settings I am now in the process of learning to understand how the different permissions, inheritances and ownerships work and seem to have set them up correctly on some dummy files and directories. Now I just have to work up the courage to apply them to the real folders!!

Thank you all for your input. I have been lurking on Wilders for some time now and appreciate the efforts a lot of you put in to helping others.

 

tlu's fix did work at one time, but now for whatever reason neither fix will work. I've just now finished upped testing all this out once again with no successs. Despite being a limited user I am still an Admin according to SuRun. The only exception that is seen by SuRun as being Limited, is the additions I've made to 131072. SuRun sees them as Limited. I also worked with it manually as zopzop mentioned(below) with no joy.

One other thing I did, was restored an image just prior to my home to pro conversion with the results being the same. Months back, I had this working beautifully. The only reason why I restored out of it was because of two apps that wouldn't work right even though I had set the proper permissions on the files for them to work. On a hunch, I monitored the install/uninstall of them and noticed that each needed full rights in their two reg entries which I didn't even know existed until monitoring as mentioned. I noted the reg entries, set the permissions and both worked. I restored back out of the successful fix, waited a couple of months, decided to give it another go with the addition of the Home to Pro conversion and now it won't work anymore. In that two month time span, something changed other than the Home to Pro conversion and it's keeping all this from working the way it's suppose to.

 

No. I observed this problem also on "real" XP Pro machines.

 

I haven't had any problems. Zorak mentions that he might not have been logged on as admin while applying these changes. This would certainly explain his problems.

 

The only time in my own experience with XP Pro over the years of this (similar anyways) happening occurred when I mucked with permissions the wrong way and introduced excessive "liberalness" to the user account, obviously my fault. However, I can certainly take your word for it. I just don't know what could cause the problem unless someone introduced something carelessly to the system, whether it be a hack or other mod, a virus or some software not compatible with the O/S.

Okay, I see. Are the registry mods written only to the user hive key? Anywhere else I don't see as being possible from a user account.

 

Hi again.

OK, I have now changed the permissions on the windows and program files folders myself and so far everything seems to be working as it should. Users can no longer create/delete files within these folders. I will see how things go for a while before i change the ownerships left over from my old admin account. In the meantime how can I tell if the security settings in the registry were changed correctly by the Microsoft automated fix, given it didn't work for the file permissions?

While examining the previous permissions I did notice something that seemed a bit strange. On my friend's standard XP Home machine the windows and program files folders were set so that they did not inherit any permissions from the parent folder, they had their own set of permissions. However on my machine they were set to inherit the permissions from the parent ie. the C:\ root directory. In fact even the C:\ directory was configured to inherit permissions. I would have thought the root directory was the ultimate "parent", where would it inherit anything from?

Does this again implicate the Seagate Drive Utility used to transfer the operating system from my old hard drive?

 

If you examine the default workstation security template (the defltwks.inf file) in both computers, you will discover the implementation of the rights at install. It does show the inheritance properties. Once you determine that both computers were intended for c:\ to inherit (or whatever you are looking for) then you can better narrow your scope to items like seagate tool or whatever that might have changed the scheme.

You can likely use the security templates tools (in Pro) to fix your issues. I am afraid I cannot give a clear-cut method to do this, but there are lots of nice tutorials and guides around that should help. I have used it many times in experimentation, but you should be able to restore rights and inheritance to all default objects and containers without much effort.

Sul.