User permissions in WinXP?

[THRESHIN]

hi, first off thanks to anyone who can give me any help at all. i REALLY appreceate it.

*if you don't care about the story/song & dance just skip to the last paragraph.*

i'm looking to possibly set some strict local policies/restrictions using windows XP home.this is all local too.

ok, here's the scenario: my girlfriend gets back from college with her new computer. family is using a pentium 166....yeah i know, stop crying....so they decide its high time they all use her computer. silly, but whatever. she didn't mind. the problem is this: they are real dolts at running a computer. these are the kind of people who you ask to specifically NOT to install something and the first thing they do is go ahead and do it anyways....fun times.

long story short, she's the most expereinced computer user there (sad...really really sad....) and we want to keep her as administrator and the default log on a user account. i can do this easy so it totally bypasses the admin account right into windows. simple. the problem is that i am an absolute DUNCE with networking/permission stuff like this.

does anyone know any tutorials on creating strict polocies such as allowing what files can be accesses/written to by a specific user? is there a way to prevent a user from installing programs? anything at all....i looked through windows help and found it pretty useless (what else is new..)

thanks again guys, i REALLY appreceate this

 

[Iclisx]

Just put passwords on all accounts other than the guest account.


The guest account doesn't have write priveleges to the system drive outside of some temp directories and the "%systemroot%\documents and settings\guest".

Thus the only place they could install a program is to thir local profile, and that's deleted each time the guest logs out. If you want to allow them to save files somewhere, you could make a separate section of the drive writable to the guest account.

Note that some poorly written programs will fail when dooing this. Some programs don't correctly go out to temp directores of the user profile for storage, rather they use the directory they were installed to. For example, if you tried to save a Diablo2 game in progress, it would fail since I thing that game keeps it's save games in the program files. In that case though, you could specifically give the user rights to write to the savegame directory.


Edit: If it wasn't already clear, the ability to install a program is equivelent of writing that program to disk. By default a normal user doesn't have write access to any system directories (including program files) so they can't install programs into those locations. However they could install a program to any place that they have write access to (like into their profile directory, on to their desktop as an example). However, for programs to run they often need write access to save files. The guest account gives them these rights, but wipes out anything in the guest profile durring logout.

 

[Flying Fox]

Just in case your girlfriend's computer is not running Windows Update 24x7 it may also be a good idea to lock down IE as well. Seems like these days the attack vectors of malware are mostly from clicking links from IE.

I remember back in the win9x days there's a local policy setting to allow only named programs to run on the system. Not sure if this is still available on XP. Heck, I don't even know if those policies stuff is available on XP Home (in the process of checking). Just give them access to Notepad only and see how they can crack it...

[As a plan B though, it's probably a good idea to ghost the drive and reimage every 2-3 weeks if it is really that chaotic... ]

 

[THRESHIN]

thanks a lot for the help guys. its somewhere to start. didn't know what the guest account would allow/not allow until now....very interesting....

 

[Iclisx]

Originally posted by Flying Fox
Just in case your girlfriend's computer is not running Windows Update 24x7 it may also be a good idea to lock down IE as well. Seems like these days the attack vectors of malware are mostly from clicking links from IE.

I remember back in the win9x days there's a local policy setting to allow only named programs to run on the system. Not sure if this is still available on XP. Heck, I don't even know if those policies stuff is available on XP Home (in the process of checking). Just give them access to Notepad only and see how they can crack it...

[As a plan B though, it's probably a good idea to ghost the drive and reimage every 2-3 weeks if it is really that chaotic... ]

Installing any programs, even malware requires write access to an install location. If you force usage of the guest account, users won't have rights to install malware.

Specifically those IE named objects that people tend to install usually require access to the HKLM registry hive, which only admins can alter. They also require a place to store the actuall libraries containing the code. Thus, normally, only an admin can install malware. There are plenty of them that will try and install for the current user only though, changing HKCU and installing into the profile, these can be installed by anyone that has the rights of "user" or above. However, since the guest account would delete such malware on logout (it probably deletes the guest HKCU as well, now that it comes to mind), there's no way to get the stuff on the system.

 

[Iclisx]

Originally posted by THRESHIN
thanks a lot for the help guys. its somewhere to start. didn't know what the guest account would allow/not allow until now....very interesting....

Just keep in mind that it wipes everything out...

I do some software testing and every once in a while I use the guest account to ensure things work. It always kind of irks me that when I log out everything is wipped out.

If you end up using the guest account, I would reccomend that you make a special directory somewhere than has read\write access for the guest account to be able to store things (like a downloaded song, or a document). Of course this opens up the possibility that they will store executable code there. If you end up doing this, you can go into the NTFS permissions and add a "deny" on execution from that directory. That ensures that even if executable libraries are places there, they will never be loaded by the OS for execution.


Edit:
Oh yea. If it wasn't already obvious, all of the above mentioned stuff requires that you be running NTFS rather than FAT32. Since NTFS is the default I don't think it's a problem. If you're using Fat32, think about changing since fat32 leads to many of security features of the OS being disabled since there is no file system level support.

 

[Flying Fox]

Originally posted by Iclisx
Installing any programs, even malware requires write access to an install location. If you force usage of the guest account, users won't have rights to install malware.

Specifically those IE named objects that people tend to install usually require access to the HKLM registry hive, which only admins can alter. They also require a place to store the actuall libraries containing the code. Thus, normally, only an admin can install malware. There are plenty of them that will try and install for the current user only though, changing HKCU and installing into the profile, these can be installed by anyone that has the rights of "user" or above. However, since the guest account would delete such malware on logout (it probably deletes the guest HKCU as well, now that it comes to mind), there's no way to get the stuff on the system.

Actually, what I meant was that there may be a bug (or two?) in IE that may allow elevated privileges attack. If IE is not properly locked down (disable scripting, ActiveX, etc.), you *may* get burned at some point in time.

Also use non-trivial passwords for all administrative accounts to avoid (at least for the simplest) dictionary attacks too.

 

[[MS]]

Originally posted by Flying Fox
Actually, what I meant was that there may be a bug (or two?) in IE that may allow elevated privileges attack. If IE is not properly locked down (disable scripting, ActiveX, etc.), you *may* get burned at some point in time.

Also use non-trivial passwords for all administrative accounts to avoid (at least for the simplest) dictionary attacks too.

IE runs with the same privileges as the user tha launched it. Even if there was a bug in the JScript\VBScript engines, and some code was able to be injected into the process, that code would still be running with the same permissions as the user. Thus, such an attack isn't elevation of priveleges, as far as the system is concerned anyway. This is, of course, the reason to keep to system up to date; the chance you'll ever encounter and arbitrary code execution exploit in the wild before an update is available is pretty close to zero.

That said, everything is an attack surface. If the risk of having a PDF viewer or Flash plugin outweighs the benefit, by all means take the secure path and dont install them. I have plenty of systems at work (mosty) and home where this is the case. If the risk of having active scripting content is too high, it can be turned off as well. This is exactly what our recent server releases do.

As for passwords, any accounts that can be used to authenticate to the system from the network should have a strong password, not just admin accounts.

 

[THRESHIN]

Originally posted by Iclisx
Just keep in mind that it wipes everything out...

I do some software testing and every once in a while I use the guest account to ensure things work. It always kind of irks me that when I log out everything is wipped out.

If you end up using the guest account, I would reccomend that you make a special directory somewhere than has read\write access for the guest account to be able to store things (like a downloaded song, or a document). Of course this opens up the possibility that they will store executable code there. If you end up doing this, you can go into the NTFS permissions and add a "deny" on execution from that directory. That ensures that even if executable libraries are places there, they will never be loaded by the OS for execution.


Edit:
Oh yea. If it wasn't already obvious, all of the above mentioned stuff requires that you be running NTFS rather than FAT32. Since NTFS is the default I don't think it's a problem. If you're using Fat32, think about changing since fat32 leads to many of security features of the OS being disabled since there is no file system level support.

this info is pretty much exactly what i wanted to do. you've hit it dead on Iclisx! thank you thank you thank you!!! mind if i ask a silly question? how would you go about setting a directory to allow a guest account to read/write and have it not wiped out? secondly how would you deny the executable permissions? i know this seems dumb, but would you believe that i have never used NTFS? yeah its freaky....i run a dual boot system. win98SE and XP....i call it SEXp!!! sorry, had to slip that one in. no pun intended there either....

man this stuff is great. i love hardware and know it really well, but i've always been a dunce with networking and permission stuff like this. guess that's why i don't take a computer course a college.

all this stuff is great learning for me. i'm learning way more here than any website i've found so far...but if anyone knows one to use for this stuff....i'd be very interested

 

[Iclisx]

> how would you go about setting a directory to allow a guest account to read/write and have it not wiped out?

You would have to have an directory outside the normal profile space (outside of "%SystemRoot%\Documents and Settings"). Ideally this would be on another drive, but if you only have a single drive, you could create a "C:\GuestArea" directory or some such thing.

Next, specifically grant the "<MachineName>\Guests" group modify and write access to the folder (minus execution permissions). Step by step:

1 Make sure you can get to the advance security options...
- 1.1 If using XP Home, reboot in safe mode (the advanced secruity options used later are not normally exposed in XP-Home)
- 1.2 If using XP (Home or Pro), from any explorer open the "Tools->Folder Options" menu. Make sure the "Use simple file sharing" option is NOT checked

2 Give the "guests" group read\write access...
- 2.1 Right click the folder you created, select the "properties" context menu item.
- 2.2 From the "properties" dialog, go to the "Security" tab
- 2.3 On the Security tab click "add" and type in "<MachineName>\Guests", where "<Machinename>" is the actual name of your system. For example: "MyBoxx\Guests". Click "OK" and an appropriate entry will be made in the security access list.
- 2.4 Under the entry you just added (it should already be selected, and should already have the "Read & Execute", "List Folder Contents" and "Read" rights), add the "Modify" and "Write" rights. The remaining two boxes should NOT be checked (Full control and special). Apply the changes.

3 Explicitly deny execution rights to the guests group
- 3.1 From the Security tab on the folder properties, click the "advanced" button.
- 3.2 Click the "Add" button and type in the same group you just granted rights to. Example: "MyBoxx\Guests". Click "OK" and a permission selection box should come up.
- 3.3 In the "Deny" column, check the following three permissions: "Traverse Folder / Execute File", "Change Permissions", "Take Ownership". Leave all other boxes unchecked. Click "OK" and then "Apply" the changes from the advanced security settings (It may throw a warning the first time you use a deny entry, this just explains that denied permissions override any permissions the user may have).

4 Explicitly deny execution rights for everybody
- 4.1 From the Security tab on the folder properties, click the "advanced" button.
- 4.2 Click the "Add" button and type the everybody groupd in the same fashion as you did for the guests group Example: "MyBoxx\Everybody". Click "OK" and a permission selection box should come up.
- 4.3 In the "Deny" column, check the following permission: "Traverse Folder / Execute File". Leave all other boxes unchecked. Click "OK" and then "Apply" the changes from the advanced security settings.


Done...

You now have a directory that won't be wiped out since it's outside the Guest's profile. Additionally, the guest has all rights to it except the right to run executables and the right to change his own rights (so he can't give himself execution rights).


The only thing I can think of that would keep this from working was if you weren't running on NTFS, or if you had originally installed XP on Fat32 and converted the drive to NTFS later on without reinstalling.



Edit: on second thought, there's one more thing I would do. With the above configuration, it's possible a guest could download something that's executable and even though they couldn't run it, an admin or normal user might accidentally run it at a later time. If you don't trust your guests, ideally you woudn't trust the stuff they download, no matter what account you happen to be using. To fix this, I'd add a second "Deny" Access Control Entry (ACE) that explicitly denied execution permissions for all accounts for that directory. I added that above in italics.

 

[Flying Fox]

For better ease of use, there's probably a need to set a shortcut on desktop or redirect My Documents to that guset folder? Don't know if you can run login script with XP Home, so does anyone know how to set this up? If this is done in a certain HKCU setting, it will be wiped up after logoff. So how can this be done?