CSED 431 Week 3 -- February 8


Networking
Windows file permissions
    Example of user permissions and inheritance
Windows SteadyState / DeepFreeze
Software permissions
procexp and svchost.exe
Registry editing
   


Windows Validation

Some of you were running into problems last week with Windows validation (for the SteadyState installation). I entered the license key for medXP and activated it; why did the validation step run by SteadyState then fail?

When windows installs, it computes a "hash" of several system This hash is sent to Microsoft during validation. If anything changes, hardware-wise, you may have to re-validate.

When I copied medXP to all the lab machines, I unfortunately did not copy the file that stored the machine "state". All the machines I created had the same amount of memory, but each had a different Ethernet address. That can, somewhat randomly, cause the validation check to fail.

This time I have tried to install the same virtual hardware, using the import/export options of VirtualBox. As a result, all copies of medXP should have hardware address 08-00-27-F6-CF-5E.

This can be something of a trial when installing labs: one generally creates one disk image and then "clones" it to the other hardware. However, that hardware will not be "identical" (if the Ethernet addresses were identical then they could not communicate with one another!), and so the same issue arises.

Networks

Brief review of IP addresses and DHCP
    IP addresses are 4 bytes
    They are composed of a network part + host part.
    The subnet mask provides the cutoff between the two
    Each machine needs:
        IP addr (network part is predetermined)
        subnet mask
        router
        DNS server
    DHCP is the protocol that generally hands these out.
     
    First mention of NAT
     
    Brief review of DNS
        basics of how lookup works, hierarchically
            edu
            luc.edu
            cs.luc.edu
            csed.cs.luc.edu
             
        cacheing
                
        alice.cs.luc.edu and bob.cs.luc.edu do NOT need to have related IP addrs!

Click here to find what the CS Dept server thinks is your IP address!

Windows File Permissions Revisited

Consider minXP. Let us follow the file permissions from drive C:\ down to C:\Docs&Settings\user\My_Documents. Note that the root of the drive, C:\, is in fact writeable by Users. More specifically, the Users group has permissions to:
The first two appear to be there to support "legacy" software that wants to create its own folder, eg C:\old_software. Note that creation of top-level files is in fact prohibited. Also, deletion or renaming of existing folders is prohibited.

For the Documents and Settings folder, the Everyone group still has Read/Execute permission, as do Users and Power Users.

For the individual user folders within, though, for owner and user, permissions change quite a bit. The User permissions would have been inherited, except that as part of account creation these permissions have been actively removed. All that is left are Admin/SYSTEM permissions, and full-control for owner and user to their respective folders.

The owner/user folder permissions then propagate down "normally" to their respective My Documents folders. These are the permissions that are inherited by any newly created subfolders. The top-level inheritable permissions granted to the Users group were blocked at owner/user, and so are not inherited to their respective My Documents.



The full "fine-grained" permissions are a set of fourteen. Not all apply in all situations.

Permissions generally inherit from the parent folder, at the time of file creation, which in turn may inherit permissions from its parent. However, "grandparent" inheritance is not automatic. If the parent-folder permissions change after the file is created, the file does not gain the new permissions.

   

SteadyState computer restrictions

1. Do not display user names in the "Log On to Windows" dialog box
This is to keep usernames concealed; that way, someone has to guess both the username and the password. The security here is limited, but may be of practical importance in a school setting.

2. Prevent locked or roaming profiles that cannot be found on the computer from logging on.
When you create a user account, a profile is not created until that user actually logs on for the first time. This setting prevents the use (initialization) of such accounts.

3. Do not cache copies of locked or roaming user profiles ....
The idea here is that cached copies of profiles are used if the network is unavailable.

4. Remove the Aministrator user name from the Welcome screen
Commonly done, does not really improve security

5. Remove the Shut Down and Turn Off options...
Keeps people from rebooting accidentally

6. Do not allow Windows to compute and store passwords using LAN Manager hash values
Fixes a security loophole in an obsolete password format

7. Do not store usernames or passwords used to log on to Windows Live ID or the domain
What is special about Windows Live ID? And this won't work with Firefox.
Implementation: system registry entries

8. Prevent users from creating folders and files on drive C:\
Why is this permission the default?
Implementation: NTFS file permissions on C:\

9. Prevent users from opening MS Office documents from within Internet Explorer
A good idea, but too narrow in scope.
Implementation: registry entries for Internet Explorer

10. Prevent write access to USB storage devices
What you really want is to prevent people from running software from USB drives!

11. Turn on the Welcome screen
Somehow, in doing this, installation manages to turn off Fast User Switching.


Software Restriction Policy

How can we keep people from running inappropriate software, including viruses? One approach is "security through obscurity", often implemented by trying to hide ways to launch the software by hiding menu options or disabling certain menus. Here is an example, from my son's former high school:
Question: How do you run something unapproved?

First you write a small visual basic program:   
    Sub foo()
        pid = Shell("c:\software\googleearth\GoogleEarth.exe")     // or c:\windows\system32\cmd.exe
    End Sub
 
Now create a word macro to run it:
  1. Word => Tools => Macro => Visual Basic Editor
  2. Insert => Module
  3. Paste in the code above
  4. Run it
(An analogous issue is how to deal with users' editing the registry. Some sites take the approach of hiding regedit.exe, but users can almost always get around that, by bringing their own copy or by using some "shell-scripting" alternative to regedit. A better approach is to mark the registry as read-only.)

What is needed is a way to disable the running of new software at a fundamental level, so that even if the software is found, it cannot be executed.

One approach is to use Windows Software Restriction Policy, which allows us to disallow executables in certain folders. The basic idea is to make sure that every part of the disk is either not writeable by the user, or is covered by a Software Restriction Policy. The standard Program Files and Windows folders would be completely non-writeable by the user, but exempt from the SRP. That way, legitimately installed software would still run. However, by disabling the execution of software in all folders that the user might have saved it to, there is no way for the software to be launched. (Note that covering mountable devices such as USB drives requires special care.)

Note the programmer problem: students in programming classes must be able to run programs. There is, realistically, no way to distinguish self-written legitimate assignments from programs brought in from the outside. However, for some languages (and most school courses) it is sufficient to run programs from within the development environment (IDE).

Software Restriction Policy allows a default rule of Unrestricted (everything can run, with exceptions) or Disallowed (nothing can run, with exceptions). Realistically, the latter policy is a more effective approach.

Software Restriction Policies in XP are set via Control Panel => Administrative Tools => Local Security Policy => Software Restriction Policies. Right-click and choose "Create New Policy" to get started.

Exceptions can be listed in the following four ways:
In lab environments, the usual strategy is to create a Disallowed default policy, and then to designate those (hopefully top-level) folders that may contain executables. On a typical Windows configuration, those folders would be:
(also see below)

Note that such a policy should forbid software on any USB drives from running.

The alternative is to leave the default policy as Unrestricted, but to apply Disallowed path SRPs to Documents and Settings and perhaps other folders. The problem here is that it is easy to miss something, and you won't cover additional drives (eg USB drives) or new folders at the top level of the C:\ drive.

Attempting to disallow certain programs (eg games) by using Hash exceptions is generally fruitless; executable files can almost always be "tweaked" by users so as to have a different fingerprint.

Rules can contain wildcards (eg *). One can write a rule to allow all software in D:\Documents and Settings\*\Programs, which would match, eg, D:\Documents and Settings\pld\Programs and D:\Documents and Settings\alice\Programs. This would allow a site to give to each user their own Programs directory, possibly that users could not write to directly but which could be populated with programs on an as-needed basis.

Also, rules can contain environment variables; the most common example is %WINDIR%. Note that anyone who can start a cmd window or who can otherwise reset environmental variables may be able to bypass this kind of restriction, eg by setting WINDIR from C:\windows to C:\Documents and Settings\pld\My Documents.

If multiple path rules match (some with Allow status and others with Deny), then the longest matching rule applies.

When implemented through Local Policy, Software Restriction Policy is purely yes/no; it does not interact with permissions at all. That is, you cannot write a SRP rule that allows access only to the group Teachers. What you can do, however, is to write a SRP software to allow everyone to run programs in, say, C:\Teachers_Software, but then use permissions to give only members of the Teachers group the right to Read and Execute the files in that folder. You can also implement SRPs through Group Policy, in which case you can apply the restrictions to selective groups.

See:
Windows XP's Software Restriction Policy is deprecated in Windows 7 in favor of "AppLocker". AppLocker allows the same sorts of hash/path/publisher rules, but also supports better per-user/per-group application, and also "audit mode" to determine (over, say, a week of real-user work) what programs would be blocked without actually blocking them.

A bad thing happened to me with the SRPs above: I couldn't open any of the control-panel applets! In particular, I couldn't open the Local Security Policy applet to fix anything. It turns out that these are all shortcuts, and not in the special directory! So they were seen by windows as executables in the wrong place! The fix is relatively simple: one has to add a special rule for *.lnk files (the underlying file-name form of shortcuts):
       *.lnk      Unrestricted
Of course, adding this is itself tricky if you can't open the control panel! But note the shortcut expansion, and go there "manually": C:\windows\system32\secpol.msc. Click on that, and it opens.


Lab

Software Restriction Policies

create a Software Restriction Policy as outlined above. Give each user a personal Programs folder within My Documents. Allow programs in this, but not other places. Verify that it works.

Now take away write access to the Programs folder for user Zack, and make owner be the owner of the folder. You can leave the folder empty; the idea is that Zack can only run programs in that folder.

As user Zack, figure out how to bypass this attempted restriction!