CSED 431 Week 1

VirtualBox configuration
Windows XP sandbox
Cygwin | Powershell
Windows file permissions
Sysinternals
Windows SteadyState
Software permissions

The schedule says:
5:15-6:45 in LT 605, 7:00-8:15 in the Emerging Technologies Lab
That's 3.0 hours! I expect that we will usually be done by 8:00.

VirtualBox

This is Sun's free alternative to VMware; there are also other free alternatives. Right now we're having trouble getting academic licenses to VMware Workstation. The feature that we need is snapshots. At the lowest level, a virtual disk is a file (a *.vdi file) of disk blocks. When we take a snapshot, all updated blocks are recorded in the snapshot file; when we access a block, the system looks first in the snapshot file and then, if that fails, in the main *.vdi file. Thus, at any point we can

throw away all changes since the snapshot
keep the snapshot active
merge the snapshot back into the primary *.vdi file

You can have a whole chain of snapshots. If you want to try something and throw it away, you

take a snapshot
make the windows change
throw the snapshot away (ie revert)

If you want to merge the changes since the snapshot back into the main virtual disk, right-click on the snapshot and choose "Discard Snapshot". This is misleadingly named!

Right-click on the "Current state" if you want to:

take a new snapshot
revert to the previous snapshot, discarding all changes since the snapshot
revert to before the snapshot ("Discard current snapshot and state")

Here are some reasons for using virtual machines in this course:

Ability to grant you full administrative control over the "hardware"
Ability to take/revert snapshots
Ability for me to replicate the exact same configuration to each machine

Note that when we work on the laptops, it will not be possible to work from home (unless you install VirtualBox at home, and bring your virtual machine back and forth on a USB drive). For that reason, we may eventually also use the system you used last semester as well, where the virtual machines ran on a designated server that allowed remote access.

Running VirtualBox on a linux host allows the following:

Improved network monitoring
Improved network firewalling

Note that before VirtualBox can start minXP, the linux script tapstart.sh must be run.

Windows XP

Why Windows XP? At the filesystem level, it's pretty close to vista/win7; NTFS has not changed much. Eventually we'll use virtual win7's too (demo). However, these take a lot more memory. Also, the windows SteadyState package that we'll look at this week is not yet available for win7 (it is available for vista).

In the VirtualBox configuration I've set up, the script tapstart.sh sets things up to enable network traffic from the virtual machine to the internet, and to do it in such a way that we can monitor that traffic as necessary.

I've called our first XP example minXP. I've installed cygwin on it, which provides the bash command shell normally associated with unix/linux. Microsoft's answer to bash is powershell, which we will eventually look at.

The network configuration is as follows:

The host linux system has an ethernet connection eth0 which gets its IP address from dhcp.
The linux system also has a virtual interface, tap0, with IP address 10.0.5.1
The virtual machine sees itself as on the same virtual ethernet with tap0.
The linux system runs dhcp on tap0, thus handing out an IP address to the virtual machine (eg 10.0.5.2)
The linux system routes IP traffic between tap0 and eth0 (the real internet)
The linux system uses network address translation (nat) to make the virtual IP address share with the laptop's real IP address. Thus, the outside world doesn't have to assign any further IP addresses beyond the one to the linux host.

Normal configuration is for the linux host to share the directory named "virtual" with the virtual machine, as drive z:. The file share is \\vboxsvr\virtual. Files you place in the host system "virtual" directory should appear on the virtual machine.

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!

Demo:
    snort -vde -i tap0
    synsniff.sh
    blockmost.sh
    unblock.sh
    source ip address??

Windows history

1. Unix view of computing

Every user has a HOME DIRECTORY , eg /home/pld
Everything runs under the ownership of that user
A user's files are also owned by that user; typically not writeable by others
No user has write permission to system files
A user's MEMORY is safe from other-user read/write

This provides good system integrity: users can't read each others' files (without permission); users can't modify system files.

2. 1980's PC view of computing: one box, one user

User has complete control over the machine
The only reason for gathering your files into one folder is to make backups easier
Users can install new software: either intentionally or un (viruses)

The 1980 view persists to this day in that many users prefer to give themselves Administrator privileges. That way, if they want to install software, they can. Unfortunately, if they accidentally run a virus, it too will have the necessary permissions to install itself.

3. Late-XP/Vista/Win7 preferred model:

Ordinary users do not have privileges to alter system files or configuration
When you need to do something as administrator, you actually have to change:

Windows XP: use switch user to get to an administrative account
Vista: User Access Control will interrupt you and ask to confirm the privilege elevation
Win7: UAC is still there, but less intrusive

4. Windows multi-user lab configurations:

A user should be able to log into any machine, and see the same environment (mostly).
If user A begins work on machine B, logs off, and later resumes work on machine C, it is very important that, one way or another, the user should be able to pick up where they left off. Otherwise you are stuck with messy social situations where A wants to ask the current user of machine B to leave.
Any machine can be logged into by any user; a typical medium-sized configuration might consist of 100 machines and 1,000 users.
Users must have a way of saving work. This can be network storage, USB/etc removeable drives, or email (a form of network storage!). Note that saving files on your particular machine is unacceptable, because you may get a different machine next time.
The user environment can be static (the same for everyone), or it may support individual user files and/or individual user preference settings.
Users can't modify basic configuration; eg they should not be able to install software or modify system files. We generally don't care if the user has good intentions, bad intentions, or may be doing unintentional harm (viruses)
For office environments where each user almost always logs in to the same machine, many things are simpler. On the other hand, office workers just about always need individual file storage and persistent settings.
It is usually the case that at any one time, only one user is using a given machine. However, sometimes other users are allowed to run things in the "background".

Two ways of protecting files:

local permissions ("client-side")
network drives mounted "read-only" ("server-side")

YES v NO issues for computer-lab settings
    YES: access to the internet
    YES: access to network drives
    YES: access to other resources such as databases
    YES: user can run installed software
    YES: access to printer
    NO: access to printing too many pages, or printing without paying
    NO: write access to system files
    NO: installation of software (a kind of write access)
    NO: viewing other users' files
    NO: monitoring other users' processes
    NO: viewing other users' registry settings, eg history

Summary of general goals:

Workstations + Server(s)
Users are prevented from making undesired modifications to Workstations
Users are prevented from taking undesired actions with Workstations (inappropriate browsing; IM; running apps)
Users in programming classes can run their programs
Software updates can be propagated from the server
"Policy" settings and desktop customization can be established from the server

Some models for labs

1. Everyone uses account GUEST, or NTUSER.
       No persistent files; no customization
       problem: how to be sure email, other passwords aren't saved!

       This can be implemented with a bunch of "standalone" XP hosts; no server

2. Everyone uses a fixed account, say NTUSER. There are no persistent files and no customization. However, everyone is given their own <userid, password> credentials, and a non-Microsoft logon front-end is installed. This is the strategy Loyola uses in their labs.

3. Everyone has their own Windows account, but there is still no disk space provided. A domain controller and domain are needed to handle accounts, but there is no disk server (and thus no need for disk backups).

4. Everyone has their own account, plus online disk space

Windows File Permissions

Windows files have 11 permission attributes, each of which can apply to any number of users and groups. Note that some groups are built-in and some are added later.

Further information is at www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/. Note that file permissions are closely integrated with file systems; that is, permissions must be supported by NTFS and the operating system.

Here are the "basic 5/6 permissions:

Full Control
Modify
Read & Execute
List Folder Contents (a form of Read)
Read
Write

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

Traverse Folder/Execute File (mysterious)
List Folder/Read Data
Read Attributes
Read Extended Attributes
Create Files/Write Data
Create Folders/Append Data
Write Attributes
Write Extended Attributes
Delete Subfolders and Files
Delete
Read Permissions
Change Permissions
Take Ownership
Synchronize

Some groups are added by convention or added by the local administration. There are also a number of built-in groups:

Everyone (no longer actually everyone; it does not include anonymous logons since XP SP2)
Local System -- this is actually an account
Administrator -- also an account
Guest -- an account
Users
Administrators
Power Users
Local
Network
Batch
Service
Anonymous
Authenticated Users

A fuller list of the built-in groups, with descriptions, is at http://support.microsoft.com/kb/243330.

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

Permission inheritance from a folder to its files and subfolders can be blocked. This is done with the special-permissions option. Also, one can set the permissions of an object so as to remove all inherited permissions. I believe it is possible to create a folder such that newly created subfiles do not inherit at the time of creation.

The virtual group creator ownerallows a set of permissions to be assigned to whoever is the owner at the time when the file is created; when the file is created with owner foo, the permissions that had been granted to creator-owner in the inheriting folder are granted to foo (the new owner) instead. Note that creator-owner permissions only make sense when inherited from a folder. Also, creator-owner permissions are only useful if multiple users have the necessary permissions to create a file in the given folder. Allowing a folder read-write access to creator-owner means that the read-write permissions transfer automatically to whoever creates a file in that folder. If a folder has creator-owner read-write permissions and also, say, create-folders permissions for Everyone, then any user can create a folder and when they do so it will automatically have read-write permissions for themselves.

Suppose user bob owns a file and allows read-write access to bob, and also grants take-ownership rights to user alice. When alice takes ownership, then alice will not have read-write access and bob still will; the permissions would have to be updated separately. This can be error-prone.

Demos:

Sysinternals

The site sysinternals.com used to be independent, but was purchased a couple years ago by microsoft; everything is now at technet.microsoft.com/en-us/sysinternals/default.aspx. The site was developed by Mark Russinovich and Bryce Cogswell, who specialized in developing useful utilities for peering at the internals of windows. We're going to look at two such utilities today: process explorer and access check.

Process Explorer is at technet.microsoft.com/en-us/sysinternals/bb896653.aspx. It provides detailed information about what processes are running, and what files, etc they are using.

AccessEnum is at technet.microsoft.com/en-us/sysinternals/bb897332.aspx. It is the GUI analogue of AccessCheck. Windows permissions are pretty complex. How do you audit them? How can you be sure that you haven't inadvertently left write permissions on some important system file? AccessEnum can show you which files in your C:\windows folder are writeable by ordinary users.

Actually, AccessChk may be more convenient, despite its command-line interface. Find it and its documentation at http://technet.microsoft.com/en-us/sysinternals/bb664922.aspx. The basic form is
    accesschk userid directory
If you want it to report subfolders too, use the -s option. If you want the output to be limited to files that the given userid has write permission for, use -w. Example:
    accesschk -s -w pld c:\windows
    accesschk -s -w Everyone c:\windows

Windows SteadyState

This is a Microsoft-developed package for securing standalone (that is, not on a domain) windows hosts. As of this writing, it is not yet available for Windows 7, though it has recently been ported to Vista. The main component of interest, for us, is Windows Disk Protection, a Microsoft version of DeepFreeze by Faronics, Inc.

Software Restriction Policy

Lab

1. Start (or restart) your minXP virtual machine. Log in to it, and try using it. Use account owner, pld, or user. If there is a password, it is "demo". Try resizing the virtual-machine window.

2. Run AccessEnum. It should be in the sysinternals subfolder in the Shared Documents folder. How helpful is it in determining what c:\windows files are writeable?

3. Try the same with accesschk.exe

4. Run ProcessExplorer (procexp). Try out some of the options. We will likely do more with it later.

5. Run Control Panel
=> Administrative Tools
=> Computer Management
=> System Tools
=> Local Users and Groups.

What users have windows accounts? For each of owner, pld, and user, how big is their NTUSER.DAT?

6. Create a snapshot, make some filesystem changes, and revert. Are the changes gone?

7. Make sure you can access the host system /home/pld/virtual directory through the windows drive z:. If necessary, use the VirtualBox menu
Devices
=> Shared Folders
=> Machine Folders
=> + (add), Folder path = /home/pld/virtual, Folder name = virtual, Make Permanent

Then use any explorer window => tools => map network drives, to map \\vboxsvr\virtual to drive z: (or another letter).
Install Windows.

8. Run the quick scan of the windows malicious software removal kit. Find it in the virtual folder.

9. Install SteadyState.msi, which should be in the virtual folder. (You might want to take a snapshot first, because windows steadystate can mess things up.)